BGP outbound route filtering

On September 12, 2012, in CCIE, Juniper, by Darren

BGP ORF is a powerful feature that relieves both the ISP and their BGP customers from time wasting and headaches. It can also be used to do some pretty complicated MPLS L3VPN stuff, but let’s keep this post relatively simple.

Let’s us the following simple topology for this post:
ORF 1 BGP outbound route filtering

Let’s say that R2 is a customer of R1. R1 is is a Tier 1 ISP with the full global routing table. R2 has bought IP transit from both R1 and another company. R2 has a choice of what BGP table to receive from the ISP. Should I take the full routing table? Should I take just a default?
Maybe a default and a few other prefixes? With the full table, I can do all kinds of load-sharing and I can ensure that my traffic will always take the shortest as-path.
On the other hand I could simple take defaults from both. That way my routers only need to hold a single default, but my routers don’t really know the best path for anything.
I can also ask both ISPs to send me a default plus a few more specifics.

Of course the problems with the first is that my edge routers need to hold the entire BGP table. The second option I am extremely limited in sending my outbound traffic via the best path. The final option seems the best, but what if I wanted to change which routes the ISP is sending me? I would have to submit a request for them to do so, and who knows how long until they make that change. Most ISPs will not even do this for you anyway.

You could take the entire BGP table and then run that through a filter blocking everything you didn’t want. That works but it’s a waste. Let’s say you want 100 prefixes. The ISP’s router will have to send all 500k IPv4 prefixes to you, only for you to filter out all but 10 of them. This is not efficient for both the ISPs and your own router. Sending the entire table also takes a few minutes.

Enter OutBound Route Filtering (ORF) – Effectively this allows you the customer to ‘configure’ the ISPs router to only send you what you want. At any time you can update the filter on your local box and that change is fed to the ISPs box. Let’s see this in action.

R1 has 9 loopbacks, 1.1.1.1 to 9.9.9.9. It’s also sending a default route. Standard config is like so:

R1
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 200
 !
 address-family ipv4
  network 1.1.1.0 mask 255.255.255.0
  network 2.2.2.0 mask 255.255.255.0
  network 3.3.3.0 mask 255.255.255.0
  network 4.4.4.0 mask 255.255.255.0
  network 5.5.5.0 mask 255.255.255.0
  network 6.6.6.0 mask 255.255.255.0
  network 7.7.7.0 mask 255.255.255.0
  network 8.8.8.0 mask 255.255.255.0
  network 9.9.9.0 mask 255.255.255.0
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 default-originate
 exit-address-family
R2
router bgp 200
 bgp log-neighbor-changes
 neighbor 10.0.0.0 remote-as 1
 !
 address-family ipv4
  neighbor 10.0.0.0 activate
 exit-address-family


R2#sh ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.0.0.0                               0 1 i
*> 1.1.1.0/24       10.0.0.0                 0             0 1 i
*> 2.2.2.0/24       10.0.0.0                 0             0 1 i
*> 3.3.3.0/24       10.0.0.0                 0             0 1 i
*> 4.4.4.0/24       10.0.0.0                 0             0 1 i
*> 5.5.5.0/24       10.0.0.0                 0             0 1 i
*> 6.6.6.0/24       10.0.0.0                 0             0 1 i
*> 7.7.7.0/24       10.0.0.0                 0             0 1 i
*> 8.8.8.0/24       10.0.0.0                 0             0 1 i
*> 9.9.9.0/24       10.0.0.0                 0             0 1 i

So far everything is expected. However I now want to receive the default route, but also 4.4.4.4/24 and 8.8.8.8/24 – nothing else. The first thing we need to do is enable ORF. Note that this can be set to ‘receive’, ‘send’, or ‘both’. This ensures that only certain routers control certain others. Note also that when you configure this, the BGP session resets.

R1
router bgp 1
 address-family ipv4
  neighbor 10.0.0.1 capability orf prefix-list receive
R2
router bgp 200
 address-family ipv4
  neighbor 10.0.0.0 capability orf prefix-list send

Note that ‘receive’ is for the router sending the routes while ‘send’ is for the router receiving the routes. The send and receive keywords are for sending and receiving the prefix-lists, not the routes themselves.

So now on R2 let’s create a prefix-list specifying what we want and apply that to our neighbour:

