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

Hello Joe,

It is just a business matter, the PBR is used exclusively to define outgoing
traffic for the correct ISP as the /24 given is divided by customer services
and some has to leave primarily via the ISP B (2MB) for instance. The path via
ISP C has its own set of prefixes going out and does not have any backup path,
however, the prefixes leaving via ISP A/B need to have ISP C as backup in case
of issues on their links. Since the agreement is to receive partial routing
from the ISPs some of the summary/aggregrate addresses (/18) are falling into
the BGP peering segment and available at all times, so starting to think IP
SLA monitoring with PBR towards those addresses may not work, the fallback
will never happen. Need to ensure the BGP sessions are formed exclusively by a
single path, and workaround this IP SLA with PBR configuration.

R1

ISP A = 6MB

ISP B = 2MB

R2

ISP C = 6MB

Thank you,

Marina Ferreira

> From: jastorino_at_ipexpert.com
> To: marinalf_at_msn.com; ccielab_at_groupstudy.com
> Subject: RE: BGP Multihoming with IP SLA and PBR scenario - different ISPs
> Date: Sat, 23 May 2009 20:21:42 -0400
>
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.31/2116 - Release Date: 05/23/09
> 07:00:00
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun May 24 2009 - 15:54:02 ART