Thank you.... We've messed already with a number of the options as you mentioned - this is really a last resort from our viewpoint. ;) The upstream (AS3320) does not have good reach when going against our other upstreams/peering and we are locked in a contract so trying to hit our minimum commit with them as best as we can.
When we do some granular local-pref options it swings traffic around too "dramatically" - using communities doesn't seem to resolve it neither (would have thought it would actually)... Appreciate it, Paul -----Original Message----- From: Stephen Kratzer [mailto:[email protected]] Sent: Monday, June 08, 2009 10:39 AM To: [email protected] Cc: Paul Stewart Subject: Re: [c-nsp] BGP Advertising - Question re more specific block If the provider to which you are advertising a /22 is well-connected, I would suggest determining what communities they support and try having them bump local pref up for the /18 and removing the more specific advertisements. If that brings too much traffic in via that provider, consider advertising the /18 with default local pref, but advertising a few more specifics with either no-advertise or no-export communities. Doing so should force that provider to use the more specifics while keeping global routing table pollution to a minimum. And if either of these two approaches don't bring enough traffic in via this provider, try tweaking local pref (depreferencing) on other providers. I realize that this doesn't address your specific config question, but I think these approaches might be a bit better (more granular and nicer to the rest of us) than plain deaggregation. And yes, do as I say, not as I do. Stephen On Wednesday 03 June 2009 11:55:26 Paul Stewart wrote: > Hi folks. > > > > I'd like to know if there's a better way to approach this. > > > > We are advertising a specific /22 that belongs to a /18 block via one > specific upstream BGP connection. The /18 is advertised to all upstreams, > the /22 is only advertised to one upstream as a method of influencing > traffic via that carrier (knowing that if that particular carrier went > down, the less specific subnet will still be reachable via the other > providers). Prepending is very ugly for this situation FYI. > > > > We use BGP communities to identify upstream and downstream BGP connections > along with our own netblocks. > > > > First I built a route-map that I could use inside the BGP network > statement: > > > > route-map blahblah-routes-providerx permit 1000 > > set community 11666:6001 > > > > Then created the network statement: > > > > network xx.xx.xx.0 mask 255.255.252.0 route-map blahblah-routes-providerx > > > > Created a new IP community-list that includes previous communities plus > this one new specific community (11666:6001): > > > > ip community-list 101 permit 11666:4000 > > ip community-list 101 permit 11666:5000 > > ip community-list 101 permit 11666:6001 > > > > And, updated the route-map towards this upstream as applicable: > > > > route-map outbound-tsystems permit 10 > > match community 101 > > > > > > My question - is there a better way to configure this? This is working > just fine for our needs but there's a lot of steps and we're going to have > to add more into this in future so rather do as simple a config as possible > ;) > > > > Thanks, > > > > Paul > > > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