ip prefix-list ROUTES_WANTED seq 5 permit 0.0.0.0/0
ip prefix-list ROUTES_WANTED seq 10 permit 4.4.4.0/24
ip prefix-list ROUTES_WANTED seq 15 permit 8.8.8.0/24
!
router bgp 200
 address-family ipv4
  neighbor 10.0.0.0 prefix-list ROUTES_WANTED in

R2#sh ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.0.0.0                               0 1 i
*> 4.4.4.0/24       10.0.0.0                 0             0 1 i
*> 8.8.8.0/24       10.0.0.0                 0             0 1 i

If you run a debug you’ll see that R2 is not receiving and then rejecting prefixes, it’ simply doesn’t see them. You can actually see this from R1′s perpective:

R1
R1#sh ip bgp neighbors 10.0.0.1 received prefix-filter 
Address family: IPv4 Unicast
ip prefix-list 10.0.0.1: 3 entries
   seq 5 permit 0.0.0.0/0
   seq 10 permit 4.4.4.0/24
   seq 15 permit 8.8.8.0/24

Now you want the 5.5.5.0/24 prefix? The customer only needs to update his prefix-filter:

R2
R2(config)#ip prefix-list ROUTES_WANTED seq 20 permit 5.5.5.0/24

R2#clear ip bgp * soft in prefix-filter 

R2#sh ip bgp | begin Network            
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.0.0.0                               0 1 i
*> 4.4.4.0/24       10.0.0.0                 0             0 1 i
*> 5.5.5.0/24       10.0.0.0                 0             0 1 i
*> 8.8.8.0/24       10.0.0.0                 0             0 1 i
R1
R1#sh ip bgp neighbors 10.0.0.1 received prefix-filter 
Address family: IPv4 Unicast
ip prefix-list 10.0.0.1: 4 entries
   seq 5 permit 0.0.0.0/0
   seq 10 permit 4.4.4.0/24
   seq 15 permit 8.8.8.0/24
   seq 20 permit 5.5.5.0/24

You specify ORF filters and capability on a per address-family basis. So you can use the same technique to filter IPv6 unicast, IPv6 multicast, IPv4 multicast, etc

Of course JunOS can do the exact same thing. Let’s replicate the topology above and do the same thing. Note that when you set this up between IOS and JunOS, you need to tell JunOS to use the Cisco format:

JunOS
darren> show configuration protocols bgp
group EXTERNAL {
    neighbor 10.0.10.1 {
        peer-as 100;
        outbound-route-filter {
            bgp-orf-cisco-mode;
            prefix-based {
                accept {
                    inet;
                }
            }
        }
    }
}

darren> show bgp neighbor orf 10.0.10.1 detail
Peer: 10.0.10.1+179   Type: External
  Group: EXTERNAL

  inet-unicast
    Filter updates recv:          4 Immediate:          1
    Filter: prefix-based            receive
            Updates recv:          4
      Received filter entries:
        seq 5 /0 permit minlen 0 maxlen 0
        seq 10 4.4.4.0/24 permit minlen 0 maxlen 0
        seq 15 8.8.8.0/24 permit minlen 0 maxlen 0
        seq 20 5.5.5.0/24 permit minlen 0 maxlen 0

darren> show route advertising-protocol bgp 10.0.10.1

inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 4.4.4.0/24              Self                                    2 ?
* 5.5.5.0/24              Self                                    2 ?
* 8.8.8.0/24              Self                                    2 ?

This is an very powerful way to easily let one router tell another what routes to send it, instead of just dropping it. Great for regular and MPLS-based BGP

Tagged with:  

Using an extended ACL as a prefix-list

On March 26, 2012, in CCIE, by Darren

This will be a short post.

I’ve mentioned it before, but let’s say you have a task which requires you to filters updates through a route-map. For some reason the task states you’re only allowed to use an ACL, not a prefix-list.

You are able to use an extended ACL as a prefix list.

Let’s use this simple topology:
extended ACL Using an extended ACL as a prefix list

R1 has a bunch of loopbacks. R1 and R2 are running EIGRP with each other. I’ve configured R1 to redistribute all connected routes into EIGRP.

R1′s loopbacks:

interface Loopback2
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip address 3.3.3.3 255.255.255.248
!
interface Loopback4
 ip address 4.4.4.4 255.255.255.0
!
interface Loopback5
 ip address 5.5.5.5 255.255.255.255
!
interface Loopback6
 ip address 5.5.5.50 255.255.255.248

R2 sees all of these EIGRP routes in it’s RIB:

