The new focus is of the R&S exam is troubleshooting. And for some reason this is seen as a new topic to study and as a result feared. It is vital to understand why troubleshooting was added to the lab, and why it will possibly be added to other tracks. Anybody can apply vanilla configs, provided it is done without error, in the correct order, and by avoiding the question pitfalls.
Troubleshooting was introduced by Cisco to give the CCIE certification that edge it needs to seperate the guys that really understand the technologies and those that just learned to configure labs. Troubleshooting is thus NOT a new section! If you understand know each technology, understand its it building blocks, processes and states, troubleshooting should be nothing ‘new’.
That said, once you understand the work, drafting a troubleshooting methodology per technology should be fairly straight forward. A detailed troubleshooting approach is included in each chapter of the Routing-Bits Handbooks.
(Note ‘{ }’ curl-brackets indicate replaceable values, the rest is regex)
Troubleshooting BGP session start-up problems
1- Are you seeing the expected neighbors in a NON ‘idle’ or ‘active’ state?
#sh ip bgp summary
2- Is a sourced telnet to the neighbor address working?
#telnet {peer-ip} 179 /source {src-int-ip}
3- Confirm if the configuration is correct and matching to neighbors configuration?
#sh run | b router bgp
4- If eBGP, is the neighbor directly connected? (Should be 1 hop in the trace)
4.1- If not directly connected is multihop configured?
#trace {peer-ip} source {src-int-ip}
#sh run | i {peer-ip}.*ebgp-multihop
5- Is there IP reachability to neighbor?
#ping {peer-ip} source {src-int-ip}
6- Are the underlying routing inplace between neighbors?
#sh ip route {peer-ip}
7- If the obvious checks don’t elude to the issue, enable debugging to analyse the TCP session setup.
#debug ip tcp transactions
7.1- If the TCP-SYN packet is not answered with a SYN-ACK packet and times out?
7.1.1- Look for ACL’s blocking TCP-179.
#sh ip interface | i line|list
7.2- If the TCP-SYN packet is answered with a RST packet, it verifies reachability, but the neighbor is not willing to grant the connection attempt.
7.2.1- Does the neighbor have BGP configured or BGP “neighbor shutdown”?
#sh run | i {peer-ip}.*shutdown
7.2.2- Does the outgoing interface IP match the peers “neighbor” statement?
#sh run | i neighbor.*{peer-ip}
7.2.3- If not is the correct source interfaces specified?
#sh run | i {peer-ip}.*update-source
7.3- If the 3-way TCP handshake completes but the router drops the session shortly after causing the neighbor to oscillate between idle and active, check the BGP parameters.
7.3.1- Confirm the AS numbers between the neighbors are correct
#sh run | i router bgp|remote-as
7.3.2- If using confederations, double check AS numbers.
#sh run | i router bgp|remote-as
7.3.3- Is MD5 password authentication configured correctly?
#sh run | i neighbor.*password
.
Troubleshooting BGP Route Selection Issues
1- Are locally originated routes appearing in the BGP table?
#sh ip bgp
1.1- If auto-summary is enabled, is at least one subnet of the major network present in the RIB?
#sh run | i router bgp|summary
#sh ip route {prefix} longer-prefixes
1.2- If auto-summary is disabled, is there a exact prefix match in the RIB?
#sh run | i router bgp|no summary
#sh ip route | i {prefix}/{mask}
1.3- Is there a distribute-list configured blocking prefixes?
#sh run | i distribute-list
2- Is there a aggregate configured that is not advertised?
#sh run | i aggregate
2.1- Is there a more specific network of the aggregate in the BGP table?
#sh ip bgp {prefix}/{mask} longer-prefixes
3- Is a prefix in the BGP table not getting advertised to a iBGP neighbor?
#sh ip bgp {prefix} 'Yields no result'
3.1- Was the prefix learned via iBGP? BGP split horizon? (Look for ‘i’ routes)
#sh ip bgp {prefix} | i _i|>i
4- Are you receiving any prefixes from the neighbor? (Look at ‘PfxRcd’)
#sh ip bgp summary | i {peer-ip}
4.1- Is the neighbor sending any routes? (This is issued on the neighbor router)
#sh ip bgp neighbor {peer-ip} advertised routes
4.2- Are the prefixes showing BEFORE any filters were applied? (For this step “soft-reconfig” must have been enabled)
#sh ip bgp neighbor {peer-ip} received-routes
4.3- Are the prefixes showing AFTER the filters were applied?
#sh ip bgp neighbor {peer-ip} routes
4.3.1- Are any prefix-filters configured denying the prefixes?
#sh run | i {peer-ip}.*prefix-list
4.3.2- Are any AS-path filters configured denying the prefixes?
#sh run | i {peer-ip}.*filter-list
4.3.3- If a route-map is configured
#sh run | i {peer-ip}.*route-map
4.3.3.1- The routes must be explicitly permitted to be accepted/used.
#sh route-map {name}
4.3.3.2- Are the prefixes explicitly denied
#sh route-map {name}
4.4- Was the BGP session cleared after changes to filters and route-maps? (BOTH SIDES)
#clear ip bgp * in
5- The prefix is in the bgp table, but not in the RIB
#sh ip bgp | i {prefix}
5.1- Is the BGP next-hop reachable?
#sh ip route {bgp-next-hop}
5.2- Is the prefix selected as the best route? (Indicated with ‘>’)
#sh ip bgp | i {prefix}
5.2.1- If not, verify the BGP attributes are correct.
#sh ip bgp {prefix}
5.3- Prefix is selected as best, but not entered into RIB? Synchronization issue!
#sh run | i no synch
5.4- If the prefix is listed in the BGP with the options:
5.4.1- ‘r’ means a lower admin distance route is used and entered in the RIB.
#sh ip bgp | i ^r.*{prefix}
5.4.2- ‘s’ means specific routes suppressed by aggregation are not advertised.
#sh ip bgp | i ^s.*{prefix}
5.4.3- ‘S’ stale routes marked during a graceful restart is not advertised.
#sh ip bgp | i ^S.*{prefix}
5.4.4- ‘d’ means the route is dampened, due to flapping violations.
#sh ip bgp | i ^d.*{prefix}
5.5- Are any communities attached to the prefix causing problems?
#sh ip bgp {prefix}
5.6- Is the expected communities being received? Sending communities enabled?
#sh run | i neighbor.*send-community
good combination of commands given.
regards
shivlu jain
http://www.mplsvpn.info
Good idea. What I would check before looking for filters is whether we are filtering the prefixes to a neighbor (sh ip bgp neighbors {peer-ip} advertised-routes) or if we are filtering prefixes from a neighbor by comparing “sh ip bgp neighbors {peer-ip} routes” (filtered) vs “sh ip bgp neighbors {peer-ip} received-routes” (unfiltered).
Nicolas
http://ccie-en-espanol.blogspot.com/
Good suggestion Nicolas. Thanks I added it :)