Chapter 7 Troubleshooting BGP

Cisco certification training

Instructor:- ASHOK TAMBE

Contact us :- 9930157345 ashok tambe

Training for

CCNA,CCNP,

CCNA SECURITY

CCIP,

MPLS, BGP, IPV6

NETWORK+, SEURITY+

Instructor:- ASHOK TAMBE

Cisco certification training

Copyright© 2013 NETworkingWANschool

https://www.facebook.com/Networkingwanschool

CCNP TSHOOT 642-832


ASHOK TAMBE

CCNP TSHOOT 642-832

[email protected]

Troubleshooting BGP


ASHOK TAMBE

CCNP TSHOOT 642-832

BGP is a complex routing protocol and there are many things that could go possibly wrong. Besides being complex it’s also completely different compared to our IGPs (OSPF and EIGRP). In this chapter we’ll start with troubleshooting BGP neighbor adjacencies and once that’s working we’ll look at issues with route advertisements that should or should not show up!

Troubleshooting BGP


ASHOK TAMBE

CCNP TSHOOT 642-832 Trouble ticket 1

We’ll start with some easy scenarios. Two BGP routers which are connected and configured for EBGP. Unfortunately we are seeing this when check the BGP neighbor adjacency


ASHOK TAMBE

CCNP TSHOOT 642-832

When 2 EBGP routers that are directly connected do not form a working BGP neighbor adjacency there could be a number of things that are wrong: • Layer 2 down preventing us from reaching the other side. • Layer 3 issue: wrong IP address on one of the routers. • Access-list blocking TCP port 179 (BGP). • Wrong IP address configured for BGP neighbor router.

We can use the show ip bgp summary command to check the IP addresses of the routers, these seem to match

I can do a quick ping and I’ll see that I’m unable to reach the other side.


ASHOK TAMBE

CCNP TSHOOT 642-832

We’ll check the interfaces and find out that someone left a shutdown command on the interface (DOH!).

Awake the interface…

That’s what we like to see. Our BGP neighbor adjacency is established…told you this one would be easy ;) Lesson learned: Make sure your interfaces are up and running.


ASHOK TAMBE


The next scenario is similar but slightly different. We are using the same routers and AS numbers but this time the BGP neighbor adjacency has to be established between the loopback interfaces

Let me show you what the BGP configuration looks like:

Here’s the BGP configuration, you can see that we are using the loopback interfaces to establish a BGP neighbor adjacency


ASHOK TAMBE

CCNP TSHOOT 642-832

Both routers show their BGP neighbor as idle. There are a number of things we have to check here: • Is the IP address of the BGP neighbor reachable? We are not using the directly connected links so we might have routing issues. • The TTL of IP packets that we use for external BGP is 1. This works for directly connected networks but if it’s not directly connected we need to change this behaviour. • By default BGP will source its updates from the IP address that is closest to the BGP neighbor. In our example that’s the FastEthernet interface. This is something we’ll have to change


ASHOK TAMBE

CCNP TSHOOT 642-832

We’ll start with the routing. Both routers only know about their directly connected networks. In order to reach each other’s loopback interfaces we’ll use static routing.

Two static routes should do the job.

Sending a ping to IP address 2.2.2.2 and sourcing it from my own loopback interface proves that both routers know how to reach each other’s loopback interface.

Use the update-source command to change the source IP address for the BGP updates


ASHOK TAMBE

CCNP TSHOOT 642-832

The ebgp-multihop command changes the TTL to 2.

We can enable a debug to see the progress. You can clearly see that R2 is using IP address 192.168.12.2 and that R1 is refusing the connection.


ASHOK TAMBE

CCNP TSHOOT 642-832

There goes! A working BGP neighbor adjacency Lesson learned: BGP routers don’t have to establish a neighbor adjacency using the directly connected interfaces. Make sure the BGP routers can reach each other, that BGP packets are sourced from the correct interface and in case of EBGP don’t forget to use the multihop command.


ASHOK TAMBE


We’ll continue by looking at some IBGP issues. Two routers in the same AS and here’s the configuration:

Plain and simple. The routers use the directly connected IP addresses for the BGP neighbor adjacency.


ASHOK TAMBE

CCNP TSHOOT 642-832

Too bad…we are not becoming neighbors. What could possibly be wrong? We are using the directly connected interfaces so there’s not that much that could go wrong except for L2/L2 issues.

Sending a ping from one router to the other proves that L2 and L3 are working fine. What about L3? We could have issues with the transport layer.


CCNP TSHOOT 642-832

I’m unable to connect to TCP port 179 from both routers. This should ring a bell, maybe something is blocking BGP ?

Someone decided it was a good idea to “secure” BGP and block it with an access-list.

Let’s get rid of the access-list.