R2#show ip route eigrp
     2.0.0.0/24 is subnetted, 1 subnets
D EX    2.2.2.0 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
     3.0.0.0/29 is subnetted, 1 subnets
D EX    3.3.3.0 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
     4.0.0.0/24 is subnetted, 1 subnets
D EX    4.4.4.0 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
     5.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D EX    5.5.5.5/32 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
D EX    5.5.5.48/29 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0

Now the task states that I need to ensure 5.5.5.48/29 is redistributed, but not 5.5.5.5/32 – I’m not allowed to use a prefix-list and I’m not allowd to use a route-map that matches an interface.

If we then use a regular ACL, we’ll end up redistributing 5.5.5.5/32 as well if we’re not careful. What actually happens if the tasks says we need to redistribute all subnets that are /29 only. This would be 3.3.3.3/29 and 5.5.5.5.48/29

The simple answer is the extended list. Let’s do all /29s:

access-list 150 permit ip host 3.3.3.0 host 255.255.255.248
access-list 150 permit ip host 5.5.5.48 host 255.255.255.248
!
route-map SLASH29 permit 10
 match ip address 150
!
router eigrp 1
 redistribute connected metric 1 1 1 1 1 route-map SLASH29

Basically the ‘source’ becomes the IP address and the ‘destination’ becomes the subnet mask.

Does it work? Let’s take a look:
R2:

R2#sh ip route eigrp
     3.0.0.0/29 is subnetted, 1 subnets
D EX    3.3.3.0 [170/2560002816] via 1.1.1.1, 00:02:12, FastEthernet0/0
     5.0.0.0/29 is subnetted, 1 subnets
D EX    5.5.5.48 [170/2560002816] via 1.1.1.1, 00:01:30, FastEthernet0/0

So yes it works just fine. But really in the real world you would be using the far more powerful prefix-list…

Tagged with:  

MPLS VPN lab #4

On May 14, 2010, in CCIE, Dynamips, by Darren

The diagram is the same as my last VPN Lab. Also it uses my MPLs topology found over here: http://mellowd.co.uk/ccie/?p=522

This is the topology for this lab (click for a bigger image):

MPLS4 small MPLS VPN lab #4

  • Customer1 and Customer 2 both have MPLS vpn’s through the ISP core.
  • Customer1 is using OSPF and Customer2 is using EIGRP
  • Customers should have no access to each others networks
  • Customers should be able to reach all their sites from all their sites
  • The ISP wants to monitor the CPE routers via their monitoring server. Create another loopback on each CPE router and give them all a /32 loopback in the 172.16.1.1/24 range – i.e. 172.16.1.1/32 for CPE1, 172.16.1.2/32 for CPE2 and so on
  • Ensure the monitoring router can get to all these /32 routes (and ONLY these /32 routes) – It should not know about any customer routes – CPE routers should only see their OWN loopbacks in the routing table
  • Now enable CPE3 and CPE6 to see each others subnets. All other CPE routers should see no change in their routing tables
Tagged with:  

Access-lists vs Prefix-lists

On January 6, 2010, in CCIE, Uncategorized, by Darren

The main purpose of this post is to show how prefix lists work and how to decipher them vs regular access lists.  Access-lists do a great job on Cisco devices, not just for security but all kinds of route filtering,  QoS and so on.

A prefix list is a bit different form an access-list, and it’s important to know the differences and when to use either.

I’ve created the following simple topology to illustrate what I’m going to be doing. There are 2 routers, both running BGP. Router1 will have numerous loopbacks with IP addresses that will be advertised into the BGP process. On router2 I’ll use various access-lists and prefix-lists to see what kind of results I get. Remember though that prefix-lists can be used with other routing protocols and not just BGP.

This is the topology (Click for the full view):

Prefix lists 150x150 Access lists vs Prefix lists

This is the config on each:

R1#sh run | begin bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.1.1.10 remote-as 200
 no auto-summary
R2#sh run | begin bgp
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.9 remote-as 100
 no auto-summary

I’ll put the following subnets on R1 and advertise them in BGP:

  • 192.168.1.1/24
  • 192.168.2.1/24
  • 192.168.3.1/25
  • 192.168.3.129/25
  • 192.168.4.1/25
  • 192.168.4.129/26
  • 192.168.4.193/26
#R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback2
 ip address 192.168.2.1 255.255.255.0
!
interface Loopback3
 ip address 192.168.3.1 255.255.255.128
