RE: iBGP Multipath and Route Reflector

From: gladston@br.ibm.com
Date: Thu Jun 16 2005 - 17:39:19 GMT-3


Thanks a lot Alexei,

It was a previous test and I missed it.

Cordially,
------------------------------------------------------------------
 Gladston

"asadovnikov" <asadovnikov@comcast.net>
16/06/2005 01:48

To
Alaerte Gladston Vidali/Brazil/IBM@IBMBR
cc
<ccielab@groupstudy.com>
Subject
RE: iBGP Multipath and Route Reflector

Reason R1 did not use 2 routes was that one of them had better weight set:

Rack2R1#sb 2.2.2.0
BGP routing table entry for 2.2.2.0/24, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: iBGP
Advertised to non peer-group peers:
142.20.125.5
Local, (Received from a RR-client)
142.20.125.5 from 142.20.125.5 (142.20.5.1)
Origin IGP, metric 0, localpref 100, valid, confed-internal
Local, (Received from a RR-client)
142.20.125.2 from 142.20.125.2 (142.20.2.1)
Origin IGP, metric 0, localpref 100, weight 65000, valid,

So the one is simply better then another.

Even if you were to reconfigure R1 to use both routes he would only
advertise 1. Multipath is of a local significance, the prefix propagated
alone is the one marked best and each BGP speaker only going to have one
of
them.

In many cases RR would not be in a forwarding path, and then it does not
matter what he uses for local routing table.

Best Regards,
Alexei

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
gladston@br.ibm.com
Sent: Wednesday, June 15, 2005 7:16 PM
To: Chris Lewis (chrlewis)
Cc: ccielab@groupstudy.com; richard.harvey@nbs.nhs.uk
Subject: RE: iBGP Multipath and Route Reflector

Thanks for the replies,

The problem is that R1 is the RR; it receives the route from R5 and R2.
Even though it receives both routes, it does not use them (just one).

Am I wrong or the limitation pointed would be valid if multipath was
configured on R5 or R2? (which receives the route reflected by R1).

Cordially
------------------------------------------------------------------
Gladston

"Chris Lewis \(chrlewis\)" <chrlewis@cisco.com>
15/06/2005 09:21

To
<richard.harvey@nbs.nhs.uk>, Alaerte Gladston Vidali/Brazil/IBM@IBMBR,
<ccielab@groupstudy.com>
cc

Subject
RE: iBGP Multipath and Route Reflector

Richard,

You correctly state that a route reflector will run its best path
algorithm and only return one path, however there are workarounds used
in large production MPLS VPNs to provide load balancing to multi-homed
sites when route reflectors are used. The primary mechanism is to have
two route distinguishers configured to represent the site, this way the
route reflector will see two VPNv4 routes for each prefix coming from
the site and be able to support load balancing.

Typically a CE will have connections to two PE routers, say PE1 and PE2
for the purposes of load balancing. PE1 will associate a RD of say 120
to the site, PE2 will set 121, when the RR gets these VPNv4 routes, it
sees them as different routes, and forwards them on to RR clients to
enable multipath load balancing from those clients to PE1 and PE2.

Cheers

Chris

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
richard.harvey@nbs.nhs.uk
Sent: Wednesday, June 15, 2005 4:56 AM
To: gladston@br.ibm.com; ccielab@groupstudy.com
Subject: RE: iBGP Multipath and Route Reflector

This is a major shortfall of the feature - the RR just returns one path
to it's RR clients. This effectively prevents load-balancing to
multi-homed sites in an MPLS IP-VPN environment.

-----Original Message-----
From: MIME :gladston@br.ibm.com Sent: 14 June 2005 22:48
To: ccielab@groupstudy.com
Subject: iBGP Multipath and Route Reflector

Hi,

It seems iBGP multipath does not work when using Route Reflector.
(at least it was the result of the lab).

It works fine without RR:

R14#sb 2.2.2.0
BGP routing table entry for 2.2.2.0/24, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: iBGP
Not advertised to any peer
Local
142.20.28.8 from 142.20.28.8 (142.20.8.1)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
Local
142.20.28.2 from 142.20.28.2 (142.20.2.1)
Origin IGP, metric 0, localpref 100, valid, internal, multipath,
best R14# R14#sir 2.2.2.0 Routing entry for 2.2.2.0/24
Known via "bgp 65202", distance 200, metric 0, type internal
Last update from 142.20.28.2 00:00:58 ago
Routing Descriptor Blocks:
* 142.20.28.8, from 142.20.28.8, 00:00:58 ago
Route metric is 0, traffic share count is 1
AS Hops 0
142.20.28.2, from 142.20.28.2, 00:00:58 ago
Route metric is 0, traffic share count is 1
AS Hops 0

Now, with RR (R1 is the RR):

Rack2R1#sb 2.2.2.0
BGP routing table entry for 2.2.2.0/24, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: iBGP
Advertised to non peer-group peers:
142.20.125.5
Local, (Received from a RR-client)
142.20.125.5 from 142.20.125.5 (142.20.5.1)
Origin IGP, metric 0, localpref 100, valid, confed-internal
Local, (Received from a RR-client)
142.20.125.2 from 142.20.125.2 (142.20.2.1)
Origin IGP, metric 0, localpref 100, weight 65000, valid,
confed-internal, best Rack2R1#

Rack2R1#sir 2.2.2.0
Routing entry for 2.2.2.0/24
Known via "bgp 65202", distance 200, metric 0, type internal
Last update from 142.20.125.2 00:33:03 ago
Routing Descriptor Blocks:
* 142.20.125.2, from 142.20.125.2, 00:33:03 ago
Route metric is 0, traffic share count is 1
AS Hops 0

Rack2R1#

Do you have other experience?

(R1, R2 and R5 are on the same confederation, and is the same of R14, R2
and CAT2, so it seems confederation does not have influence on this
result)



This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3