[c-nsp] BGP Advertising - Question re more specific block

[Paul Stewart]

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:kratzers at pa.net] 
Sent: Monday, June 08, 2009 10:39 AM
To: cisco-nsp at puck.nether.net
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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/