[nsp] ip load-sharing per-packet - cef accelerated ?

[Oliver Boehmer (oboehmer)]

> Does anyone have any concrete RSP and VIP numbers to show what
> happens when switching from per destination to per packet?

concrete numbers for what? Performance? as I said: it should not make a
difference, but expect your end user's application to suffer from
out-of-order packets.
 
> 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:

Why do you think we would load-share like this? If you want to achieve
this, fiddle around with your routing protocol, but this is no longer
equal-cost-multi-path load-sharing.

> 
> 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 :-(

How are you able to judge your load-sharing distribution just by looking
at two flows (0.0.0.0 -> 132.73.0.0, 0.0.0.0 -> 132.72.0.0)? 

	oli