[nsp] ip load-sharing per-packet - cef accelerated ?
Hank Nussbacher
hank at mail.iucc.ac.il
Thu Jan 22 05:52:07 EST 2004
I'd like to revisit CEF load sharing per packet from March 2003:
>] My understanding is that 'ip load-sharing per-packet' is CEF accelerated,
>] yes?
>
>No. It is per packet load balancing instead of per flow load balancing.
>This puts quite a bit of additional load on the router, and may result
>in out of order packets arriving at the destination. I recommend
>against it.
>
>Likely the providers with whom you've spoken don't want to chew up their
>router CPUs with a per packet load balancing solution.
>
>Just my $.02, of course.
>
>Thanks,
>Rob.
To which Oli wrote:
>All,
>
>just to clear this up (some wrong information has been floating around in
>this thread):
>
>"ip load-sharing per-packet" is CEF accelerated, there is no significant
>overhead when it comes to router performance compared to cef
>per-destination (I'm now only talking about non-GSR systems). The sole
>difference between the two is how we select one of the 16 loadsharing
>bucket when we switch a packet.
>
>cef per-destination (the default loadsharing method) uses a hash with
><source,dest>, so the name is a bit misleading. It does NOT balance per
>destination address only, as someone mentioned. And it also does not
>load-balance per micro-flow as L4 information or protocol# is not used
>while building the hash.
>
>There is a command "show ip cef exact-route <source> <dest>" which can be
>used to find which path a given session (<source,dest>) will take:
>
>r1#sh ip cef 2.0.0.0 internal
>2.0.0.0/8, version 14, attached, per-destination sharing
>0 packets, 0 bytes
> via Serial2/0, 0 dependencies
> traffic share 1
> valid adjacency
> via Serial3/0, 0 dependencies
> traffic share 1
> valid adjacency
>
> 0 packets, 0 bytes switched through the prefix
> tmstats: external 0 packets, 0 bytes
> internal 0 packets, 0 bytes
> Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1)
>
> Hash OK Interface Address Packets
> 1 Y Serial2/0 point2point 0
> 2 Y Serial3/0 point2point 0
> 3 Y Serial2/0 point2point 0
> 4 Y Serial3/0 point2point 0
> 5 Y Serial2/0 point2point 0
> 6 Y Serial3/0 point2point 0
> 7 Y Serial2/0 point2point 0
> 8 Y Serial3/0 point2point 0
> 9 Y Serial2/0 point2point 0
> 10 Y Serial3/0 point2point 0
> 11 Y Serial2/0 point2point 0
> 12 Y Serial3/0 point2point 0
> 13 Y Serial2/0 point2point 0
> 14 Y Serial3/0 point2point 0
> 15 Y Serial2/0 point2point 0
> 16 Y Serial3/0 point2point 0
>r1#
>r1#sh ip cef exact-route 1.1.1.1 2.2.2.2
>1.1.1.1 -> 2.2.2.2 : Serial3/0 (attached)
>r1#sh ip cef exact-route 1.1.1.2 2.2.2.2
>1.1.1.2 -> 2.2.2.2 : Serial2/0 (attached)
>r1#sh ip cef exact-route 1.1.1.3 2.2.2.2
>1.1.1.3 -> 2.2.2.2 : Serial2/0 (attached)
>r1#
>
>Please also check
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt1/xcfcefc.htm#1000944
>
> oli
Does anyone have any concrete RSP and VIP numbers to show what happens when
switching from per destination to per packet?
Using per destination is not great - take this as an example:
TAU-gp1#sh ip cef s9/1/1
Prefix Next Hop Interface
128.139.179.0/24 attached Serial9/1/1
128.139.220.57/32 128.139.179.2 Serial9/1/1
128.139.188.2 GigabitEthernet8/0/0
128.139.251.0/28 128.139.179.2 Serial9/1/1
128.139.188.2 GigabitEthernet8/0/0
128.139.251.32/28 128.139.179.2 Serial9/1/1
128.139.188.2 GigabitEthernet8/0/0
132.72.0.0/16 128.139.179.2 Serial9/1/1
128.139.188.2 GigabitEthernet8/0/0
132.73.0.0/16 128.139.179.2 Serial9/1/1
128.139.188.2 GigabitEthernet8/0/0
192.168.4.4/32 128.139.179.2 Serial9/1/1
Was hoping that one /16 would take S9/1/1 and the other /16 would take
G8/0/0 but:
TAU-gp1#sh ip cef exact-route 0.0.0.0 132.73.0.0
0.0.0.0 -> 132.73.0.0 : GigabitEthernet8/0/0 (next hop
128.139.188.2)
TAU-gp1#sh ip cef exact-route 0.0.0.0 132.72.0.0
0.0.0.0 -> 132.72.0.0 : GigabitEthernet8/0/0 (next hop
128.139.188.2)
Becomes more of a hit and miss :-(
-Hank
More information about the cisco-nsp
mailing list