That’s what we are looking for! Lesson learned: Don’t block BGP TCP port 179.


ASHOK TAMBE


Next IBGP issue. This one is similar to the EBGP situation earlier...we are using the loopback interfaces to establish the BGP neighbor adjacency, here are the configurations:

Nothing special, IBGP and we are using the loopback interfaces


ASHOK TAMBE

CCNP TSHOOT 642-832

No luck here…no neighbors. Let’s first check if the routers can reach each other’s loopback interfaces

A quick look at the routing table shows us that this is not the case. We could fix this with a static route or an IGP. Normally we use an IGP for IBGP to advertise the loopback interfaces, let’s use OSPF:


ASHOK TAMBE

CCNP TSHOOT 642-832

A quick ping to check if the routers know how to reach each other’s networks is successful.

Still no BGP neighbor adjacency though…


ASHOK TAMBE

CCNP TSHOOT 642-832

A debug shows up that the connection is refused and it also shows us the local IP address that is used for BGP. Seems someone forgot to add the update-source command so let’s fix it!

Just like EBGP we have to set the correct source for our BGP packets

Problem solved! The only difference with EBGP is that we don’t have to change the TTL with the ebgp-multihop command. Lesson learned: Its common practice to configure IBGP between loopback interfaces. Make sure these loopbacks are reachable and that the BGP updates are sourced from the loopback interface


ASHOK TAMBE


Here’s a new scenario for you. R1 and R2 are in different autonomous systems. We are trying to advertise network 1.1.1.0 /24 from R1 to R2 but it’s not showing up on R2. Here are the configurations

At first sight there seems to be nothing wrong here


ASHOK TAMBE

CCNP TSHOOT 642-832

However R2 didn’t learn any prefixes from R1

Maybe there’s a distribute-list but that’s not the case here. This means we’ll have to check our network commands.

The problem is the network command, it works differently for BGP vs our IGPs. If we configure a network command for BGP it has to be an exact match. In this case I forgot to add the subnet mask


ASHOK TAMBE

CCNP TSHOOT 642-832

I have to make sure I type the correct subnet mask.

Now you can see we learned the prefix and R2 installs it in the routing table…problem solved! Lesson learned: Type in the exact correct subnet mask…BGP is picky!


ASHOK TAMBE


Let’s move onto the next scenario. The network engineer from AS1 wants to advertise a summary to AS 2. The network engineer from AS 2 is complaining however that he’s not receiving anything…let’s find out what is going wrong!

Here’s the configuration. You can see the aggregate-address command on R1 for network 172.16.0.0 /16.


ASHOK TAMBE

CCNP TSHOOT 642-832

Too bad…no prefixes have been received by R2. There are two things I could check here: • See if a distribute-list is blocking prefixes like I did in the previous example. • See what R1 has in its routing table (can’t advertise what I don’t have!). Let’s start with the routing table of R1 since I think by now you know what a distribute-list looks like

There’s nothing here that looks even close to 172.16.0.0 /16. If we want to advertise a summary we have to put something in the routing table of R1 first. Let me show you the different options

This is option 1: I’ll create a loopback0 interface and configure an IP address that falls within the range of the aggregate-address command


ASHOK TAMBE

CCNP TSHOOT 642-832

Now we see the summary in the routing table of R2. By default it will still advertise the other prefixes. If you don’t want this you need to use the aggregate-address summary only command!

Let me show you option 2 of advertising the summary:

First we’ll put the 172.16.0.0 /16 network in the routing table by creating a static route and pointing it to the null0 interface. Secondly I’ll use a network command for BGP to advertise this network.

Now it shows up on R2! Problem solved! Lesson learned: You can’t advertise what you don’t have. Create a static route and point it to the null0 interface to create a loopback interface that has a prefix that falls within the summary address range.


ASHOK TAMBE


Onto the next scenario. You are working as a network engineer for AS 1 and one day you get a phone call from the network engineer at AS 2 asking you why you are advertising a summary for 1.0.0.0 /8. You have no idea what the hell he is talking about so you decide to check your router.

This is what the network engineer on R2 is seeing.


ASHOK TAMBE

CCNP TSHOOT 642-832

We can see that we have network 1.0.0.0 /8 in the BGP table of R1. Let’s check its routing table.

Network 1.1.1.0 /24 is configured on the loopback interface but it’s in the BGP table as 1.0.0.0 /8. This could mean only 1 thing….summarization

A quick look at show ip protocols reveals that automatic summarization is enabled. Let’s disable it:

We’ll disable it on R1.


ASHOK TAMBE


Same topology, different problem. The people from AS 2 are complaining that they are not receiving anything from AS 1. To keep it interesting I’m not going to show you the configurations

For starters, we can see that R2 is not receiving any prefixes

