Sponsored Links

Some IP addresses are unreachable

rawnsley

Casual Member
On my new AirBand FTTP installation I've got a weird problem: some IP addresses are unreachable. For instance, if I PING 192.0.80.240 I get no reply, but 192.0.73.2 responds just fine. It seems to affect about 1 in 10 IP addresses and I can't find any sort of pattern.

I'm fairly experienced with networking, but there's still a chance I'm missing something obvious. I have an open ticket with AirBand, but they haven't made any progress as far as I know and the support process is quite opaque.

I get the same problem if I PING from the routers diagnostic page or if I plug my PC directly into the wall (bypassing the router) and PING from there. The IP addresses that fail are always the same.

My best guess is either misconfigured network settings on the ISP side or possibly a failure of IPv6 to IPv4 translation. I've run out of ideas and I wondered if anyone had seen anything similar or had any good ideas I could try.
 
On my new AirBand FTTP installation I've got a weird problem: some IP addresses are unreachable. For instance, if I PING 192.0.80.240 I get no reply, but 192.0.73.2 responds just fine. It seems to affect about 1 in 10 IP addresses and I can't find any sort of pattern.

I'm fairly experienced with networking, but there's still a chance I'm missing something obvious. I have an open ticket with AirBand, but they haven't made any progress as far as I know and the support process is quite opaque.

I get the same problem if I PING from the routers diagnostic page or if I plug my PC directly into the wall (bypassing the router) and PING from there. The IP addresses that fail are always the same.

My best guess is either misconfigured network settings on the ISP side or possibly a failure of IPv6 to IPv4 translation. I've run out of ideas and I wondered if anyone had seen anything similar or had any good ideas I could try.
Are the IP addresses which don't respond checked to be publicly routable addresses which correspond to a known device configured to respond on the Internet and do respond using a different ISP?
 
Are the IP addresses which don't respond checked to be publicly routable addresses which correspond to a known device configured to respond on the Internet and do respond using a different IS
Yes, they are all public addresses that resolve from domain names; in this case gravatar.com and www.gravatar.com.

I also have BT as an ISP and the IP addresses work fine when I use that network.
 
Sponsored Links
Yes, they are all public addresses that resolve from domain names; in this case gravatar.com and www.gravatar.com.

I also have BT as an ISP and the IP addresses work fine when I use that network.
Sounds like a routing issue. You can probably do a traceroute to see where things go wrong. A search at the below does seem the IP address which does not respond should be announced into the Internet. If the route goes wrong in your ISP's network, it could be something to raise with them.

You could also nmap the non-responsive IP address to ensure it's not just ICMP which is impacted. tracepath and tcptraceroute might also be useful to confirm the issue.

 
Very useful - thank you. The best and fastest results come from `tcptraceroute` which works fine on BT, but fails on AirBand when trying to route to one of the problem IP addresses:

Good IP Address

> tcptraceroute 192.0.73.2
Selected device en0, address 192.168.1.189, port 57745 for outgoing packets
Tracing the path to 192.0.73.2 on TCP port 80 (http), 30 hops max
1 192.168.1.1 120.221 ms 2.264 ms 50.388 ms
2 * * *
3 10.251.255.41 30.000 ms 23.703 ms 20.697 ms
4 jlh2.asr1.thn.air-band.net (185.130.156.109) 28.492 ms 31.030 ms 38.358 ms
5 185.130.156.118 43.843 ms 43.493 ms 40.506 ms
6 hu0-1-0-1.ccr21.lon01.atlas.cogentco.com (149.11.248.193) 42.208 ms 42.665 ms 36.572 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 192.0.73.2 [open] 28.286 ms 27.163 ms 36.261 ms


Bad IP Address

> tcptraceroute 192.0.80.240
Selected device en0, address 192.168.1.189, port 57462 for outgoing packets
Tracing the path to 192.0.80.240 on TCP port 80 (http), 30 hops max
1 192.168.1.1 128.575 ms 2.685 ms 4.048 ms
2 * * *
3 10.251.255.41 21.154 ms 20.671 ms 21.483 ms
4 jlh2.asr1.thn.air-band.net (185.130.156.109) 30.488 ms 28.104 ms 27.859 ms
5 185.130.156.118 27.306 ms 29.241 ms 28.032 ms
6 hu0-1-0-1.ccr21.lon01.atlas.cogentco.com (149.11.248.193) 27.654 ms 26.724 ms 28.891 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Destination not reached


