Aggregate to a specific peer

Hey all,

Quick question, how can I send an aggregate to only 1 specific peer? I don't have any of my books handy and searching the internet hasn't yeilded any results.

Any hints will be greatly appreciated.

Find more posts tagged with

Comments

networker050184

What do you mean exactly? You want to send say a /23 to one provider and two more specific /24s to the other? You could use a prefix-list tied to a route-map or just to the neighbor.

burbankmarc

Well it's part of a lab, here's the specific task:

R2 should aggregate all the networks in 3 . 1 .0.0 address space and advertise a single
aggregate route that only aggregates the specific routes for subnets under the 3 .0.0.0
network in it's BGP table, ensure that the atomic-aggregate attribute is not attached to the
aggregate route. This aggregation should be configured such that R 1 in AS 1 00 is the
only AS that receives the aggregate route, R3 or future peer neighbors should NOT
receive the aggregate route. R 1 should use R2 as the next hop to reach any of the specific
routes within the aggregate, R I should NOT use R2 if it' s network 3 . 1 . 1 1 .0 124 network
is down. R3 does NOT need NLRI to network 3 . 1 . 1 1 .0 124 advertised by R 1 .

Here's an ascii of the network:

[R1]---------{FR}----------[R2]-------------[R3]

R1 has 3.1.11.0/24 and R3 has 3.1.0-15.0/24 minus 3.1.11.

So I know how to do all of the above except the bold

networker050184

Looks like its looking for the aggregate command with as-set.

burbankmarc

Right, but that will aggregate it for ever other peer, not just R1.

networker050184

The as-set should kick the loop prevention in for going to the AS in the as-set. You can use an as-path access-list or regular access-list with an advertise map I believe also to narrow it down to just one neighbor.

I'll have to actually lab it up a bit to get any more specific than that though.

burbankmarc

Well I've been playing around with it some more and the advertise-map just matches the prefixes you want to aggregate, which makes sense. I'm thinking I need to use an attribute-map but I'm still not exactly sure as to how.

deth1k

Create a summary/aggregate route, create a prefix list which would only allow that route to propagate, use that same prefix list in the neighbor statement outbound to R3, this will filter all other subnets (if summary-only is not used).
You can then filter this agregate on other routers or towards other AS'es.

networker050184

deth1k wrote: »

Create a summary/aggregate route, create a prefix list which would only allow that route to propagate, use that same prefix list in the neighbor statement outbound to R3, this will filter all other subnets (if summary-only is not used).
You can then filter this agregate on other routers or towards other AS'es.

That was my initial thought as well, but I'm not sure if thats what the lab is asking for. I'll try to mess around with it later if I have some time.

burbankmarc

deth1k wrote: »

Create a summary/aggregate route, create a prefix list which would only allow that route to propagate, use that same prefix list in the neighbor statement outbound to R3, this will filter all other subnets (if summary-only is not used).
You can then filter this agregate on other routers or towards other AS'es.

The lab makes it seem like you should be able to do all of this within the aggregate-address command, all though I may be off base on that one.

This guy did the lab but his solution didn't seem to work. I added another router to the mix and peered with R2, and the new router received the aggregate route as well.

Narbik adv wb BGP lab 5 – route aggregation Pete’s Packet

froggy3132000

Any restrictions?

Deny the aggregate from the other peers.

U then have the aggregate to only 1 peer.

burbankmarc

I'm convinced that that's the only way to achieve the desired results.

APA

sounds like as-set and perhaps a little bit of conditional route advertisement?

Did you get to lab this up at all?

Forsaken_GA

burbankmarc wrote: »

The lab makes it seem like you should be able to do all of this within the aggregate-address command, all though I may be off base on that one.

The best way I can think to do this would be to use a route-map to set the no-export community as part of the aggregate-address command, that should keep it from leaving the AS. And then just have a route-map pointing to that one particular neighbor to remove the no-export community, allowing it to be propagated out.

Forsaken_GA

Forsaken_GA wrote: »

The best way I can think to do this would be to use a route-map to set the no-export community as part of the aggregate-address command, that should keep it from leaving the AS. And then just have a route-map pointing to that one particular neighbor to remove the no-export community, allowing it to be propagated out.

Actually that's not going to work, the no-export will keep it from even being considered to be sent out, so it'll never hit the neighbor's route-map for the attribute to get stripped.

This is an interesting problem. Obviously you can do it with individual route maps to neighbors, just denying the aggregate to everyone it's not supposed to go to, but that can be an administrative nightmare. You wouldn't think trying to accomplish this with a minimum of configuration would be so tough.

How I would do it in real life is fairly simple - I already have a standard route map that I apply to peers to prevent things like RFC1918 space from getting leaked out, so I'd just duplicate that route map, apply it to the peer that needed the aggregate, then add the aggregate to the standard route map filter to prevent everyone else from getting the aggregate and that would accomplish the goal.

I don't think as-set is really part of this solution, unless I'm overthinking it. as-set wouldn't prevent the aggregate from going out to new peers unless the new peers were advertising a route that fell within the aggregate. If they weren't, then their AS would never appear in the set, so they'd get the aggregate.

burbankmarc

Hey all, it's been a while.

I never did solve this lab the way I wanted to. As forsaken said you can do this, but it involves a bit of administrative overhead.

I haven't been able to touch networking for a while now, I've been wrapped up in sysadmin stuff. However, I'm able to get back into it and will be going over this lab again, soon. I will post any progress I've made.