BGP Route Filtering Lab - Route-maps

BGP Deployment Workshop

Introduction

This lab is the third in a series demonstrating how to filter BGP announcements between neighbouring ASes. Four techniques will be covered in this series: prefix-list, as-path filters, route-maps, and BGP communities.

Lab Topology

The following common topology is used for this lab.

Clean up

Before we start this lab, we need to clean up from the AS_PATH filter lab we just completed, ready to test the next example which introduces BGP Communities and route-maps.

The following shows what needs to be done in configuration mode:

router bgp 6450X
 address-family ipv4
  no neighbor <ebgp-peer> filter-list 1 out
  no neighbor <ebgp-peer> filter-list 2 in
 address-family ipv6
  no neighbor <ebgp-peer> filter-list 1 out
  no neighbor <ebgp-peer> filter-list 2 in
!
no ip as-path access-list 1
no ip as-path access-list 2
end

Replace the X and entries in <brackets> with the names you used.

Once you have done this, remember to do the Route Refresh on the EBGP sessions! (It’s simplest just to do clear bgp all <ext-AS> in and clear bgp all <ext-AS> out.) After that the full BGP table should be restored and you will see all the routes in the network again.

BGP Communities & Route-maps

This lab introduces the Router Teams to using BGP communities for tagging, identifying, and eventually filtering prefixes. We achieve similar end results to what we achieved in the previous steps using prefix-list and AS_PATH filters.

On all routers, configure BGP to send a community for all prefixes belonging to the local AS advertised to external BGP peers. The community should be in the form of [AS number]:[Router number]. For example, Router8 should use community 64503:8.

Here is a configuration of what Router8 could use to tag all prefixes its EBGP neighbour, Router6:

! Display communities in 16-bit:16-bit format rather than as one 32-bit integer.
!
ip bgp-community new-format
!
ip prefix-list AS64503-v4 permit 100.68.3.0/24 le 28
!
route-map AS64503-v4out permit 10
 match ip address prefix-list AS64503-v4
 set community 64503:8
!
ipv6 prefix-list AS64503-v6 permit 2001:DB8:3::/48 le 56
!
route-map AS64503-v6out permit 10
 match ipv6 address prefix-list AS64503-v6
 set community 64503:8
!
router bgp 64503
 address-family ipv4
  neighbor 100.68.2.8 remote-as 64502
  neighbor 100.68.2.8 route-map AS64503-v4out out
  neighbor 100.68.2.8 send-community
!
 address-family ipv6
  neighbor 2001:DB8:2:5:: remote-as 64502
  neighbor 2001:DB8:2:5:: route-map AS64503-v6out out
  neighbor 2001:DB8:2:5:: send-community
!

Use this example to design a configuration for your EBGP peering with your external neighbour.

Note that Router2 and Router9 have two EBGP neighbours, in different ASes. In this case we can use the same outbound route-map for each peering.

Once the configuration has been entered for the EBGP peer, refresh the BGP session with the EBGP peer, and then log in to your EBGP peer router (use SSH) and check that you see your community attached to your prefixes.

Note 1: A community attribute can be seen in the BGP table via the show ip bgp <network> and the show bgp ipv6 unicast <network> commands.

Note 2: A community attribute is a 32-bit field. By IETF agreed-upon convention it is divided into two 16-bit fields for easy interpretation. The top 16-bit contains the AS number, while the lower 16-bit represents an integer that has specific meaning to the two ASes involved in the peering. The exceptions to this are the well-known community attribute strings such as no-export or local-as.

Question: Why is send-community needed for EBGP peerings?

Answer: As community values are not passed by default between BGP peers by Cisco’s IOS, you need to tell the router explicitly to do this.

Confirmation

Once this community tag and route-map has been put in place, what do you see?

Yet again you should only see prefixes from your immediately adjacent ASes. You will no longer see any prefixes from ASes that are not directly connected. Which means:

AS64501 will no longer be able to see AS64503 (and vice-versa)
AS64502 will no longer be able to see AS64504 (and vice-versa)

Confirm that this is indeed the case.

Question: Why have has this scenario ended up filtering routes between ASes again?

Answer: Because of the route-map. Route-maps have a default deny - so if there is no match found, any other prefix is immediately dropped by the route-map. And because the adjacent AS was only matching its own prefixes to add the community, all other prefixes were dropped.