So it looks like some sort of routing error along the path?
 
Very useful - thank you. The best and fastest results come from `tcptraceroute` which works fine on BT, but fails on AirBand when trying to route to one of the problem IP addresses:

Good IP Address

> tcptraceroute 192.0.73.2
Selected device en0, address 192.168.1.189, port 57745 for outgoing packets
Tracing the path to 192.0.73.2 on TCP port 80 (http), 30 hops max

1 192.168.1.1 120.221 ms 2.264 ms 50.388 ms
2 * * *
3 10.251.255.41 30.000 ms 23.703 ms 20.697 ms
4 jlh2.asr1.thn.air-band.net (185.130.156.109) 28.492 ms 31.030 ms 38.358 ms
5 185.130.156.118 43.843 ms 43.493 ms 40.506 ms
6 hu0-1-0-1.ccr21.lon01.atlas.cogentco.com (149.11.248.193) 42.208 ms 42.665 ms 36.572 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 192.0.73.2 [open] 28.286 ms 27.163 ms 36.261 ms


Bad IP Address

> tcptraceroute 192.0.80.240
Selected device en0, address 192.168.1.189, port 57462 for outgoing packets
Tracing the path to 192.0.80.240 on TCP port 80 (http), 30 hops max

1 192.168.1.1 128.575 ms 2.685 ms 4.048 ms
2 * * *
3 10.251.255.41 21.154 ms 20.671 ms 21.483 ms
4 jlh2.asr1.thn.air-band.net (185.130.156.109) 30.488 ms 28.104 ms 27.859 ms
5 185.130.156.118 27.306 ms 29.241 ms 28.032 ms
6 hu0-1-0-1.ccr21.lon01.atlas.cogentco.com (149.11.248.193) 27.654 ms 26.724 ms 28.891 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Destination not reached


So it looks like some sort of routing error along the path?
The route seems to have gone out onto the internet so less likely to be an issue of the ISP. The good and bad routes seem essentially identical so it's a mystery why you don't get reachability to both, or the target devices fail to send a response on the return route to you.

I'd be tempted to compare with the known-good ISP to see if the route converges near the end. It's possible this routing issue could resolve itself in 24 or 48 hours or might need to be reported to an administrator of one of the later hops on that route. A network administrator of one of those hops could check their routing tables and whether they see reachability. It's just a matter of whether it's important enough for anyone to care. Potentially an admin at the endpoint might care more if the ISP you are using is significant enough.

If you're behind CGNAT, there's an outside chance of an ISP firewall issue where the bad IP address is wrongly flagged as problematic for incoming traffic but this is probably clutching at straws.
 
Here are the traces for BT (the good ISP):

Good IP Address (BT)

Selected device en0, address 192.168.1.138, port 55363 for outgoing packets
Tracing the path to 192.0.73.2 on TCP port 80 (http), 30 hops max
1 192.168.1.254 3.589 ms 2.203 ms 2.312 ms
2 * * *
3 * * *
4 62.172.102.68 14.316 ms 14.771 ms 12.691 ms
5 core3-hu0-16-0-6.faraday.ukcore.bt.net (62.172.103.27) 13.920 ms 13.958 ms 14.065 ms
6 core6-hu0-0-0-35.faraday.ukcore.bt.net (62.6.201.245) 14.477 ms 17.262 ms 13.614 ms
7 166-49-209-194.gia.bt.net (166.49.209.194) 13.794 ms 12.990 ms 13.303 ms
8 195.66.226.127 16.607 ms 18.395 ms 17.635 ms
9 192.0.73.2 [open] 16.622 ms 16.307 ms 16.893 ms


Bad IP Address (BT)

