BGP with two ISPs and private AS

[Dmitry Podtikhov]

Hi

Assume I have two sites, each have two routers and two ISPs providing MPLS VPN service to me. Site routers use OSPF two exchange routes. ISP offer BGP as PE-CE routing protocol with the use of private AS numbers.

So here are my thoughts about the whole setup:

Each ISP will be in its own private AS, I will bring up EBGP session from each of my router to the appropriate ISP.

I will announce site's prefixes with several prepends to the secondary ISP so that the route priority was chosen according to the AS-PATH attribute. There is no problem with the sites that have one router for two ISPs, but there is some questions about dual router setup.

The problem is that EBGP routes recieved from other site will be chosen as the best on each router because of the administrative distance of 20, regardless of the protocol between this two site routers.

But I want my traffic to be routed only via ISP1 as the main ISP. There is a possibility that packets from the site will pass through the router with the secondary ISP and will go to the other site via the route recieved from secondary ISP because of the administrative distance of 20.

My thought is to set different private AS per each site router so that distance was equal and routes were chosen according to the AS-PATH.

I've set up a lab in dynamips - all is working, but maybe there is more effective way to reach my goal (e.g. IBGP between site router with changed protocol distance or something else) ?

[Olga.Vedina]

The answer to this issue with advertising routes back to eBGP (or, surprise, even back to iBGP RR-client!)  is dynamic update groups

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtbgpdpg.html

[milan.kulik]

Hi Olga,

so you are saying:

Cisco  IOS is creating updates groups automatically.

As the router is advertising the same prefixes with the same attributes to all members of the update group, it can happen one of the group memebers is receiving prefixes with next-hop being its IP address?

I can see in my network:

I'm peering to several providers by primary/secondary pairs of routers.

And the update groups are created composed of that router pairs.

So when a prefix is received from the primary router within that pair, its advertised by my routers to the secondary router within the pair with next-hop attribute being the IP address of the primary router. As the primary router is a memeber of the same update group, it's receiving the same perfix with next-hop being its IP address!

So you are right probably!

Thanks a lot,

Milan

[Olga.Vedina]

Hi, Milan!

No, it will not recieve update with its ip as next-hop. As my sending router will change it to itself according to eBGP rules, if it's eBGP peering, add its AS number and send it to all clients in dynamic-group. If originaly sending router is in this group, it will recieve this update, see own AS and denies it.

If it's iBGP, and route was reflected by my reflector, it adds new attribute Originator ID and send this update to all clients in dynamic-update-group (without changing next-hop per iBGP rules), even to originator router itself, it it's part of this group. Originator will see this atribute and know that this is his path and denies it also.

[milan.kulik]

Hi Olga,

in my case, the eBGP neighbor will recieve update with its IP address as next-hop.

"When the next hop is in the same subnet as the peering address of the eBGP peer, the next hop is not modified. This is referred to as third party next-hop."

(See

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/15-2mt/irg-next-hop.html#GUID-C694DA2E-CF68-43A4-AC5E-F6AC640B1BB3  )

And this is my case.

But now I realized why not all prefixes are advertised back to my eBGP neighbor which was cunfusing me so far.

I have a route-map used which is denying some of them due to the provider changed the originating AS number slightly.

BR,

Milan

[Olga.Vedina]

Oh, i haven't thought that you might be on the same shared segment. In this case, yes, next-hop isn't changed. But I think your primary router doesn't even look at next-hop as it is discarding this update due to its own AS in as-path