GNS3 Lab: Troubleshoot and Resolve Routing IssuesBGP

In previous articles, we have learned how to face OSPF and EIGRP routing
issues. If you havent already, please check out my previous articles. It is a
very challenging and responsible task to maintain Border Gateway Protocol
(BGP) properly because we have to deal with external routing; if any
breakdown occurs it should be resolved quickly.

GNS3LabBGPTroubleshooting.zip

Lets have a quick look at functionalities and properties of BGP.

BGP is an Exterior Gateway Protocol (EGP) used for routing between
autonomous systems. TCP port 179 is used to establish session and BGP
neighbors are not discovered; rather, they must be configured manually so
we have to configure unicast routing using neighbor command on both
sides.
We can use BGP in the following conditions:

Customer connected to multiple Internet service providers (ISPs).

Service provider networks (transit autonomous system).

In very large enterprise networks, where we can use BGP at core

layer as a redundant routing protocol.

Common Neighbor Stability Problems of BGP:

Misconfigured neighbors IP address and AS number.

Reachability issues when interfaces other than directly connected
interfaces are used while peering (update-source issue).

Authentication must be properly implemented (if configured).

Router ID must be unique.

BGP often stuck in idle or active state; some common issues are described
below.
For the IDLE state, common issues are:

TCP port 179 is not open.

Misconfigured Peer address under BGP.

Misconfigured AS number under BGP (remote-as).

BGP misconfiguration for peers.

For the ACTIVE state, common issues are:

TCP connection is initiated and it is in ACTIVE state; Retry to

establish TCP session.

Peer address configured is not directly connected interface (Missing

update-source command).

Network congestion, so TCP is unable to establish session.

Interface flapping.

To resolve most common BGP routing issues I have designed a GNS3 Lab
which is posted here for your hands-on practice so that you can start the
implementation or trouble-shooting as per the described objective. You will
also find a solution file so that you can tally your configuration.

Scenario
In this GNS3 lab (as shown in Fig. 1), you will begin with preloaded
configuration scripts on each of the routers. These scripts contain errors
that will prevent end-to-end communication across the network, especially
between Router LA and NY. This means you have to establish
communication from 10.1.1.1 to 10.2.2.2. To achieve this task, you will
need to troubleshoot each router to determine the configuration errors,
and then use the appropriate commands to correct the configurations.
When you have corrected all of the configuration errors, loopback on the

router LA should be able to communicate with the loopback address of

router NY, i.e., 10.2.2.2, so at the end you should get a ping reply, as
shown below:
LA# ping 10.2.2.2 source 10.1.1.1
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/126/168 ms

Learning Objectives of Working with GNS3 File:

Upon completion of this lab, you will be able to troubleshoot and resolve:

Next hop unchanged issue with BGP (for iBGP peers)

BGP split-horizon issues

BGP authentication issues

BGP neighborship stability issues

Router ID issue with BGP

You can also:

Gather information about the misconfigured portion of the network.

Analyze information to determine why communication is not
possible.
Implement solutions to resolve network errors.

Download the GNS3 file and turn on all the devices. First we will check BGP
peering using sh ip bgp summary on routers LA, WDC1, WDC2, WDC3,
WDC4, WDC5 and NY. You will see that neighborship between WDC1WDC4
(1.1.1.1 to 4.4.4.4) is in active state, as shown in Fig. 2.

<img src="http://1rtdn21e2k8w27koup1eiasxspe.wpengine.netdnacdn.com/wp-content/uploads/052314_1709_TroubleShoo2.jpg" alt="" />

But if you check the running configuration on routers WDC1 and WDC4,
you will see that update-source command is missing from BGP
configuration, as shown below:
!
router bgp 10
no synchronization
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 10
neighbor 11.1.1.1 remote-as 20
no auto-summary
!

So configure the update-source for respective neighbors using this

command:
WDC1(config)#router bgp 10
WDC1(config-router)#neighbor 4.4.4.4 update-source loopback 1
WDC4(config)#router bgp 10
WDC4(config-router)#neighbor 1.1.1.1 update-source loopback 1

After configuring the above commands, your neighborship will comes up.
But on router WDC4, you will see the log messages of BAD Authentication
for BGP neighbor 56.1.1.1, as shown below:
*Mar 1 00:04:49.731: %TCP-6-BADAUTH: No MD5 digest
56.1.1.1(14121)
*Mar 1 00:04:49.871: %TCP-6-BADAUTH: No MD5 digest
56.1.1.1(14121)

from 56.1.1.2(179) to
from 56.1.1.2(179) to

If you check the authentication parameters on both routers using show

