RE: iBGP Multipath and Route Reflector

From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Wed Jun 15 2005 - 09:21:18 GMT-3


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