[f-nsp] BGP insight required

[Vinny_Abello at Dell.com]

Filter using prefix-lists for routes received from your customer based on
your policies and what you have verified they are permitted to announce to
you. For IPv4, le 24 is all that’s really going to be useful if you will be
announcing it to any up streams or peers as anything greater than /24 is
usually filtered out. Tag the customer routes with one or more communities
as well so you can easily propagate it elsewhere using those communities.
And for everything else, use communities. Trying to maintain prefix-lists
everywhere for what you are announcing to your customers will make you go
insane and does not scale. Identify prefixes as they enter your network with
communities so you can then advertise those networks with your customers.
Use prefix-lists in route-maps along with the communities if you want to
adjust prefix-length.

 

-Vinny

 

From: foundry-nsp-bounces at puck.nether.net
[mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Muhammad
Sent: Friday, May 20, 2011 2:58 PM
To: foundry-nsp at puck.nether.net
Subject: [f-nsp] BGP insight required

 

Dear list,

 

I would like to request an insight from some professionals.

 

I am administering two independent networks, each running an own AS and each
network consisting of two MLX-4, each router has two upstreams peers and one
session between them. Some far all worked just well for years.

 

For some reasons, these two networks are now being merged into one for
global IP Transit for saving on costs but each will keep its total autonomy
(local peering, etc.). The routes toward Tier-1 will be only sent thru the
second network, while some local peering will be kept by the first network,
thus servicing internally and leveraging on the savings of the second
network.

 

Therefore it means that one of the routers in the second network will become
the upstream peer of the first network router. So far all seems easy, one
BGP session and routes will be sent toward upstreams Tier-1 providers.

 

But here comes the trick with me. I have never set a session with a
downstream as this wasn’t my business until a few days. I am bit puzzled
about how to adapt my route-maps and ACLs prefix lists.

 

1) What should my route-maps/prefix-list consist of if I am sending a
full-route to the downstream?

 

Ø I imagine I will have an empty statement in the route-map toward the peer?
(for sending ALL routes) If not, what should my ACL be?

 

2) What should my route-maps/prefix-list consist of if I am accepting only
two prefixes from my downstream peer?

 

Ø I also imagine having a filter on incoming routes based on a prefix-list
that will ONLY accept the prefixes that matches the downstream’s prefixes?
But should I also filter it against bogons?

 

3) Am I just adding these two prefixes to the current prefix-list that I
send to my upstreams peers, or should I make a new one?

 

Ø I imagine I will just add these prefixes to the current prefix-list
currently used for my announced prefixes? Maybe should I have a prefix-list
for my downstream prefixes but I have no clue about how to concatenate them
together


 

I may have to merge additional peers later with the same concept so I am
looking for some relevant remarks and good practice with prefix-list and
route-map. There’s no community implied in this BGP design between the two
networks. Upstreams filters have been updated.

 

Much thanks in advance.

 

BR.

Muhammad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20110523/10ae7474/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4991 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20110523/10ae7474/attachment.p7s>