BGP Troubleshooting

[tanmoymm91]

lets say we have R1(AS-100) peering with R2 (As-200)

when you do

show tcp brief

on R1 you saw TCP connection is not established .

You need to give proofs to customer that there is no issue from local end (R1 side)

what are the troubleshooting approaches you can perform on your Router R1 

Few notes  : You dont have any control on R2 ,  you cant do debug on R1 as its production device 

[MHM Cisco World · Accepted solution]

Telent using port 179

Check if the R2 open this port and reachable or not.

[David Ruess]

@MHM Cisco World Im not sure that would work as the OP said you don't have access to R2. So they would not be able to telnet to R2 as its the customers site. I assume it would be blocked as most customer sites dont allow their Service provider to telnet on any port into their device.

I would check the BGP neighbor status on R1 by doing a

sh ip bgp summary

If the neighbor shows in an Idle or Connect state then that shows that its trying to establish a TCP connection with the remote side. Once it establishes a TCP session then it moves to the OpenSent and Active state

-David

[tanmoymm91]

Hi David ,

if the neighbor state is either in connect or active state , issue either may be local side or remote(customer ) side .

you cant say customer by showing this output that there is no issue from local side 

as @MHM Cisco World said telnet is one option to proof that there is no issue on local side but David's statement is also somehow correct . customer generally block telnet traffic .

without telnet do you have any other option to proof that issue on remote or customer side ?

[David Ruess]

True its not definitive, but at least those states show its attempting to establish the neighborship. Its a starting point. At that point I would turn to the customer side to see if they were receiving any connections (maybe being blocked by a firewall). Without debugs or log messages its difficult to show the customer "its working on our end".

Also just debugging BGP for that neighbor should not be a problem even in production network. The general statement of "debugging" is bad in a production network usually applies to something like debug all and fills the logs so fast it crashes the router.

Another thing to note is nothing could be wrong on either side. It could be something in the transit path that neither of you have control over.

Really not sure if there is anything "definitive" that says everything is working on our side (except some debug possibly) to show the actual customer.

[MHM Cisco World]

connection refused meaning the IP is reachable and port is Open 
destination unreachable & connection timeout meaning the port is closed and/or the IP is unreachable 

[tanmoymm91]

Connection refuse means the port is not open on destination device , thats why the socket is accepting the packet on that port .

Connection time out means there is communication gap between source and destination . mostly routing issue .

[tanmoymm91]

ICMP packet mostly blocked on customer side . but , i thing telnet should be on customer side .

instead of telnet we can do analysis based on packet captures . probably by tcpdump or wireshark .

@MHM Cisco World  whats your suggestion on this point 

[MHM Cisco World]

I will check this point

Thanks

MHM

[tanmoymm91]

in most cases  ICMP packets are blocked on customer side , in that case telnet will not works .

so instead of telnet we can provided our end analysis based on tcpdump or packet capture output .

@MHM Cisco World  will that be a good step to prove our side is fine ?