Selected device en0, address 192.168.1.138, port 55287 for outgoing packets
Tracing the path to 192.0.80.240 on TCP port 80 (http), 30 hops max
1 192.168.1.254 2.727 ms 2.126 ms 2.877 ms
2 * * *
3 * * *
4 62.172.102.68 17.835 ms 22.223 ms 15.310 ms
5 peer7-et0-0-6.telehouse.ukcore.bt.net (62.172.103.37) 17.681 ms 16.166 ms 16.651 ms
6 166-49-214-194.gia.bt.net (166.49.214.194) 15.622 ms 17.097 ms 16.306 ms
7 ldn-b3-link.ip.twelve99.net (213.248.71.146) 16.805 ms 18.067 ms 17.828 ms
8 ldn-bb4-link.ip.twelve99.net (62.115.122.180) 25.740 ms 16.246 ms 17.105 ms
9 adm-bb4-link.ip.twelve99.net (62.115.113.238) 24.279 ms 22.838 ms 23.254 ms
10 adm-b1-link.ip.twelve99.net (62.115.137.65) 21.856 ms 22.360 ms 26.481 ms
11 automattic-ic341610-adm-b1.ip.twelve99-cust.net (62.115.170.93) 22.992 ms 22.498 ms 22.952 ms
12 wordpress.com (198.181.119.102) 113.543 ms 117.277 ms 113.077 ms
13 wordpress.com (198.181.119.23) 136.661 ms 133.094 ms 132.477 ms
14 wordpress.com (198.181.119.79) 135.829 ms 135.300 ms 135.337 ms
15 * * *
16 192.0.80.240 [open] 136.577 ms 145.294 ms 136.587 ms


There's almost no commonality between the good and bad ISPs.

I wonder if the AirBand router is incorrectly configured somewhere along the line and sending the packets down a blind alley?

Thanks very much for giving it so much thought. At this point I'm pretty sure AirBand need to send the IP networking guy to my house or at least to the pole to run serious diagnostic tools.
 
Sponsored Links
Here are the traces for BT (the good ISP):

Good IP Address (BT)

Selected device en0, address 192.168.1.138, port 55363 for outgoing packets
Tracing the path to 192.0.73.2 on TCP port 80 (http), 30 hops max

1 192.168.1.254 3.589 ms 2.203 ms 2.312 ms
2 * * *
3 * * *
4 62.172.102.68 14.316 ms 14.771 ms 12.691 ms
5 core3-hu0-16-0-6.faraday.ukcore.bt.net (62.172.103.27) 13.920 ms 13.958 ms 14.065 ms
6 core6-hu0-0-0-35.faraday.ukcore.bt.net (62.6.201.245) 14.477 ms 17.262 ms 13.614 ms
7 166-49-209-194.gia.bt.net (166.49.209.194) 13.794 ms 12.990 ms 13.303 ms
8 195.66.226.127 16.607 ms 18.395 ms 17.635 ms
9 192.0.73.2 [open] 16.622 ms 16.307 ms 16.893 ms

Bad IP Address (BT)

Selected device en0, address 192.168.1.138, port 55287 for outgoing packets
Tracing the path to 192.0.80.240 on TCP port 80 (http), 30 hops max

1 192.168.1.254 2.727 ms 2.126 ms 2.877 ms
2 * * *
3 * * *
4 62.172.102.68 17.835 ms 22.223 ms 15.310 ms
5 peer7-et0-0-6.telehouse.ukcore.bt.net (62.172.103.37) 17.681 ms 16.166 ms 16.651 ms
6 166-49-214-194.gia.bt.net (166.49.214.194) 15.622 ms 17.097 ms 16.306 ms
7 ldn-b3-link.ip.twelve99.net (213.248.71.146) 16.805 ms 18.067 ms 17.828 ms
8 ldn-bb4-link.ip.twelve99.net (62.115.122.180) 25.740 ms 16.246 ms 17.105 ms
9 adm-bb4-link.ip.twelve99.net (62.115.113.238) 24.279 ms 22.838 ms 23.254 ms
10 adm-b1-link.ip.twelve99.net (62.115.137.65) 21.856 ms 22.360 ms 26.481 ms
11 automattic-ic341610-adm-b1.ip.twelve99-cust.net (62.115.170.93) 22.992 ms 22.498 ms 22.952 ms
12 wordpress.com (198.181.119.102) 113.543 ms 117.277 ms 113.077 ms
13 wordpress.com (198.181.119.23) 136.661 ms 133.094 ms 132.477 ms
14 wordpress.com (198.181.119.79) 135.829 ms 135.300 ms 135.337 ms
15 * * *
16 192.0.80.240 [open] 136.577 ms 145.294 ms 136.587 ms


There's almost no commonality between the good and bad ISPs.

I wonder if the AirBand router is incorrectly configured somewhere along the line and sending the packets down a blind alley?