I can also verify that R1 doesn’t have any distribute-lists


ASHOK TAMBE

CCNP TSHOOT 642-832

I can confirm that R1 does have network 1.1.1.0 /24 in its routing table so why is it not advertising this to R2?

Let’s see if R1 has configured anything special for its neighbor R2:


ASHOK TAMBE

CCNP TSHOOT 642-832

I will use the show ip bgp neighbors command to see detailed information of R2. We can see that a route-map has been applied to R2 and it’s called “NEIGHBORS”. Keep in mind that besides distribute-lists we can use also use route-maps for BGP filtering


ASHOK TAMBE

CCNP TSHOOT 642-832

There’s only a match statement for prefix-list “PREFIXES”.

There’s our troublemaker…its denying network 1.1.1.0 /24!

We’ll get rid of the route-map…

And finally R2 has learned about this prefix…problem solved! Lesson learned: Make sure there are no route-maps blocking the advertisement of prefixes.


ASHOK TAMBE


Finally a third contestant enters the arena to demonstrate a new issue. R1 is advertising network 1.1.1.0 /24 but R3 is not learning about this network. Here are the configurations:


ASHOK TAMBE

CCNP TSHOOT 642-832

The neighbor adjacencies have been configured and R1 is advertising network 1.1.1.0 /24

We can see network 1.1.1.0 /24 in the routing table of R2 but it’s not showing up on R3. Technically there is no problem. If you look closely at the BGP configuration of all three routers you can see there is only a BGP neighbor adjacency between R1 & R2 and betweenvR2 & R3. Because of IBGP split horizon R2 does not forward network 1.1.1.0 /24 towardsvR3. In order to fix this we need to configure R1 and R3 to become neighbors

If I’m going to configure the BGP neighbor adjacency between R1 and R3 I’ll need to make sure they can reach each other. I can use a static route or an IGP…to keep things easy I’ll use a static route this time.


ASHOK TAMBE

CCNP TSHOOT 642-832

Configure the correct BGP neighbor commands

And R3 has access to network 1.1.1.0 /24! Lesson learned: IBGP neighbor adjacencies have to be full mesh! Another solution would be by using a route-reflector or confederation.


ASHOK TAMBE


Here’s a new scenario for you. R3 is advertising network 3.3.3.0 /24 through EBGP and R2 installs it in the routing table. R1 however doesn’t have this network in its routing table. Here are the configurations:


ASHOK TAMBE

CCNP TSHOOT 642-832

Here are the configurations. To keep things easy I’m using the physical interface IP addresses to configure the BGP neighbor adjacencies

We can verify that network 3.3.3.0 /24 is in the routing table of R2.

There’s nothing in the routing table of R1 however. The first thing we should check is if it’s the BGP table or not

We can see it’s in the BGP table and the * indicates that this is a valid route. However I don’t see the > symbol which indicates the best path. For some reason BGP is unable to install this entry in the routing table. Take a close look at the next hop IP address (192.168.23.3). Is this IP address reachable?


ASHOK TAMBE

CCNP TSHOOT 642-832

R1 has no idea how to reach 192.168.23.3 so our next hop is unreachable. There are 2 ways how we can deal with this issue: • Use a static route or IGP to make this next hop IP address reachable. • Change the next hop IP address. We’ll change the next hop IP address since I think you’ve seen enough static routes and IGPs so far.

This command will change the next hop IP address to the IP address of R2.

You can see the > symbol that indicates that this path has been selected as the best one. The next hop IP address is now 192.168.12.2


ASHOK TAMBE

CCNP TSHOOT 642-832

Hooray! It’s in the routing table now. Are we done now? If my goal was to make this show up in the routing table then we are now finished…there’s another issue however.

My ping is unsuccessful. R1 and R2 both have network 3.3.3.0 /24 in their routing table so we know that they know where to forward the IP packets to. Let’s take a look at R3:

R3 will receive an IP packet with destination 3.3.3.3 and source 192.168.12.1. You can see in the routing table that it has no idea where to send IP packets meant for 192.168.12.1. Let’s change that


ASHOK TAMBE

CCNP TSHOOT 642-832

We’ll advertise network 192.168.12.0 /24 on R2.

Now R3 knows where to send traffic for 192.168.12.0 /24 to.

Problem solved! Lesson learned: Make sure the next hop IP address is reachable so routes can be installed in the routing table and that all required networks are reachable.


ASHOK TAMBE

CCNP TSHOOT 642-832


ASHOK TAMBE

CCNP TSHOOT 642-832

Chapter 7 Troubleshooting BGP

Documents

bgp configuration

troubleshooting bgp

external bgp

default bgp

bgp neighbor router

bgp neighbor reachable

working bgp neighbor

ashok tambe training