[c-nsp] per-packet load sharing.

virendra rode // virendra.rode at gmail.com
Mon Dec 10 09:59:59 EST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Ibrahim Abo Zaid wrote:
> Hi Rode
> 
> i believe that according for GRE order of operation , GRE encapsulation
> occurs first then routing decesion will be taken based on destination
> address of GRE-Encapsualted headers
> means that you will need 2 equal-cost routes for the GRE-tunnel destination
> 192.168.2.1
> 
> so check your router routing table for network 192.168.2.1 route and ensure
> it has 2 routes
- -------------------------
The thing is the cef is load-balancing packets across equal-cost links
on a per-destination which is how its suppose to be which I get it. The
issue is my tunnel traffic is destined to a single core router on the
far end of the links consuming the majority of the BW for any single link.

Hence I'm looking at using per-packet method. I don't have any latency
sensitive application that I need to worry in this case.

Not sure if I need to enable "ip load-sharing per-packet" on L2 port /
serial links off dual routers?


regards,
/virendra

> 
> also , CEF has a default load-sharing per-destination enabled so make sure
> to change it under interfaces to load-sharing per-packet
> 
> 
> best regards
> --Abo Zaid
> 
> 
> On Dec 10, 2007 1:42 PM, Joe Provo <jzp-cnsp at rsuc.gweep.net> wrote:
> 
>> On Sun, Dec 09, 2007 at 05:39:07PM -0800, virendra rode // wrote:
>> [snip]
>>> In order to distribute traffic (load-sharing) across two links I'm
>>> looking at enabling equal cost traffic (per-packet load sharing) going
>>> out both serial links as their data processing is overloading one link.
>>> The equal cost routes with CEF default load sharing is not distributing
>>> the load over the 2 links as expected.  MLPPP is not an option for
>>> budget reasons hence I'm looking at doing per-packet.
>> [snip]
>>> Any recommendation and /or feedback will be appreciated.
>> ECMP in routing protocols good, per-packet bad.  If you care at all
>> about TCP performance or have jitter-sensitive traffic then don't do
>> it.  Your best bet is to suss out how much BGP you can eat on the
>> platform, get that data and (backfill with 0/0 if you are on a limited
>> platform), then slice and dice your load at that level.
>>
>> Cheers,
>>
>> Joe
>> --
>>             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
>>  _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHXVRvpbZvCIJx1bcRAjqMAKCipcfSht9pAUK6yvEUpB8ie+p8sACg2z8+
AaxHQ9fc9vXSM+G13VES97Y=
=rWJy
-----END PGP SIGNATURE-----


More information about the cisco-nsp mailing list