Unreachable Peer

Home » CentOS » Unreachable Peer
CentOS 5 Comments

Hey all,

I have a public peer system (yy.yy.yy.yy) that is reachable via my home uplink (xx.xx.xx.xxx).

15:59:30.244199 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 0
15:59:30.281931 IP yy.yy.yy.yy.https > xx.xx.xx.xxx.42958: tcp 0
15:59:30.281945 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 0
15:59:30.305020 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 105
15:59:30.344004 IP yy.yy.yy.yy.https > xx.xx.xx.xxx.42958: tcp 1412
15:59:30.344013 IP xx.xx.xx.xxx.42958 > yy.yy.yy.yy.https: tcp 0
15:59:30.344016 IP yy.yy.yy.yy.https > xx.xx.xx.xxx.42958: tcp 23

At the office we have a EL5 based router that can not reach the mentioned system. It does not give any hint about the problem.

15:57:51.751591 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0
15:57:54.750834 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0
15:58:00.749351 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0
15:58:12.746408 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0
15:58:36.740454 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0
15:59:24.728605 IP o.ff.i.ce.50902 > yy.yy.yy.yy.https: tcp 0

I tried to connect with a removed ecn bit [1]

[1] https://en.wikipedia.org/wiki/Explicit_Congestion_Notification

but this was not the solution.

Any ideas?

5 thoughts on - Unreachable Peer

  • That’s not much information to go on. Can you run tcpdump on the
    “public peer system”? Does it receive the SYN packets from your office?

  • Am 15.05.2015 um 18:17 schrieb Gordon Messmer :

    Well, the destination is not in my realm (different provider). Before contacting them I want to be sure that my system is not causing this. So far i just see a “tcp retransmission” while trying to establish a https connection (captured on our router):

    office -> destination: TCP 66 54487→443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=8
    office -> destination: TCP 66 [TCP Retransmission] 54487→443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=8

    from my home and office, I can see via traceroute that for the destination the entry hop is the same. So, the destination is not responding with SYN,ACK when the connection passes our router. But as I said it is reachable from my home, and this is confusing.

    Thanks, LF

  • In such situations, I use HPING in the following manner:
    hping3 -n -T -S -p 443 yy.yy.yy.yy

    Breakdown:
    -n – do not do DNS resolution
    -T – traceroute mode
    -S – send SYN packet (you should see flags=SA in the output for a reachable machine)
    -p – the destination port – 443 in this case

    You can a -t ## to start off with a larger tty than the default 0.

    Cheers, ak.

  • That can be difficult to establish. If you’re getting no response, the most likely problems are either a bad route or a firewall rule somewhere along the path. The problem could exist at anywhere along the path, and they’ll typically both look the same according to tests at your host.

    As Anthony pointed out, you can use hping3 in TCP traceroute mode to determine where along the path the problem probably exists. The first host to not respond should be the host with the problem. Hopefully you have access to a host that has access and a similar path to the host you can’t reach. If so, the same hping3 command should give you the complete traceroute path, and from there you can find the host that didn’t respond in the first test.

  • Am 18.05.2015 um 18:25 schrieb Gordon Messmer :

    I could determine that the problem didn’t sits on our systems now. The carrier of the endpoint has a ticket open now and I’m betting with my colleagues how fast they will be :-)

    Thanks for the pointers!