[nsp] bgp - aggregates and specific routes

[joshua sahala]

On (14/07/04 12:02), Roger wrote:
> To: cisco-nsp at puck.nether.net
> From: Roger <grunky at rockriver.net>
> Date: Wed, 14 Jul 2004 12:02:52 -0500
> Subject: [nsp] bgp - aggregates and specific routes
> 
> I have a question reguarding BGP aggregate routes and more specific 
> routes. Currently we have 2 WAN links w/ large carriers running eBGP, we 
> advertise our /19 aggregate, example 192.168.0.0/19.

 ok so far
 
> A customer of ours, who's range is say 192.168.16.0/24 will be using our 
> numbers and advertising said route to other eBGP peers.

 your numbers?

> My question is - if the link between us and our customer at 16.0/24 goes 
> down we need to advertise that 16.0/24 as invalid while still 
> advertising our /19. The customer w/ the 16.0/24 should still be 
> connected via their other eBGP links.

 how are you learning the /24?  if you are learning it from your
 customer, then when the link goes down, you will stop learning that
 prefix and will subsequently stop advertising it.  if you are
 learning it via some other means, then i'd need to know how that is
 to answer this.
 
> How would I do this? Currently my BGP setup is like so. Now if the 
> 16.0/24 peering session goes down traffic will still flow because it 
> will be lumped into our /19.

 /24 is more specific than /19, so for addresses in that /24, traffic
 will go towards your customers other providers.  all other traffic
 for the /19 will come to you

> 
> router bgp 1
> no synchronization
> bgp log-neighbor-changes
> network 192.168.0.0 mask 255.255.224.0
> neighbor 1.2.3.4 remote-as 1234
> neighbor 1.2.3.4 description WAN Link 1
> neighbor 1.2.3.4 send-community
> neighbor 5.6.7.8 remote-as 5678
> neighbor 5.6.7.8 description WAN Link 2
> neighbor 5.6.7.8 send-community
> neighbor 192.168.16.254 remote-as 2
> neighbor 192.168.16.254 description downstream customer
> neighbor 192.168.16.254 send-community
> !
> ip route 192.168.0.0 255.255.224.0 Null0

this looks good - make sure that you are using some prefix filters
and/or as path filters to prevent readvertising prefixes that you do
not want to provide transit for ;-)

/joshua
-- 
A common mistake that people make when trying to design something 
completely foolproof is to underestimate the ingenuity of complete
fools.
	- Douglas Adams -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20040714/9229832f/attachment.bin