5 recommendations |
Has Vz disabled TTL propagation?I'm noticing some weirdness with tracerts done recently. The only hops are my router, and the destination. This is occurring on multiple computers, multiple operating systems (Windows and Linux). Same issue with the Verizon router and third-party router. If I plug a laptop directly into the ONT, tracert only shows the destination hop. I'm thinking Verizon has disabled TTL propagation. I checked at a friend's house with fios, and I'm not seeing the same at his place, but he's not close enough that we'd be on the same circuit. Has anybody else seen anything similar? C:\>tracert google.com
Tracing route to google.com [172.217.11.46]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms router [192.168.1.1]
2 1 ms <1 ms 1 ms lga25s61-in-f14.1e100.net [172.217.11.46]
Trace complete.
C:\>tracert dslreports.com
Tracing route to dslreports.com [64.91.255.98]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms router [192.168.1.1]
2 1 ms 1 ms 1 ms www.dslreports.com [64.91.255.98]
Trace complete.
|
|
|
4 recommendations |
Yes, I'm seeing the same behavior here. |
|
4 recommendations |
to yyonline
|
|
3 recommendations |
I am seeing it on windows.
On Unix variants (MacOs, Linux) I am not seeing it although I am seeing multiple IP's per hop. |
|
kaboose join:2016-12-10 Gaithersburg, MD
3 recommendations |
|
|
3 recommendations |
to yyonline
Try to do it manually. On Windows machines, ping -i x [target] with x being your TTL hop count. Start at 1 and move outwards. Linux (and, presumably, Unix/BSD) is ping -t x [target].
TTL Exceeded is a unicast ICMP response, as well, so Verizon wouldn't just have to 'turn it off' (which they usually do for their core/backbone routing infrastructure), they would have to be actively blocking responses from off their network. That would be strange.
One new behavior I'm seeing, though, is my local GWR isn't responding with TTL Exceeded anymore, when it used to. Local LCR is, which it didn't used to do. Very strange. |
|
4 recommendations |
From Windows: C:\Users\username>pinggoogle.bat
C:\Users\username>ping google.com -i 1
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 192.168.1.1: TTL expired in transit.
Reply from 192.168.1.1: TTL expired in transit.
Reply from 192.168.1.1: TTL expired in transit.
Reply from 192.168.1.1: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 2
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 172.217.10.14: bytes=32 time=6ms TTL=254
Reply from 172.217.10.14: bytes=32 time=1ms TTL=254
Reply from 172.217.10.14: bytes=32 time=1ms TTL=254
Reply from 172.217.10.14: bytes=32 time=1ms TTL=254
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 6ms, Average = 2ms
C:\Users\username>ping google.com -i 3
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 130.81.221.112: TTL expired in transit.
Reply from 130.81.221.112: TTL expired in transit.
Reply from 130.81.221.112: TTL expired in transit.
Reply from 130.81.221.112: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 4
Pinging google.com [172.217.10.14] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\username>ping google.com -i 5
Pinging google.com [172.217.10.14] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\username>ping google.com -i 6
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 140.222.2.229: TTL expired in transit.
Reply from 140.222.2.229: TTL expired in transit.
Reply from 140.222.2.229: TTL expired in transit.
Reply from 140.222.2.229: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 7
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 209.85.149.208: TTL expired in transit.
Reply from 209.85.149.208: TTL expired in transit.
Reply from 209.85.149.208: TTL expired in transit.
Reply from 209.85.149.208: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 8
Pinging google.com [172.217.10.14] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\username>ping google.com -i 9
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 108.170.237.210: TTL expired in transit.
Reply from 108.170.237.210: TTL expired in transit.
Reply from 108.170.237.210: TTL expired in transit.
Reply from 108.170.237.210: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 10
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 108.170.248.84: TTL expired in transit.
Reply from 108.170.248.84: TTL expired in transit.
Reply from 108.170.248.84: TTL expired in transit.
Reply from 108.170.248.84: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 11
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 216.239.58.121: TTL expired in transit.
Reply from 216.239.58.121: TTL expired in transit.
Reply from 216.239.58.121: TTL expired in transit.
Reply from 216.239.58.121: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 12
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 209.85.255.53: TTL expired in transit.
Reply from 209.85.255.53: TTL expired in transit.
Reply from 209.85.255.53: TTL expired in transit.
Reply from 209.85.255.53: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 13
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 108.170.248.33: TTL expired in transit.
Reply from 108.170.248.33: TTL expired in transit.
Reply from 108.170.248.33: TTL expired in transit.
Reply from 108.170.248.33: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 14
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 216.239.62.149: TTL expired in transit.
Reply from 216.239.62.149: TTL expired in transit.
Reply from 216.239.62.149: TTL expired in transit.
Reply from 216.239.62.149: TTL expired in transit.
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
C:\Users\username>ping google.com -i 15
Pinging google.com [172.217.10.14] with 32 bytes of data:
Reply from 172.217.10.14: bytes=32 time=5ms TTL=56
Reply from 172.217.10.14: bytes=32 time=6ms TTL=56
Reply from 172.217.10.14: bytes=32 time=6ms TTL=56
Reply from 172.217.10.14: bytes=32 time=6ms TTL=56
Ping statistics for 172.217.10.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 6ms, Average = 5ms
Will try on Linux after work, as I need Windows for work. |
|
5 recommendations |
Anon9b5f5 to yyonline
Anon
2018-Oct-2 11:23 am
to yyonline
Seeing same in northern NJ.
This is usually indicative of a buggy or botched MPLS deployment. Verizon has previously stated that they are deploying 6PE services (basically tunneling IPv6 inside of an IPv4/MPLS core), so this, as with the other thread, could be an indication that IPv6 is about to roll out wider... |
|
tito79 join:2010-03-14 Port Saint Lucie, FL
3 recommendations |
tito79
Member
2018-Oct-2 12:56 pm
Yes for there 5g home services |
|
3 recommendations |
to Anon9b5f5
Well at least it's not just me |
|
PA23 join:2001-12-12 East Hanover, NJ
4 recommendations |
to yyonline
Looks like it depends upon if you are using ICMP or UDP for your traceroute queries.
For example, Unix/Linux uses UDP by default with traceroute, however if you specify the "-I" option traceroute will use ICMP. I don't know how WindoZe implements traceroute so I can't comment.
If you use ICMP for your query then you only get back the final destination on the reply, if your traceroute uses UDP for traceroute then you will get the intermediate hops to the destination. Remember all you are looking for is the response from a router/device along the way to say that the TTL is expired, it doesn't really matter what protocol was used to get that message.
Oh and getting back multiple addresses just says that there are multiple paths that you are taking TO your destination, it says nothing about the return path from the destination.
-PA |
|
5 recommendations |
Lexatt
Member
2018-Oct-3 8:55 am
said by PA23:For example, Unix/Linux uses UDP by default with traceroute, however if you specify the "-I" option traceroute will use ICMP. I don't know how WindoZe implements traceroute so I can't comment. Windows uses ICMP by default. Mac/BSD use UDP. Using both UDP and ICMP traceroute on a SUSE machine, I get the same results I get off my Windows machine. |
|
phibs join:2012-09-25 Newark, DE 2 edits
5 recommendations |
to yyonline
Yep been seeing the same thing here with mtr and ICMP! Whatever they misconfigured it sucks... $ mtr -4 --report www.google.com
1.|-- core1-vl100.fiber.house 0.0% 10 0.2 0.2 0.1 0.2 0.0
2.|-- fw1.fiber.house 0.0% 10 0.2 0.2 0.1 0.2 0.0
3.|-- lga34s19-in-f4.1e100.net 0.0% 10 1.1 2.2 0.8 8.2 2.2
DHCP6-PD does *NOT* work here either. |
|
3 recommendations |
to Anon9b5f5
said by Anon9b5f5 :This is usually indicative of a buggy or botched MPLS deployment. Verizon has previously stated that they are deploying 6PE services (basically tunneling IPv6 inside of an IPv4/MPLS core), so this, as with the other thread, could be an indication that IPv6 is about to roll out wider... Taking a closer look at yyonline's results of a manual traceroute, this seems to be it. Notice the first hop after the home gateway gets you a ping response? That's messy and indicates something very weird happening (TTL should decrement at every hop, so something is being encapsulated). The strangest thing about it is it seems to be end-to-end, seeing as your traceroute is failing even once your TTL lets you get off Verizon's network. yyonline, have you had the chance to check if you're able to pull an IPv6 delegation? They might be turning up IPv6 on certain gateway routers only as a test. |
|
3 recommendations |
Still happening here in North Jersey. |
|
ScrawnyB join:2004-05-18 Mechanicsburg, PA
3 recommendations |
to m242144
Must be nice... I'm over in Mechanicsburg area and my latency just 'doubled' to my 2nd (out of network) hop in the past few weeks. VZ doesn't care when I reported it. For example, if I ping your hop 6 (140.222.2.199), that's ~18ms for me now. I'm on Gigabit, FYI. |
|
3 recommendations |
to yyonline
I get the same abbreviated result as yyonline. In Queens, NY. It didn't used to be like this a few months ago. |
|
2 recommendations |
I'm in North NJ and seems fine for me?
Tracing route to google.com [172.217.12.142] over a maximum of 30 hops:
1 1 ms 1 ms 1 ms lo0-100.NWRKNJ-VFTTP-334.verizon-gni.net [72.76.89.1] 2 5 ms 3 ms 4 ms B3334.NWRKNJ-LCR-22.verizon-gni.net [130.81.26.34] 3 * * * Request timed out. 4 5 ms 5 ms 6 ms 0.et-11-3-0.GW7.EWR6.ALTER.NET [140.222.239.51] 5 5 ms 5 ms 5 ms 209.85.149.32 6 * * * Request timed out. 7 4 ms 4 ms 4 ms 108.170.230.0 8 6 ms 7 ms 6 ms 108.170.248.2 9 7 ms 7 ms 7 ms 209.85.254.139 10 4 ms 4 ms 5 ms 209.85.255.53 11 6 ms 6 ms 6 ms 108.170.248.97 12 6 ms 5 ms 6 ms 108.170.227.209 13 5 ms 6 ms 6 ms lga34s19-in-f14.1e100.net [172.217.12.142]
Is it only using the VZ router? |
|
phibs join:2012-09-25 Newark, DE
3 recommendations |
to yyonline
Sadly this still isn't fixed |
|
3 recommendations |
to mario44222
I still get what appears to be a valid trace route using udp.
I still get the truncated trace route with icmp. |
|
3 recommendations |
to yyonline
Queens, NY. Here's my output on a Windows machine: Tracing route to google.com [172.217.10.142]
over a maximum of 30 hops:
1 <1 ms 3 ms <1 ms 192.168.0.1
2 1 ms 1 ms 1 ms lga34s16-in-f14.1e100.net [172.217.10.142]
Trace complete.
Also, all my ports are currently blocked inbound. |
|
mikev Premium Member join:2002-05-04 Leesburg, VA ·Verizon FiOS (Software) pfSense Panasonic KX-TGP600
4 recommendations |
mikev
Premium Member
2018-Oct-30 10:40 pm
Hmm... CGNAT maybe? the inbound port blocking is what's making me think that (since Verizon's NAT would come before your router's)... They do it on their wireless network. My phone shows an address in IANA reserved space (100.64.0.0/10), but various web tests show a Verizon public IP address (174.204.20.xx)... so why not do it on FiOS too, especially since IPv6 is (slowly) rolling out. Check your WAN address and run an ARIN Whois on it (search box in the upper right corner of the page)... see if it comes back as Verizon (or MCI/Worldcom or Verizon Business) or something else. |
|
3 recommendations |
Lexatt
Member
2018-Oct-30 10:53 pm
said by mikev:Hmm... CGNAT maybe? the inbound port blocking is what's making me think that (since Verizon's NAT would come before your router's)... They do it on their wireless network. My phone shows an address in IANA reserved space (100.64.0.0/10), but various web tests show a Verizon public IP address (174.204.20.xx)... so why not do it on FiOS too, especially since IPv6 is (slowly) rolling out. Mine just started doing this recently and my internet facing IP address matches the WAN IP address my router lists for itself. As an Anon pointed out above: said by Anon9b5f5 :This is usually indicative of a buggy or botched MPLS deployment. Verizon has previously stated that they are deploying 6PE services (basically tunneling IPv6 inside of an IPv4/MPLS core), so this, as with the other thread, could be an indication that IPv6 is about to roll out wider... This is a configuration issue in the MPLS backbone that carries your traffic throughout the Verizon network, likely related to the recent start of an IPv6 rollout. It'll get resolved someday but getting things brought to the NOC's attention is like pulling teeth with Teamviewer and a set of remote Helping Hands. Then it needs to go from the NOC to Engineering, which is its own process. It'll likely end up being fixed as the IPv6 rollout becomes wider and the sheer volume of tickets gets things done. |
|
3 recommendations |
to yyonline
Happening in Pittsburgh PA too. |
|
sTs950 join:2003-07-29 Bel Air, MD
3 recommendations |
to yyonline
this just started happening in Bel Air, Maryland... hopefully an indication of ipv6 coming soon? |
|
3 recommendations |
to mikev
said by mikev:Hmm... CGNAT maybe? the inbound port blocking is what's making me think that (since Verizon's NAT would come before your router's)... They do it on their wireless network. My phone shows an address in IANA reserved space (100.64.0.0/10), but various web tests show a Verizon public IP address (174.204.20.xx)... so why not do it on FiOS too, especially since IPv6 is (slowly) rolling out.
Check your WAN address and run an ARIN Whois on it (search box in the upper right corner of the page)... see if it comes back as Verizon (or MCI/Worldcom or Verizon Business) or something else. I really hope CGNAT is something we can opt out of, I occasionally connect to my house for cameras/home automation stuff that's not cloud based. Also work inbound connectivity is locked down to a dynamic DNS address we set up so they can lock us down by IP. Bunch of us on Verizon would be in trouble if that's the case. |
|
jades join:2013-04-01 New York, NY
3 recommendations |
to yyonline
I noticed this a month ago too. If you do an MTR it comes out totally off, but if you do a full traceroute it works. I only have this issue on DHCP verizon lines. Anyone with static IP, for now, does not have this issue
what i also noticed for the DHCP customers is that verizon is not responding to pings on that second hop, which I assume is why the MTR's come out bad
Temporary workaround is to run mtr IP -u but the problem with that is that it will not show the last hop. Better than nothing though. Hope they fix this soon, there was absolutely no reason to do this other than to cause an inconvenience. |
|
Smith6612 MVM join:2008-02-01 North Tonawanda, NY ·Charter Ubee EU2251 Ubiquiti UAP-IW-HD Ubiquiti UniFi AP-AC-HD
5 recommendations |
to noebl1
Verizon had a page for this years ago which was opened up when the first "Carrier Grade NAT" scare came out. It was originally brought up for DSL users, not FiOS. I can't bring it up anymore since I'm no longer a Verizon DSL customer, but the page provided an opt-out to usage of Carrier Grade NAT in the event that Verizon were to roll it out. |
|
6 recommendations |
to noebl1
said by noebl1:I really hope CGNAT is something we can opt out of, I occasionally connect to my house for cameras/home automation stuff that's not cloud based.
Also work inbound connectivity is locked down to a dynamic DNS address we set up so they can lock us down by IP. Bunch of us on Verizon would be in trouble if that's the case. said by Smith6612:Verizon had a page for this years ago which was opened up when the first "Carrier Grade NAT" scare came out. It was originally brought up for DSL users, not FiOS. I can't bring it up anymore since I'm no longer a Verizon DSL customer, but the page provided an opt-out to usage of Carrier Grade NAT in the event that Verizon were to roll it out. AS has been noted, this isn't CGNAT. |
|
nh5 join:2006-01-21 Old Bethpage, NY
3 recommendations |
to yyonline
Well finding this thread certainly helped. I noticed this two days ago and was in the midst of tearing my pfsense apart trying to figure out what I changed that started triggering this. Good to see it's not just me. |
|