Aggregate plus more specific routes

In some cases, more-specific routes, in addition to the aggregate, need to be passed (leaked) to a neighbouring AS. This is usually done in a Customer AS multihomed to a single provider. The Provider AS that gets the more-specific routes from the Customer AS would be able to make a better decision about which way to reach the route within the Customer AS.

Setup: Network Topology & configuration as in Chapter 11 - Internet Routing Architectures. I will cover basics of configuration & theory of this example.

Our starting configuration will list the networks we wish to advertise via BGP. This is determined with the network command under BGP configuration.
Next, on each of the Customer AS EBGP routers, configure BGP to send the aggregate network.

Aggregate-address 172.16.0.0 255.255.0.0

Note that we have not included the "summary-only" option, so both the aggregate and more-specific will be advertised.

We have seen on the Aggregate only, suppressing more specific routes post, what we would expect to see in the neighbours BGP table, however, we would also now see the more specific routes.

What is important now is that these more-specific routes do not leak further into the Internet, upstream of the Provider AS. We will do this with the Community attribute.

With the "community: no-export" attribute the Customer AS Routers can instruct the Provider AS Routers to export only the aggregate and not the more-specific routes upstream. This reduces the Internet BGP Table as the Provider AS will only advertise aggregates for all the networks under its control.

Community No-Export Configuration:

Under our Customer AS BGP Configuration we first need to establish our Provider AS neighbours to receive community attribute advertisements.
By default, BGP community attributes are not advertised to peers. The "neighbour send-community" command enables the sending of BGP community attributes to BGP peers.

Neighbour 192.68.5.2 send-community

Then, we set up an access list to catch the addresses we are interested in.

access-list 101 permit ip 172.16.0.0 0.0.255.255 host 255.255.0.0

The host 255.255.0.0 makes sure nothing more-specific than 172.16.0.0 is let through.

Next, we set up a route-map to tag the more-specific routes with the community no-export attribute.

Route-map SETNOEXPORT permit 10
Match ip address 101
Route-map SETNOEXPORT permit 20
Set community no-export

Finally in our Customer AS BGP configuration we apply the route-map

Neighbour 192.68.5.2 route-map SETNOEXPORT out

All seems good and well and if you even run "show ip bgp" on an upstream (from the provider) router you might even get a nicely aggregated route to the 172.16.0.0 networks or you might not.

The reason routes could be leaking into the Internet is because the nature of the community attribute is that of an optional transitive attribute. This means we have to decide on each router whether we will pass the community attribute. As it stands, one of our multihomed routers in the Provider AS is passing on the routes to the Provider AS EBGP neighbor via IBGP and then if these are the best routes to the specific networks BGP will propagate these upstream.

Though my working example (yours may differ), the route being propagated upstream has the community attribute set. This is because that route so happens to be deemed as the best. However, the backup routes community is not set. If this alternative route were to become the best route, the more-specific route it describes would be propagated upstream. Bad!

I garnered this information by the command "sh ip bgp 172.16.20.0.0" ( a network in the aggregate I am advertising).

RTD>sh ip bgp 172.16.20.0
BGP routing table entry for 172.16.20.0/24, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to non peer-group peers:
192.68.6.2
3
192.68.5.1 from 192.68.5.1 (192.68.5.1)
Origin IGP, localpref 100, valid, external, best
Community: no-export
3
172.16.20.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, metric 0, localpref 100, valid, internal

See! The back up route does not have the community set. Bad!

On our BGP Neighbors in the Provider AS we need to propagate the community attribute to the Provider AS EBGP neighbour.

Neighbour 192.68.6.1 send-community

RTD>sh ip bgp 172.16.20.0
BGP routing table entry for 172.16.20.0/24, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to non peer-group peers:
192.68.6.2
3
192.68.5.1 from 192.68.5.1 (192.68.5.1)
Origin IGP, localpref 100, valid, external, best
Community: no-export
3
172.16.20.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, metric 0, localpref 100, valid, internal
Community: no-export
RTD>

See! Both routes are now part of the community. Good!