Scenario

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.

Topology

Ok, let’s assume the following. You are in control of an AS 100 and you want to advertise your prefix 11.12.12.0/22. You will use Internet address provided by your ISP to connect to the Internet but you will use your loopback address 11.12.12.254 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 21.22.23.0/30. They are in control of an AS 200 and the loopback address they use to establish the BGP session is 21.22.24.254.

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.

Challenges

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 21.22.23.2/30 ip address. Check if you can ping the other end, 21.22.23.1. 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 21.22.24.254.

Nexus011(config)#ip route 21.22.24.254/32 21.22.23.1 name ISP_BGP_Loopback

Ensure you can ping the 21.22.24.254 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.

Nexus011(config)#feature bgp

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 21.22.24.254.

Nexus011(config)#ip route 11.12.12.0/22 null 0

 Nexus011(config)#router bgp 100

 Nexus011(config-router)#router-id 11.12.12.254

 Nexus011(config-router)#address-family ipv4 unicast

 Nexus011(config-router-af)#network 11.12.12.0/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 21.22.24.254 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 11.12.12.254 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 11.12.12.254 update-source Loopback 0

 Nexus011(config-router-af)#neighbor 11.12.12.254 password cisconexus123

 Nexus011(config-router-af)#neighbor 11.12.12.254 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 11.12.12.254 ebgp-multihop 5

Route filtering

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 1.2.3.0/24 would match only the 1.2.3.4/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.

Inbound route-map

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 11.12.12.254 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.

Outbound route-map

In the outbound route-map you will define what will you send to your neighbor. In our case, only the prefix 11.12.12.0/22 needs to be advertised to the world. Create a prefix-list to define that prefix.

Ip prefix-list BGP_PEER_OUT permit 11.12.12.0/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 11.12.12.254 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 11.12.12.254 shutdown

Useful commands

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 11.12.12.254 advertised-routes

This very useful command will tell you which prefixes you are sending to your peer.

show ip bgp neighbor 11.12.12.254 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.