Hello Our router is running simple bgp. "one BGP router, two upstreams (each 100M from ISP A and ISP B) We are getting full feeds tables from them We discover the routes is going to ISP A only even the bandwidth 100M is full Can we set the weight to change to ISP B to use ISP B as preference routes? Can the following configuration work? What suggest to this weight no. too? neighbor 1.2.3.4 description ISP B neighbor 1.2.3.4 remote-as 111 neighbor 1.2.3.4 weight 2000 If this works, how is ISP B upstream connection is down? Can it still be failover to ISP A automatically? If it won't work, Do you have any suggestion? Thank you for your help
On Mon, Jan 30, 2012 at 7:27 PM, Ann Kwok <annkwok80@gmail.com> wrote:
We discover the routes is going to ISP A only even the bandwidth 100M is full
There are several ways to handle this is, if you have at least two /24s of space. Let's say you just have two /24s, both part of the same /23. Option 1: Announce m.m.m.m/24 with no path prefixing on ISP A. Announce m.m.m.m/24 prefixed with your own ASN one or two times on ISP B. Announce n.n.n.n/24 with no path prefixing on ISP B Announce n.n.n.n/24 prefixed with your own ASN one or two times on ISP A. Most of the internet would probably prefer A for m.m.m.m/24, and prefer B for n.n.n.n/24. But if either A or B went down, there would still be a reachable route. Option 2: Announce m.m.m.m/23 on both ISP A and B Announce m.m.m.m/24 on ISP A Announce n.n.n.n/24 on ISP B The n.n.n.n/24 which is part of m.m.m.m/23 would use ISP B for inbound traffic, while ISP A would be used for m.m.m.m/24. If either A or B, the less specific /23 would provide a backup path.
Can we set the weight to change to ISP B to use ISP B as preference routes?
Not really. You may be able to set a community that controls how ISP B advertises the routes or preferences your traffic. Weights generally aren't used for path selection.
Am 31.01.2012 04:06, schrieb Joel Maslak:
There are several ways to handle this is, if you have at least two /24s of space.
Let's say you just have two /24s, both part of the same /23.
[...]
Sad to see that deaggregation is still propagated to handle this issue. As a matter of fact deaggregation pollutes the global BGP table with more than 40% of rubbish, mainly caused by this silly type of traffic engineering. See the weekly routing table report or the CIDR report:
Analysis Summary ----------------
BGP routing table entries examined: 394446 Prefixes after maximum aggregation: 169250 Deaggregation factor: 2.33 Unique aggregates announced to Internet: 191523
There are many smarter ways to manage unbalanced links. See my slides presented on various occations (page 31 to 48) which describes the disadvantages and collateral damage of deaggregation: http://www.swinog.ch/meetings/swinog23/p/03_BGP-traffic-engineering-consider... HTH, -- Fredy Künzler Init7 / AS13030
On Mon, 30 Jan 2012, Ann Kwok wrote:
Our router is running simple bgp. "one BGP router, two upstreams (each 100M from ISP A and ISP B) We are getting full feeds tables from them
Are you sure you're getting a full table from each provider? A full IPv4 feed is close to 400,000 prefixes and a full IPv6 feed is getting close to 8,000 routes. It's also important to understand what the desired behavior is. Do you want to use both upstream links, or do you want to use provider B only when provider A is down? Based on your description above, I'm guessing you want to use both links at the same time.
We discover the routes is going to ISP A only even the bandwidth 100M is full
BGP doesn't know or care about link utilization. If all of your outbound traffic is using only one link, then it sounds like one (or more) of a few things is happening: 1. Provider B is only sending you a default route, or something less than a full table. If that's the case, then you need to get provider B to send you a full table, or verify that your BGP import policy isn't rejecting most of what provider B is sending you. Most specific route wins. 2. Provider B's routes are less preferred by your router for one or more reasons, with a longer AS path probably being the most common reason. Check if provider B is doing anything like prepending routes before they send them to you (generally a bad idea, but I've seen stranger things happen). 3. You are taking some action on provider B's routes to make them less preferred, such as lowering the local-preference. It might be helpful to post the whole "router bgp XXXX" section of your config, with any related items (route-maps, access-lists, prefix-lists, AS-path access-lists (if any, etc).
Can we set the weight to change to ISP B to use ISP B as preference routes?
neighbor 1.2.3.4 description ISP B neighbor 1.2.3.4 remote-as 111 neighbor 1.2.3.4 weight 2000
If you are receiving a full table from both providers, you can write a policy to reset the local-preference on some of the routes you get from provider B to higher than the same routes you get from provider A.
If this works, how is ISP B upstream connection is down?
Can it still be failover to ISP A automatically?
If you receive a full table from both providers, you should be able to use either provider's link when the other one fails, with little to no intervention on your part. jms
On Jan 30, 2012, at 9:27 PM, Ann Kwok wrote:
Hello
Our router is running simple bgp. "one BGP router, two upstreams (each 100M from ISP A and ISP B) We are getting full feeds tables from them
We discover the routes is going to ISP A only even the bandwidth 100M is full
Can we set the weight to change to ISP B to use ISP B as preference routes?
Can the following configuration work? What suggest to this weight no. too?
neighbor 1.2.3.4 description ISP B neighbor 1.2.3.4 remote-as 111 neighbor 1.2.3.4 weight 2000
If this works, how is ISP B upstream connection is down?
Can it still be failover to ISP A automatically?
If it won't work, Do you have any suggestion?
Please implement an AS-PATH filter on your outbound to your upstreams blocking yourself from re-annoucing their routes to them. You can see many of these cases here: http://puck.nether.net/bgp/leakinfo.cgi eg: 41.217.236.0/24 852 3561 6453 15399 15399 15399 174 3491 33770 36997 37063 37113 15399 (Wananchi Online Limited) is leaking their upstream (Cogent) routes to TATA (6453) - Jared
Hello
Our router is running simple bgp. "one BGP router, two upstreams (each 100M from ISP A and ISP B) We are getting full feeds tables from them
We discover the routes is going to ISP A only even the bandwidth 100M is full
Can we set the weight to change to ISP B to use ISP B as preference routes?
Can the following configuration work? What suggest to this weight no. too?
neighbor 1.2.3.4 description ISP B neighbor 1.2.3.4 remote-as 111 neighbor 1.2.3.4 weight 2000
If this works, how is ISP B upstream connection is down?
Can it still be failover to ISP A automatically?
If it won't work, Do you have any suggestion?
Thank you for your help
Ann, I've done this for a few customers that have requested it. Some engineers complain that advertising /24 routes dilutes the Internet routing tables, which is true in some regards. However, this does work in many situations to "balance" things out. Check out my blog post that walks through this procedure: http://mattreath.com/2012/01/29/bgp-load-balancing/ -Matt -- Matt Reath CCIE #27316 (SP) matt@mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath
On Mon, Jan 30, 2012 at 8:27 PM, Ann Kwok <annkwok80@gmail.com> wrote:
We discover the routes is going to ISP A only even the bandwidth 100M is full
Can we set the weight to change to ISP B to use ISP B as preference routes? Can the following configuration work?
Tuning weights and localpreference values can influence traffic that your equipment sends _to_ ISP A and ISP B. These options do not control what incoming traffic gets forwarded into your network _from_ ISP A or ISP B; you need a separate strategy for incoming bits. The config you listed should do just what the vendor documentation says it does, so I can't say it doesn't "work"; it just does nothing to help remedy the situation. That is, if you have two ISP links each 100M full duplex; and one of them is at 100% outbound usage, increasing the weight of all the other neighbor's paths assuming the set of prefixes received over BGP are the same, will mean that ISP B is the preferred next-hop for each path; which means ISP A outgoing utilization should drop to near 0, and then ISP B should be just as fully utilized as ISP A is currently. You could instead identify some specific paths that are heavy users or would carry a high percentage of the outgoing traffic, and use filters/route maps to adjust local preference of specific paths, to take outgoing load off ISP A. or increase the weight for 128.0.0.0/1 on routes received from ISP B, and allow your outgoing traffic to rest of the address space to utilize ISP A, for example. But the preferred fix for this problem would be to upgrade ISP A and ISP B links to at least double their current capacity. Weight is a vendor-specific parameter, local to your router. I would consider increasing the default local preference for ISP A first, by the way, But as long as you only have one router on which ISP A and ISP B sessions land, when you have an identical prefix from ISP A and B, the outgoing path through ISP B is to be preferred by your local router, if the path has a higher weight. " What suggest to this weight no. too? " With weights the magnitude of the numbers and the numerical difference between weights is not significant; it just matters if one path has a higher weight, or both paths have equal weight. I would suggest weights that are uniformly spaced apart and easy to remember, e.g. 100 200 300 400. When you want to add ISP C later, you will also have flexibility without re-assigning your existing weights. If this works, how is ISP B upstream connection is down?
Can it still be failover to ISP A automatically?
If it won't work, Do you have any suggestion?
Thank you for your help
-- -JH
participants (7)
-
Ann Kwok -
Fredy Kuenzler -
Jared Mauch -
Jimmy Hess -
Joel Maslak -
Justin M. Streiner -
Matthew Reath