RE: BGP Multihoming with IP SLA and PBR scenario - different

Quick question -- Is there a good business reason to rely on PBR for path
selection? Is there a reason why if ISP A or ISP B is down you go to ISP
C? If only A or B is down, why not just let BGP figure out if you should go
to either ISP A/B or ISP C ? I mean, why not just let BGP do it's thing
and route based on shortest AS-Path? If R1 lost it's peering to ISP A or
ISP B , BGP would just figure it out by itself.

Regards,

Joe Astorino
CCIE #24347 (R&S)
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
 
-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
marina ferreira
Sent: Saturday, May 23, 2009 8:08 PM
To: ccielab_at_groupstudy.com
Subject: BGP Multihoming with IP SLA and PBR scenario - different ISPs

GS,

Running into an issue with BGP Multihoming using this scenario:

R1 --> connects to ISP A (200.1.1.1) and ISP B (201.1.1.2)
R2 --> connects to ISP C (202.1.1.3)

1. The agreement is to receive partial routing from the ISPs 2. The PBR is
used to specify which internal prefixes are leaving via ISP A, B or C.
3. ISP C is used as backup for ISP A and B, but it does not have backup for
its own.
4. R1 and R2 are iBGP neighbors (10.1.1.x)

The simplified IP SLA and PBR configuration:

R1

ip sla monitor 1
 type echo protocol ipIcmpEcho 200.1.1.1 ip sla monitor 2 type echo
protocol ipIcmpEcho 10.1.1.2

route-map PBR permit 10
 match ip address PBR-ISP-A
 set ip next-hop verify-availability 200.1.1.1 1 track 1 set ip next-hop
verify-availability 10.1.1.2 2 track 2

ip sla monitor 3
 type echo protocol ipIcmpEcho 201.1.1.2 ip sla monitor 4 type echo
protocol ipIcmpEcho 10.1.1.2

route-map PBR permit 10
 match ip address PBR-ISP-B
 set ip next-hop verify-availability 201.1.1.2 1 track 3 set ip next-hop
verify-availability 10.1.1.2 2 track 4

R1 monitors ISP A and B, and long as they are reachable, traffic are
forwarded from R1, if ISP A or B are down, the next hop is R2 (10.1.1.2)
which then uses ISP C (202.1.1.3) as the backup. The R2 has the same
configuration monitoring ISP A and B IP addresses, so it does not use ISP C
when not needed. It has a list of prefixes already going out via ISP C
primarily.

The issue is that, when the BGP session between R1 and ISP A is down, the IP
SLA is still able to ping IP address 200.1.1.1 via ISP B, so the PBR does
not fall back to ISP C, and R2 is also able to reach IP 200.1.1.1 and still
thinks
R1 and ISP A BGP session is up. This is happening because the partial
routing received from the ISP B comes with a 200.1.0.0/18 supernet, and we
cannot find a way to block the specific prefix 200.1.1.1/32 individually.

Do you guys have seen any similar scenario or a solution to overcome this
type of issue when the BGP peering IP address segment is advertised by other
ISPs?

Thank you
Marina Ferreira

Blogs and organic groups at http://www.ccie.net
Received on Sat May 23 2009 - 20:21:42 ART