Thanks very much for giving it so much thought. At this point I'm pretty sure AirBand need to send the IP networking guy to my house or at least to the pole to run serious diagnostic tools.
I think the four routes above should be sufficient for your ISP to debug and there shouldn't be a need for an on-site engineer. If there is a misconfiguration, it must be (99% chance) removed from your location.

The announcement of routes by BGP should be an automated process and typically they should converge unless the destination is a huge service with CDN and multicast in play.

If the ISP is happy their configuration is correct and their routing tables are correct, they might not engage to avoid wasting time based on misconfiguration of intermediate routers or the destination data center routing. You might need to evidence a systematic problem or wider breakage that correlates with complaints from their other customers.
 
I'd wager this might be an ACL or similar that targets throwing away RFC1918 addresses but has been typo'd...

Example ACLs, note reverse netmask as is typically used in big end routers.

192.168.0.0 0.0.255.255 typical correct ACL
192.168.0.0 0.0.0.255 possible typo

The typo line would result in packets destined for 192.anything being thrown away.

The issue in terms of getting this fixed is probably going to be to convince the ISP to reach out to other ISPs to get it fixed.
 
I'd wager this might be an ACL or similar that targets throwing away RFC1918 addresses but has been typo'd...

Example ACLs, note reverse netmask as is typically used in big end routers.

192.168.0.0 0.0.255.255 typical correct ACL
192.168.0.0 0.0.0.255 possible typo

The typo line would result in packets destined for 192.anything being thrown away.

The issue in terms of getting this fixed is probably going to be to convince the ISP to reach out to other ISPs to get it fixed.
This is an interesting theory. Possibly counter to that there are plenty of problematic IP addresses that don't follow the same pattern:

199.232.57.140 (reddit)
209.216.230.240 (hacker news)
163.171.130.108
163.171.130.110
194.135.94.168

In retrospect I probably shouldn't have chosen an example that started with 192.
 
This is an interesting theory. Possibly counter to that there are plenty of problematic IP addresses that don't follow the same pattern:

199.232.57.140 (reddit)
209.216.230.240 (hacker news)
163.171.130.108
163.171.130.110
194.135.94.168

In retrospect I probably shouldn't have chosen an example that started with 192.
Ah fair cop then. Not a 192 typo!

Next theory is that the destinations either are hosted in a particular AS (autonomous system, typically an ISP or single network entity) that has a routing issue, or there's a specific network AS over which these destinations need to route via that has a peering problem that your ISP depends on.

I think you're going to need to send in some traceroutes (ICMP and TCP) showing the issue and comparing to a working network connection like BT. Good luck!
 
Sponsored Links
Top
Cheap BIG ISPs for 100Mbps+
Community Fibre UK ISP Logo
150Mbps
Gift: None
Virgin Media UK ISP Logo
Virgin Media £22.99
132Mbps
Gift: None
Vodafone UK ISP Logo
Vodafone £24.00 - 26.00
150Mbps
Gift: None
NOW UK ISP Logo
NOW £24.00
100Mbps
Gift: None
Plusnet UK ISP Logo
Plusnet £25.99
145Mbps
Gift: £50 Reward Card
Large Availability | View All
Cheapest ISPs for 100Mbps+
Gigaclear UK ISP Logo
Gigaclear £17.00
200Mbps
Gift: None
Community Fibre UK ISP Logo
150Mbps
Gift: None
Virgin Media UK ISP Logo
Virgin Media £22.99
132Mbps
Gift: None
Hey! Broadband UK ISP Logo
150Mbps
Gift: None
Youfibre UK ISP Logo
Youfibre £23.99
150Mbps
Gift: None
Large Availability | View All
Sponsored Links
The Top 15 Category Tags
  1. FTTP (6026)
  2. BT (3639)
  3. Politics (2721)
  4. Business (2439)
  5. Openreach (2405)
  6. Building Digital UK (2330)
  7. Mobile Broadband (2146)
  8. FTTC (2083)
  9. Statistics (1901)
  10. 4G (1816)
  11. Virgin Media (1764)
  12. Ofcom Regulation (1582)
  13. Fibre Optic (1467)
  14. Wireless Internet (1462)
  15. 5G (1407)
Sponsored

Copyright © 1999 to Present - ISPreview.co.uk - All Rights Reserved - Terms  ,  Privacy and Cookie Policy  ,  Links  ,  Website Rules