[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