I am seeking some feedback/help with my BGP configuration. I am peering with two providers level3 and tw. Unfortunately all of my address spaces are preferring the route over tw rather than level3. I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3. I was trying to advertise each provider's address space out their connections and then use the other for backup. Now however everything is coming in through tw and no one seems to like level3.
Thanks in advance for any guidance or assistance.
Joe
How are you announcing your address space now?
I am announcing two separate /24s. 8.37.93.0 and 207.114.212.0.
Joe
Perhaps L3 is preferring the routes it hears from TW over the ones it hears
from you. Perhaps there is a community string you can attach to your
announcements to one or both providers which can help you further manipulate
what they do with your routes ...
Another thing to keep in mind that some providers will use local pref. as well for traffic engineering,
Looking at the TW Telecom Community strings, it would appear that they do...
http://www.onesc.net/communities/as4323/
http://www.onesc.net/communities/as3356/
Try using the communities to influence your traffic engineering.
BTW, I took a quick look at Routeviews looking glass for you ...
Here is what I see....
8.37.93.0/24 is only being advertised via your TW Telecom connection .... (Possible Filters issues with Level3 ?)
207.114.212.0/24 is being advertised via both TW Telecom and Level3.. and in case of Routeviews, it is preferring the Level3 connection.
The above is for inbound traffic only...
For outbound, if you want to use both connections, then you will have to create an ACL to change the Local Pref so that you can use one or the other provider as the preferred route.
Regards.
Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232
Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net
According to telnet://route-server.twtelecom.net and
http://lookingglass.level3.net/bgp/lg_bgp_main.php BGP is working as
designed. Your single prepend on one prefix with TWTC causes a slight
preference for LVL3. Add another prepend if you want to further balance
your ingress load away from TWTC.
Or for more coarse adjustment, use the TWTC feature communities to reduce
their local preference below that of customer default (115 for TWTC). Use
4323:100 for transit default.
../C
Hi Joe,
I had a situation like this a couple months ago but my two providers
were: Centurylink and Centurylink. No matter how many prepends I
added, the traffic preferred the slow link in one state to the fast
link in another.
It turned out that Centurylink (Embarq) gets to the Internet via
Centurylink (Qwest). Unless modified by communities, Qwest has a local
pref that delivers traffic to direct customers in preference to other
ASes. And the folks in Embarq's support had no idea what Qwest was
doing.
This sort of local-pref default seems to be a common practice with
backbones. It's very annoying. I wish they'd stop.
Regards,
Bill Herrin
This sort of local-pref default seems to be a common practice with
backbones. It's very annoying. I wish they'd stop.
Most of their customers would actually be very unhappy if they stopped. This local-pref default prevents many many problems and in the vast majority of cases provides the desired result. Yes, it's important to know what is going on and to be able to ask your providers to make necessary changes in circumstances where this is not optimal (either via community or ticket), but I assure you that if every backbone turned this off suddenly, most internet users would be very !HAPPY.
Owen
Le 29/01/2014 20:34, Owen DeLong a �crit :
This sort of local-pref default seems to be a common practice with
backbones. It's very annoying. I wish they'd stop.
Most of their customers would actually be very unhappy if they stopped. This local-pref default prevents many many problems and in the vast majority of cases provides the desired result. Yes, it's important to know what is going on and to be able to ask your providers to make necessary changes in circumstances where this is not optimal (either via community or ticket), but I assure you that if every backbone turned this off suddenly, most internet users would be very !HAPPY.
The underlying reason for this type of local preference has to do with
an assumption of cost
(which, given current transit prices, may be true or not):
cost(customer) < 0 < cost(peer) < cost(provider) ..., thus
local_pref(customer) > local_pref(peer) > local_pref(provider),
and as you say Owen, many actors sharing a policy simplifies our view of
things a bit. Another
way of assigning local preference of a route may factor in measured or
perceived path quality,
slightly more complex, but not a crime at all :-).
Cheers,
mh