1. Home
  2. Cisco Systems
  3. BGP multihoming with uneven links - sample config and Qs

BGP multihoming with uneven links - sample config and Qs

Hi, everyone,

I was hoping for some input from some of the BGP gurus here, in regards to a suggested configuration of a dual ISP + 1 router, with uneven links (DS3 and T1). I have asked earlier about this, and I have been advised to upgrade the T1 to DS3, but we do not have that financial capability, and would rather eliminate some Internet services, if the DS3 goes down ... but this is just logistics. The issue I would like to raise is a configuration suggested to us by the ISP with the T1 (I'll call them ISP-T1), involving something along these lines:

router bgp no synchronization no bgp log-neighbor-changes bgp dampening network --> this one comes from the ISP-T1 neighbor ISP-T1 peer-group neighbor ISP-T1 remote-as XXXX --> ISP-T1 AS number neighbor ISP-T1 version 4 neighbor ISP-T1 send-community neighbor ISP-DS3 peer-group neighbor ISP-DS3 remote-as YYYY --> ISP-T1 AS number neighbor ISP-DS3 version 4 neighbor ISP-DS3 route-map localpref in neighbor ISP-DS3 route-map ISP-DS3 out no auto-summary

.... various ip route ...

ip bgp-community new-format ip as-path access-list 10 deny _XXXX_ ip as-path access-list 10 permit .* ip as-path access-list 20 deny _YYYY_ ip as-path access-list 20 permit .* ip flow-export version 5 ip flow-export destination

.... other access lists ...

route-map ISP-T1 permit 10 match as-path 10 set community ZZZZ:WW route-map localpref permit 10 set local preference 300 route-map ISP-DS3 permit 10 match as-path 20

....

So - looking at the above: ISP-T1 implies that he could help us control the majority of the traffic through ISP-DS3, because of a community ZZZZ:WW used at his end, also, and the local preference. My questions are:

  1. I do not understand (yet) all this, so I have no idea what the community woullld do (how does it get defined at the ISP end, top allow - presumably - more routes to come the other way (through ISP-DS3)?
  2. What would happen in case of ISP-T1 failure (under two scenarios: my link to them, or their end)?

NOTE: all of the above has been typed just now, as we scribbled the stuff over the phone, on a notepad, so if there are typos, please do not consider them fundamental mistakes.

I would appreciate any comments, papi

Reply to
papi
Loading thread data ...

I assume there's supposed to be:

neighbor ISP-T1 route-map ISP-T1 out

You don't need to deny XXXX and YYYY in these ACLs. BGP automatically excludes the routes that were received from an ASN when sending to that ASN.

Unless you're providing transit service for other ASes, you should just use:

ip as-path access-list ## permit ^$

to advertise only the routes that you originate.

Should this be:

set community XXXX:WW

? The convention for communities is that the prefix is the ASN of the AS that uses the community. But I suppose ZZZZ could be their upstream provider's ASN.

What this *probably* does is tell them to change the local-pref of the routes they receive from you. Normally, an ISP will set the local-pref of their customer routes so that they're preferred over routes received from peers. But in your case, you only want the T1 to be used when the DS3 is down, so this drops the local-pref down below the local-pref for the peer routes.

Another possibility is that it tells them to pad the AS Path that they send to their peers. So their own customers will use the T1, but everyone else will prefer to the DS3.

The meaning of communities is established by the AS that you're advertising to. They should be able to provide detailed documentation of the various communities that they use.

They'll stop receiving routes from you, and their traffic to you will go through ISP-DS3.

Reply to
Barry Margolin

In fact we were hoping to send absolutely everything out the DS3, out of fear that we may not be able to properly control the "out" between the two unbalanced lines.

Good to know - thank you!

You are right - I got carried away with abstractization, out of fear of not making public info from providers that may or may not agree to have their opinion "google-ized" without consent :) ZZZZ is, in fact, XXXX.

Thank you again for all comments.

Reply to
papi

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.