[quagga-dev 8015] Re: [PATCH] bgpd: Implement multipath insertion into RIB

Adrian Ban bluelightning at mantech.ro
Wed Jun 2 18:15:47 BST 2010


Hi all,

This implementation of multipath it will be added to quagga if the 
mentioned attributes (same BGP path or same remote AS, same 
local-pref/weight/cost .. the RD is not discused here becouse VRF is not 
available yet in quagga) are respected?

Best regards.

On 5/24/2010 4:20 PM, Felipe Zanchet Grazziotin wrote:
> Hi all,
>
> getting a little late on discussing, but as far I remember from Cisco's
> implementation,
> multipath for BGP will only work if attributes are equal.
>
> By attributes I mean:
>
>   - same BGP path from both routes
>   - same RD (for VRF)
>   - no differences at local-pref, weight, cost
>
> Actually we can resume to:
>
>   - equal routes, but using N different next-hop routers to the same AS
> cloud
>
> This way it would be same to run even at edges or at backbone level.
>
> On Mon, May 24, 2010 at 7:26 AM, <paul at jakma.org
> <mailto:paul at jakma.org>> wrote:
>
>     On Sun, 23 May 2010, Boian Bonev wrote:
>
>         I also think that aggregation won't solve the issues with
>         traffic loops. It is the responsibility of the administrator not
>         to enable such a feature in a setup that can generate a routing
>         loop.
>
>
> If you only look at prefix destination, you can easily run into routing
> loop. That's way BGP attributes are important to be checked before
> continuing.
>
>
>     It's planting a mine in the path of administrators, which will blow
>     up at least a few. We don't need to do this, as the software could
>     and should just do the right thing.
>
>
>         Generally speaking this is very useful for non-transit nodes who
>         want to make outgoing traffic balance of their upstreams.
>
>
> Isn't it baking a hot potato and just sending it to your upstreams? I'm
> pretty sure there are many BCP against this practice.
>
>
>         For transit systems this is neither needed nor useful anyways.
>
>
> As said before, Cisco's way is safe for both.
>
>         What I did with that patch is to provide the option to balance
>         outgoing traffic when you have multiple upstreams. I have tested
>         this
>         with 3 full table upstreams without issues for about 2 months.
>
>
>
> Didn't bother to read before, but are you at least checking if sending
> to provider B isn't going to send to provider A in AS-PATH?
> If you don't check, your latency is going to increase for some packets
> and not for others. Different latencies lead to jitter, which
> is a show-stopper for many protocols nowadays. TCP will bother too, if
> PMTU is different.
>
>     Yes, I'm sure it's useful - thanks! It just needs a bit more work to
>     make it safe.
>
>
>
> To me just sound like a hack to lower your monthly bandwidth bill. Can
> be useful, tho... :)
>
>
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev




More information about the Quagga-dev mailing list