!
interface Loopback4
 ip address 192.168.3.129 255.255.255.128
!
interface Loopback5
 ip address 192.168.4.1 255.255.255.128
!         
interface Loopback7
 ip address 192.168.4.129 255.255.255.192
!         
interface Loopback8
 ip address 192.168.4.193 255.255.255.192

This is R1′s BGP config now:

R1#sh run | begin bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0 mask 255.255.255.128
 network 192.168.3.128 mask 255.255.255.128
 network 192.168.4.0 mask 255.255.255.128
 network 192.168.4.128 mask 255.255.255.192
 network 192.168.4.192 mask 255.255.255.192
 neighbor 10.1.1.10 remote-as 200
 no auto-summary

On Router2, we can see the routes advertised:

R2#sh ip bgp 
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.3.0/25   10.1.1.9                 0             0 100 i
*> 192.168.3.128/25 10.1.1.9                 0             0 100 i
*> 192.168.4.0/25   10.1.1.9                 0             0 100 i
*> 192.168.4.128/26 10.1.1.9                 0             0 100 i
*> 192.168.4.192/26 10.1.1.9                 0             0 100 i

Let’s say I want to filter out the network 192.168.4.0/25. If I use an access-list I need to do it as follows. Create the access list:

R2#conf t
R2(config)#access-list 5 deny   192.168.4.0 0.0.0.127
R2(config)#access-list 5 permit any

Add a rule to the BGP config:

R2#sh run | begin bgp
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.9 remote-as 100
 neighbor 10.1.1.9 distribute-list 5 in
 no auto-summary

You can see that the 192.168.4.0/25 route has now been filtered out:

R2#sh ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.3.0/25   10.1.1.9                 0             0 100 i
*> 192.168.3.128/25 10.1.1.9                 0             0 100 i
*> 192.168.4.128/26 10.1.1.9                 0             0 100 i
*> 192.168.4.192/26 10.1.1.9                 0             0 100 i

Let’s say I wanted to filter out the 192.168.4.x/26′s as well. In order to do so I’d have to add another line for each network in my access-list. With a prefix-list it’s much easier to do this. Let’s remove the access-list and start again. NB: Prefix-lists, like access-lists, have a implicit DENY at the end. In an ACL you’ll place a permit any at the end. The prefix-list version of this is to permit 0.0.0.0/0 le 32
First I’ll create the prefix-list:

R2(config)#ip prefix-list exclude_4 seq 5 deny 192.168.4.0/24 ge 25 le 26
R2(config)#ip prefix-list exclude_4 seq 10 permit 0.0.0.0/0 le 32

Now I’ll apply it to the BGP process:

router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.9 remote-as 100
 neighbor 10.1.1.9 prefix-list exclude_4 in
 no auto-summary

When checking the BGP table I see the following:

R2#sh ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.3.0/25   10.1.1.9                 0             0 100 i
*> 192.168.3.128/25 10.1.1.9                 0             0 100 i

You can see that all the 192.168.4.1/25 and /26s are gone thanks to the prefix-list.

The basics of the prefix list is as follows. If I write

ip prefix-list exclude_4 seq 5 deny 192.168.4.0/24 ge 25 le 26

The /24 tells the IOS to match only the first 24 bits. i.e. 192.168.4 – I then tell the IOS to match only those prefixes that have a subnet mask of /25 or /26. i.e. If I had another network advertised which was 192.168.4.200/27 it would NOT match as even though the 192.168.4 part matches, it has a subnet mask of /27

Let’s say I wanted to now match 192.168.x.x/25 but I wanted to leave the /26′s in place. This would be easy with a prefix list as follows:

R2(config)#ip prefix-list exclude_4 seq 5 deny 192.168.3.0/16 ge 25 le 25 
R2(config)#ip prefix-list exclude_4 seq 10 permit 0.0.0.0/0 le 32

I’ve told the IOS to only match on the first 16 bits, i.e. 192.168 – I then told IOS to only match those prefixes that have a subnet mask of /25. If I apply this to my BGP process I can see that it works as expected:

R2#sh ip bgp          
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.4.128/26 10.1.1.9                 0             0 100 i
*> 192.168.4.192/26 10.1.1.9                 0             0 100 i

Only the 3 /25′s have disappeared, everything else is still there.

You can also do all of this with extended access-lists, but it’s so much more work, why make life difficult? Once you understand the context of prefix-lists it becomes very easy

© 2009-2014 Darren O'Connor All Rights Reserved