Let’s consider a typical real-world BGP scenario: peering with your ISP.
Maybe you don’t have a powerful enterprise router or maybe you want to save the device’s resources, but chances are you’d want your ISP to send you only a default route.
But what happens if your ISP Network Engineer accidentally forgets to filter their outbound route-map properly? Cisco Nexus switches shouldn’t pass away if they mistakenly receive a full routing table. But if you are using a smaller or overburdened router, you can expect smoke to come out of it when the BGP starts its calculations.
Luckily, you can and will use PBR (Policy Based-Routing) to configure your BGP session to not allow anything but the default route from that neighbor. If you are unsure, like I was before, I will show you how.
Ok, let’s assume the following. You are in control of an AS 100 and you want to advertise your prefix 220.127.116.11/22. You will use Internet address provided by your ISP to connect to the Internet but you will use your loopback address 18.104.22.168 as your BGP peering address. Lastly, you plan to have a multi-homed setup in the future and you want your peer ID to be always up. Or you just like to follow best practices.
Subnet provided by your ISP is 22.214.171.124/30. They are in control of an AS 200 and the loopback address they use to establish the BGP session is 126.96.36.199.
You can also ask your ISP to configure the BGP with the password set. This is useful as a defense from certain types of hacks. You agreed with your ISP to use the unbreakable cisconexus123 password.
There are a couple of challenges to overcome in this setup.
To be able to send your prefix to your ISP and the world, you first need to advertise it with network command under the router BGP sub-configuration mode. You also need to have an entry in your routing table for that prefix. A Static route to the null interface is used for this purpose.
Also, chances are you won’t have a route to your ISP’s loopback address. Why would you, anyway? That’s why you first need to have a route to your ISP’s loopback in your routing table. Static route to the loopback interface is commonly used here.
Also, you need to overcome the default BGP behavior which is to have its TTL set to 1. That means it will drop the packet if it doesn’t reach the destination after the first hop. And the loopback interface is two hops away, right? So, we use ebgp-multhop command to change this behavior.
Last, but not least, you want to make sure you’ll receive a default route only from your ISP.
Let’s get to work.
Basic BGP configuration
Of course, the first step is to configure the interface towards your ISP and set the ip address on it. You will use 188.8.131.52/30 ip address. Check if you can ping the other end, 184.108.40.206. If successful, proceed. If not, prepare for a nightmare with your Fiber Optics Technicians.
Now, you need to make sure you have connectivity to your ISP’s loopback address 220.127.116.11.
Nexus011(config)#ip route 18.104.22.168/32 22.214.171.124 name ISP_BGP_Loopback
Ensure you can ping the 126.96.36.199 ip address.
If you succeed in these checks, you are now ready to configure your BGP process.
While BGP is enabled by default in Cisco IOS, in NX-OS you should enable it first. In the global configuration mode, issue the feature bgp command.
Advertising a network
Now, let’s configure the BGP process. We’ll assign a router-id and then advertise our network. But to install the route to our routing table, we first need to create a static route to null interface. Remember, you need to exactly match your routing table entry with the network command for the route to be accepted by your BGP process. You will likely need a route to your ISP’s loopback address 188.8.131.52.
Nexus011(config)#ip route 184.108.40.206/22 null 0 Nexus011(config)#router bgp 100 Nexus011(config-router)#router-id 220.127.116.11 Nexus011(config-router)#address-family ipv4 unicast Nexus011(config-router-af)#network 18.104.22.168/22
Configuring a BGP neighbor
Let’s configure the peering itself. The minimum needed to establish the BGP session is to specify a neighbor AS under the neighbor command. Also, it’s a good idea to give your peering a description. It speeds up the locating and troubleshooting if you have more than one BGP neighbor.
Nexus011(config-router-af)#neighbor 22.214.171.124 remote-as 200 Nexus011(config-router-af)#neighbor description BGP_ISP_1
I also like to issue the shutdown command first, configure all the commands first, and then turn it on. That way you avoid the possibility to receive a full routing table while you are setting up filters. By default, if no filtering is configured, neighbors will exchange all their routes, and that is what we are trying to avoid from the beginning.
Nexus011(config-router-af)#neighbor 126.96.36.199 shutdown
The neighbor is now administratively shut. Next, we’ll specify the update-source, password and, finally, inbound and outbound route-maps. We’ll also add the soft-reconfiguration inbound command. That command will allow you to make a soft reset of a BGP peer in both directions. This is useful if you make changes to your routing policies but you don’t want to tear the BGP session to allow the updates to happen.
Nexus011(config-router-af)#neighbor 188.8.131.52 update-source Loopback 0 Nexus011(config-router-af)#neighbor 184.108.40.206 password cisconexus123 Nexus011(config-router-af)#neighbor 220.127.116.11 soft-reconfiguration inbound.
Anything missing? Yes. We still didn’t overcome the default BGP TTL of 1. We’ll issue the ebgp-multihop 5 command. The number indicates the number of hops to the peer ip address. Although your ISP’s loopback interface is only one hop away, let’s be generous here, and allow five.
Nexus011(config-router-af)#neighbor 18.104.22.168 ebgp-multihop 5
Great. Now we almost configured everything. But still, we have an important task of creating prefix lists and matching them in route-maps. While this may sound complicated and intimidating at the beginning, once you really understand how prefix lists and route-maps work, all of this start to make sense.
Prefix lists are like access lists. You will use them to define which networks you will send to your ISP (or any other neighbor) and which routes you will allow from the neighbor.
Prefix lists match what you tell them to match. It’s that simple. A command like ip prefix-list LIST permit 22.214.171.124/24 would match only the 126.96.36.199/24 route (if found in the routing table). It’s possible to use le (less than or equal to) and ge (greater than or equal to), to have more matching flexibility.
After you configure prefix lists, you match them in route-maps. Then you apply those route-maps in the inbound or outbound direction.
You first need to define inbound route-map. Inbound route-map filter prefixes coming from your neighbor, in the IN direction. Since you want to allow only the default route to be installed in your routing table, you must configure an appropriate prefix list.
Ip prefix-list BGP_PEER_IN permit 0.0.0.0/0
Then match it in the route map
Nexus011(config)#route-map BGP_PEER_IN permit 10 Nexus011(config-route-map)#match ip address prefix-list BGP_PEER_IN Nexus011(config-route-map)#exit
And apply it to the neighbor.
Nexus011(config)#router bgp 100 Nexus011(config-router)# address-family ipv4 unicast Nexus011(config-router-af)#neighbor 188.8.131.52 route-map BGP_PEER_IN in
Your default route is now configured. Now, even if your neighbor accidentally sends you the whole routing table, you will filter all 650,000+ routes, installing the default route only.
In the outbound route-map you will define what will you send to your neighbor. In our case, only the prefix 184.108.40.206/22 needs to be advertised to the world. Create a prefix-list to define that prefix.
Ip prefix-list BGP_PEER_OUT permit 220.127.116.11/22
Now match it in your route-map.
Nexus011(config)#route-map BGP_PEER_OUT permit 10 Nexus011(config-route-map)#match ip address prefix-list BGP_PEER_OUT Nexus011(config-route-map)#exit
And apply it in the outbound direction.
Nexus011(config)#router bgp 100 Nexus011(config-router)# address-family ipv4 unicast Nexus011(config-router-af)#neighbor 18.104.22.168 route-map BGP_PEER_OUT out
That’s it. Your neighbor is now set. Your inbound route-map will allow only the default route to be accepted by your router. Your outbound route-map is advertising only your own network to the ISP.
If you followed the instructions, and configured along the way, live or in the lab, maybe you are wondering why it’s not working? We issued the shutdown command, remember.
Simply negate the command and you are good to go. Sit back, relax and watch the magic happen.
Nexus011(config-router-af)#no neighbor 22.214.171.124 shutdown
If you want to check if the neighbor adjacency is formed, you can run an sh ip bgp summary command. Keep in mind that Active state is not good. It does not mean BGP neighbor is running as I naively assumed. You will know the BGP session is up if you see a number in the State field. The number is telling us how many routes are learned from that neighbor. In our case, you should see 0, indicating you are receiving a default route only, and no prefixes.
show ip bgp neighbor 126.96.36.199 advertised-routes
This very useful command will tell you which prefixes you are sending to your peer.
show ip bgp neighbor 188.8.131.52 received-routes
This will tell you which prefixes you received from your peer. You should see 0 prefixes.
In my next BGP post I’ll talk about a multi-homed setup with your Nexus switches and how can you modify BGP various attributes to influence the routing.
Thank you to Filip Knezevic for his contributions to this article.