Cisco ccnp route bgp troubleshooting


Published on

Cisco ccnp route bgp troubleshooting

Published in: Technology, Health & Medicine
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Cisco ccnp route bgp troubleshooting

  1. 1. Cisco CCNP Route – BGP TroubleshootingEvery time you troubleshoot your BGP (Border Gateway Protocol), always follow atried and tested troubleshooting model. That way, you can work more efficiently andprobably even resolve the problem much faster. We usually follow an 8-pointtroubleshooting model like the one below: Define the problem Gather the facts Document the facts Consider the possibilities Create an action plan Implement the action plan Repeat until resolution Document the solutionJust like in most protocols, there are some very specific, common issues andproblems, as well as their corresponding solutions. Here in our article on BGPtroubleshooting, we’ll be looking at these four potential problems/issues: 1. Neighbor relationship problems 2. Route advertisement issues 3. Routes missing from the table 4. Address summarization problemsNeighbor Relationship ProblemsThere are a number of possible reasons that may prevent neighbors fromestablishing a relationship. Here are some of the most common causes of neighborrelationship problems:Possible Cause: Layer 2 or Interface is downIf the Layer 2 process or Interface is down, it may prevent a neighbor relationshipfrom forming. The easiest way to determine that this is the problem when it’s stuckin the Active or Idle state is by executing the show interface <slot/port>. Forexample, execute: show interfaces fastethernet 0/0 or show interfacesgigabitethernet 0/0 When the output is displayed, look at the interface that’s facingthe BGP peer. You should be able to see a line where it says something like:Fast Ethernet 0/0 is up, line protocol is up.The first part (Fast Ethernet 0/0 is up) is talking about the physical hardware portion,while the second part (line protocol is up) is talking about the Layer 2 process.So if you see something like: Fast Ethernet 0/0 is up, line protocol is down, thatmeans the physical interface is fine but Ethernet keepalive are not sent/received onthe interface. Sometimes, the reason is that something isn’t plugged-in on the otherside. Another reason could be you simply have a bad cable.
  2. 2. If, however, the interface shows to be administratively down, then you can remedythat by simply issuing the no shutdown command on the interface.In figuring out Layer 1 and Layer 2 problems, always start at Layer 1 and work yourway up. Troubleshoot and solve the Layer 1 and Layer 2 issues on that particularinterface. If it’s a hardware failure, if it’s a cable failure, or something more subtle,this method will be the best way to take care of this particular cause. Possible Cause:Incorrect IP address used in neighbor statement in BGP An incorrect IP address in theneighbor statement in BGP may also cause neighbor relationship problems.Consider this diagram:So, for example, in router R1, the configuration should be: router bgp65001 neighbor remote-as 65006 (this is the neighbor statement for R6,for peering)Conversely, on router R6, the statement in the configuration should be: router bgp65006neighbor remote-as 65001 If, for example, the IP address on eitherR1 or R6 is wrong, the relationship will not form. So the easiest way to figure out ifthere’s a problem is to first execute the show ipbgp summary command. It will showyou the state of the neighbor relationship, how many prefixes if any are beingreceived, and whether the neighbor is stuck in Idle or Active state.In addition to that, you can also execute the show running config command to verifythat the peer address in the neighbor statements are correctly configured in BGP.One of the things that’s going to be helpful is to: go in using PuTTY, SecureCRT, TeraTerm or whatever terminal services program you’re most comfortable with; highlightthe BGP section; paste the configuration into Notepad; and then go into the neighbor
  3. 3. router and do the same thing. See if the neighbor configuration statements are infact correct. If they’re not correct, delete the neighbor statement and recreate themwith the correct IP addresses. Possible Cause: Configured eBGP peers are notdirectly connected although eBGP peers that aren’t directly connected can still haveneighbor relationships, an additional command must be used and a special pathmust be in place for the neighbor relationship to work.You can determine whether the neighbor is more than one hop away by executingthetraceroute<peer ip> command. You’ll be able to tell very easily by the number ofdifferent sections and hops shown in the output.Once you discover that the neighbor is in fact more than one hop away, you can goback into the BGP configuration and put in the statement: neighbor <peerip>ebgp-multihop<ttl>. ttlstands for time-to-live, which can be a value from 1 to 255and which refers to the maximum number of hops that can be taken to reach thepeer. If it’s 2 hops away, you put 2. If it’s 3 hops away, you put 3, and so on. You mayalso leave that parameter blank. If you do that, the default value of 255 will beapplied.Another thing you can use is the show tcp command, which you execute in thecommand-line. It will show you whether a TCP connection is up and in progress withthat particular neighbor. Subsequently, it will allow you to verify establishment of aTCP session on port 179 toward a BGP peer. Possible Cause: Misconfigured neighborauthentication Another cause that’s very common for neighbor relationships notforming in BGP is the failure to configure the correct key in the password statement.If you do a show ipbgp summary and you see that the neighbor relationships areindeed stuck in Active or Idle, the easiest way to resolve this is to execute the showrunning configcommand and then verify that the neighbor <peer ip> password<key> command is present on both peers and that the configured keys match.Again, it would help if you copy those snippets and paste them into Notepad. Thatway, you can view the snippets all by themselves as you try to compare them andspot anything missing or mistyped. Remember that the key is case-sensitive. If thatstatement is incorrect, you don’t have to delete the entire configuration. Justrecreate the neighbor <peer ip> password <key> statements on both BGPpeers. Possible Cause: Unicast traffic being blocked between devices this possiblecause for neighbor relationships not forming is not as common as those mentionedearlier. However, it’s still a possible cause nevertheless. In this case, Unicast trafficbetween the peers is being blocked. Blocking can be caused by a firewall, an accesslist, or a variety of different things.Most likely, it’s going to be something configured on one or the other peers that maybe blocking it but if there’s an intermediate device, then you’ll have to take a good
  4. 4. look at that device’s configuration as well.But in the particular device in question, execute the show ip interface and showaccess listcommands. Look at all the access lists, see if anything is being applied onthe interface facing that particular neighbor, and if there is, either alters the accesslist to allow the traffic or you may have to alter it altogether.Once you’re done with that, make sure everything is correct, make sure that thestatements for peering are correct, and make sure show interface showsup/up. Possible Cause: Neighbor statement misconfigured under BGP There may beother things in the neighbor statement that may cause problems in neighborrelationships. For instance, timers may be mismatched.To check whether something’s incorrect with the neighbor statement in BGP, start byexecuting the show ipbgp summary. You’ll want to know first whether the neighborrelationships aren’t even shown. If they aren’t shown, then that means the neighborrelationship is not being established and it has not been configured at all.If it has been configured, you’re going to see at least Active or Idle as a result of thatcommand. At that point, you can also execute the show running-config in order to beable to go through and parse through the configuration. If there are only a fewentries, this task is going to be very easy.However, if it’s really long, then it can be difficult. If so, then paste it to Notepad soyou can use the search function to find specifically what you’re looking for. If youknow a specific IP that’s correct, you can go to that particular IP where you’ll find theentire string of numbers and commands, which will be listed in order. From that youcan gather some information and determine possible causes.Once you’ve pinpointed what’s wrong, you can delete and recreate the neighborstatements with the correct IP address combinations.Route Advertisement IssuesPossible Cause: Automatic network summarization is in effect Although there can bea number of things that may prevent routes from being advertised correctly, one ofthe primary culprits is the auto-summary command.Both BGP and EIGRP have automatic summarization enabled by default. If you don’texecute the no-auto summary command when you configure BGP, it’s going toautomatically summarize into a classical boundary.To check whether summarization is enabled, use the show ip protocols command.Look for the statement that says, Automatic route summarization is <disabled |
  5. 5. enabled>. In EIGRP, it will say, “... is in effect” or “... is not in effect”.So in BGP, you’ll want to see “disabled”. If it says something different, then you willneed to go back into the BGP router configuration and execute the noauto-summary command.Possible Cause: The advertisement does not match a routein the IP routing table If the particular route being injected into BGP bythe network statement is not matching a route in the IP routing table, then you canencounter route advertisement problems.To remedy this, execute the show ip route command to discover whether the routeexists in the current routing table. If it is not there, troubleshoot the local router andthe IGP to determine the cause. See whether it was even configured in the router orcheck the IGP to see if there is a particular issue that’s preventing the route frombeing installed in the routing table.Once you see the cause of the problem, correct it. Possible Cause: Routesynchronization is enabled By default, route synchronization is enabled in BGP.Synchronization means that it has to exist in the IP routing table through an IGP,static routes, or other means, or BGP will not advertise the route.To solve this problem, first execute the show ip protocols command and checkwhether the statement says IGP synchronization is enabled. If so, go back into theBGP configuration and put in the no synchronization command in order for thatbehavior to be turned off. Possible Cause: Route redistribution is not configured or ismisconfigured One more cause for a problem with route advertisement issues mayhave to do with redistribution. Basically, if redistribution has not been configured,BGP won’t pull those routes in. The table has to be populated either through directinjection into BGP using the network statement or through redistribution.You may use the show ip protocols command and look to see if redistribution hasbeen configured. If it has, then investigate some more to see where the problem lies.It could be that you may have put in an incorrect AS number or a process ID relatingto OSPF.Routes Missing from TableNow, aside from routes not being advertised correctly in BGP, you may find thatcertain routes are not showing up in the routing table, which is a little bit of adifferent issue. They sound the same but route advertisement is actually the BGPprocess announcing something out, and whether or not something’s being installedin the routing table is a separate issue altogether.Possible Cause: Default routemisconfigured If the default route is not showing up, then it’s probably simplybecause it was not configured correctly. To investigate, execute the show iproute andsee whether there is a route to network to begin with. If it’s missing from the
  6. 6. table, it won’t be injected or advertised from BGP.You may also execute the show running-config and verify whether the network0.0.0.0 and the default-information originate statements are existing and correctlyconfigured in BGP. Add those statements if you find them missing. Possible Cause:Route synchronization is enabled We discussed this earlier as a possible cause forroute advertisement issues, so just review that section if you want. Possible Cause:iBGP neighbors not fully meshed You may have a problem with iBGP neighborsbecause these neighbors are not full meshed. Remember, when the routes are beingadvertised among iBGP peers, it has a ttl of 1. If they’re not all fully meshed, youwon’t be able to propagate routes correctly.To verify that peerings are happening correctly, use the show ipbgpneighbors command. You may also use the show running-config command and do alittle bit more investigative work in order to determine whether or not the neighborsare in fact fully meshed.If there are connections that are missing, configure them using the <peer ip>remote-as <ASN> command. For example, let’s bring back the diagram we showedyou earlier.If these were IBGP routers and there were direct connections between the InternetRouter and Router 1 as well as between Router 1 and Router 6, but there was noconnection between the Internet Router and Router 6, that would be a missing leg toa fully-meshed environment.So if you have that kind of missing connection, you can then use the <peer ip>remote-as <ASN> command to remedy the problem.Finally, execute the show ipbgp summary command, make sure that all the other
  7. 7. peers that you’re looking for are indeed there and that each one of the neighborsshows all the other peers that are required. That will be your best way ofdetermining whether or not a fully meshed relationship has beenconfigured. Possible Cause: iBGP next-hop is not reachable One of the ways for you tocheck whether this is an issue is to do the show ip route command and examine theIP routing table for the required static/IGP route. And this is true with even eBGP. Ifthe next-hop route is not reachable, it’s not going to be advertised.If a static route is required, configure it using the ip route<prefix><mask><next-hop>command. Now, if for some reason, the IGP is failing toinstall the route leading to the iBGP next-hop address, you may have a whole otherset of issues just related to the IGP.In that instance, you have to make sure you’re looking at BGP as one sort oftroubleshooting domain and the IGP as another. They depend on each other but theycan have different issues.Address Summarization ProblemsPossible Cause: No subnets in the routing table in the range of the aggregateaddress In terms of address summarization problems, one common cause for anaggregate not being advertised is because there isn’t some part of the IP addressrange within the aggregate that exists already in the routing table.The easiest way to check that is to execute the show ip route. See if any networkswithin that range currently exist. If you were advertising an aggregate address216.145.0.0 and the mask is and there are no 216.145-any typeaddresses in terms of the routing table, it’s not going to advertise the aggregate.Execute the show running-config to verify that the aggregate address statement iscorrectly configured. If it is not, delete and recreate the statement that needcorrections.Relevant Debug and Show CommandsThe troubleshooting process in BGP requires the use of several Show and a coupleof Debugcommands that you should be familiar with. BGP Show Commands Show ipprotocols This will show the BGP status of your neighbor, your Autonomous SystemNumber (ASN), timer intervals, networks being advertised, and neighbors/gateways.Consequently, it will be helpful in troubleshooting neighbor relationships, missingroutes, summarization issues, and filtering problems.Here’s a portion of an output resulting from a show ip protocols command:
  8. 8. Show ip route bgp This will show BGP routes advertised by neighbors, theadministrative distance, MED value (if any), and the route source/interface. Theseinformation will be helpful in troubleshooting missing routes, summarization issues,filtering problems, and general troubleshooting tasks.Show ipbgpsummaryThis will show your configured peer IP addresses, your ASN, thenumber of messages received and sent, how long the session has been up, the state(Active, Idle, etc.), and prefixes received. This will be helpful in troubleshootingneighbor relationship issues, local configuration issues, and routing problems.
  9. 9. Show ipbgpneighborsThere are two forms of this command. The first one isjust show ipbgp neighbors, which will show you the IP address of neighbors, routerID of neighbors, state of a neighbor, peer-group (if configured), BGP messages/typesreceived, and so forth.However, you can also specify the peer ip address and then add either of these twooptional parameters received-routes and advertised-routes. Received-routes is forroutes being received by that particular neighbor, while advertised-routes is forroutes advertised out to a particular neighbor.Here’s the syntax: show ipbgp neighbors [peer ip address] {received-routes |advertised-routes} That will show you how many routes you are actually advertisingor receiving and can be extremely helpful in attacking problems associated withroutes missing and so forth. It can also be helpful in troubleshooting neighborrelationships, local configuration issues, and other issues associated with BGP routes.Here’s part of what I got when I issued the command: show ipbgp neighbors10.6.6.6Now, here’s part of what I got when I used show ipbgp neighbors instead:
  10. 10. Notice the default route that’s being advertised at the top, followed by a whole hostof prefixes.Lastly, here’s part of what I got when I used show ipbgp neighbors It’s practically the same type of information but it’s showing what’s beingreceived. Show ipbgp This shows the entire contents of the routing information base.It will show your network mask/prefix, next-hop router, MED value, Local PreferenceValue, Weight Value, AS path, and so forth.In turn, that information is going to be helpful in troubleshooting missing routes,filtering problems, and general troubleshooting tasks.Now we go to the Debug commands.BGP Debug Commands Debug commands display results that are more real-timeviews of the situation compared to the results of the show commands, which mostly
  11. 11. allow you only to look at settings.debugipbgp<peer ip> updates This will show you everything that has to do withneighbor adjacencies and relationships. So it’s good for troubleshooting neighborrelationships and routing update issues.debugipbgp eventsThis is helpful in looking at different network events like interfaces that go up anddown, processes that change, neighbor relationships that change, and so forth. It canhelp in troubleshooting routing update issues, convergence issues, and interfaceflapping.ConclusionThat wraps up our discussion on BGP troubleshooting. I hope you learned a lot and Ilook forward to having you here again.More Cisco Certification Info, Tips:CCNP TSHOOT: Cisco Troubleshooting Techniques & ProceduresTop Cisco Certification BooksTop 5 VoIP Concepts to Know for CCNA Voice—VoIP Basic for CCNA Voice ExamHow to Prepare for the CCIE Voice Written Exam?Guide to Cisco CCNA Voice Exam 640-461…Reviews, Main Topics