run | section bgp, you will find that router WDC4 is configured with
password CISC0 instead of CISCO (which is configured on neighbor router
NY).
Now you have all the BGP neighborships, as described in scenario, so you
have won half of war with BGP. Now its time to check routing database
and network reachability between BGP peers.
If you check the BGP database on routers WDC1 and WDC5, you will get
10.1.1.1 on WDC1 and 10.2.2.2 on WDC5 as best path but on router WDC4
you will find that you are getting both 10.1.1.1 and 10.2.2.2 but not best,
as shown in Fig.3 . Why are both routes not best?

You can find the answer with next hop; if you closely look at the next hops,
11.1.1.1 and 56.1.1.2, both are eBGP routes and we have not advertised
11.1.1.0 or 56.1.1.0 anywhere in BGP. Thats why both next hops are
unreachable from WDC4, so the solution is to advertise 11.1.1.0 on WDC1
under BGP and 56.1.1.0 on WDC5 but this is not feasible solution to
advertise eBGP networks.
A better and more feasible solution is to use Next-hop-self and you know
very well when to use this command; if not, then the next line is for you.
To inject networks learned from eBGP peer to iBGP peer
The next hop command is only for iBGP peers; now you can go to routers
WDC1 and WDC5 to configure next-hop-self under BGP for router WDC4,
as shown below:
self
self

WDC1(config-router)#neighbor 4.4.4.4 next-hopWDC5(config-router)#neighbor 45.1.1.1 next-hop-

Now if you check the BGP database on router WDC4 , you will get the
result shown in Fig. 4.

Both networks are best, but you will not get 10.2.2.2 on router WDC1 and
10.1.1.1 on router WDC5 because of the BGP split-horizon rule, which says
Routes learned from iBGP peer will not be forwarded to other iBGP peer.
Feasible solutions of BGP split-horizon are:

* Route-reflector

* Confederation (sub-AS method)

The confederation method is not as popular as a solution of BGP splithorizon just because of its complex implementation and lack of flexibility
for technology updating, whereas route reflector is a far better and more
widely used solution for BGP split-horizon.
Route reflector is deployed over centralized routers in iBGP; as per our
topology, WDC4 is a centralized router, so WDC4 will be configured as
route reflector and WDC1-WDC5 will be router reflector clients so that
WDC4 can exchange routing information with WDC1 and WDC2. You can
use following commands to implement route reflector:
WDC4(config)#router bgp 10
WDC4(config-router)#neighbor 1.1.1.1 route-reflector-client
WDC4(config-router)#neighbor 45.1.1.2 route-reflector-client

Instantly you will get following log messages,

*Mar 1 01:19:59.099:
config change
*Mar 1 01:20:01.347:
*Mar 1 01:20:20.651:
config change
*Mar 1 01:20:22.931:

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down RR client

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 45.1.1.2 Down RR client
%BGP-5-ADJCHANGE: neighbor 45.1.1.2 Up

Now you can see the 10.2.2.2 in LAs BGP routing table as shown in Fig. 5.

Now you have end to end reachability between AS 20 & AS 30 and you can
check the reachability using ping from router LA loopback to router NYs
loopback as shown in Fig. 6

Some Important Tips to Trouble-Shoot and Resolve BGP Issues:

 Router-ID must be unique to establish BGP peering.

If certain BGP routes are missing from the routing table, then check
if they exist in the BGP table:
if yes : next hop reachability issue
if not : non-availability of valid route in BGP
Split-Horizon issue or Synchronization rule issue
If certain routes are missing from the BGP and routing table, then
check the neighborship, using show ip bgp summary, or you can
check for route filtering (ACLs, route-maps, etc.).
iBGP learned route is not advertised to other iBGP peers, so
configuring a route reflector might be necessary.
Similarly, routes advertised by issuing a network command in BGP
must be advertised with proper subnet mask.
Useful Commands to Monitor and Troubleshoot BGP:

show ip bgp summaryTo check BGP neighbors with their

respective states
show ip bgpTo check BGP routing database

show ip bgp neighbor [ip-address]To check specific neighbors

information

show ip bgp [particular route]To check detailed information

about specific route

debug ip bgp eventsDisplays significant BGP events

debug ip bgp keepalivesDisplays BGP keepalive packets

debug ip bgp updatesDisplays all incoming or outgoing BGP

updates

I have also posted a solution file for BGP GNS3 lab so that you can tally
your solutions with that file.
All of us know very well that it is not possible to describe BGP issues in a
single article, but I have tried to discuss most common BGP problems with
their solutions. I hope that now you can deal with BGP issues and resolve
them quickly and thanks all for appreciating my previous articles. If you
like this article, then say thanks to intenseschool.com @ comment section
for providing you with such technologies. Your feedback is also welcome.

References
1. Cisco Certified Internetwork Expert by Wendell Odom and others,
Ciscopress.com
2. Routing TCP/IP Vol. 2 by Jeff Doyle
3. CCNP Route Quick Reference by Denis Donohou, Ciscopress.com
4. Cisco Certified Internetwork Expert Quick Reference by Brad Ellis,
Ciscopress.com