dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
17089
yyonline
join:2009-02-09
Downingtown, PA

5 recommendations

yyonline

Member

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.
 
cuda74360
join:2008-11-08
Halethorpe, MD

4 recommendations

cuda74360

Member

Yes, I'm seeing the same behavior here.
m242144
join:2018-09-27
Palmyra, PA

4 recommendations

m242144 to yyonline

Member

to yyonline
Click for full size
not for me
cram501
join:2008-11-29
Ashburn, VA

3 recommendations

cram501

Member

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

kaboose

Member

Click for full size
Seems fine here
Lexatt
join:2017-02-22
USA

3 recommendations

Lexatt to yyonline

Member

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.
yyonline
join:2009-02-09
Downingtown, PA

4 recommendations

yyonline

Member

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.

Anon9b5f5
@verizon.net

5 recommendations

Anon9b5f5 to yyonline

Anon

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

Yes for there 5g home services
yyonline
join:2009-02-09
Downingtown, PA

3 recommendations

yyonline to Anon9b5f5

Member

to Anon9b5f5
Well at least it's not just me

PA23
join:2001-12-12
East Hanover, NJ

4 recommendations

PA23 to yyonline

Member

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
Lexatt
join:2017-02-22
USA

5 recommendations

Lexatt

Member

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

phibs to yyonline

Member

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.
Lexatt
join:2017-02-22
USA

3 recommendations

Lexatt to Anon9b5f5

Member

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.
synthexic
join:2018-02-23
Hoboken, NJ

3 recommendations

synthexic

Member

Still happening here in North Jersey.
ScrawnyB
join:2004-05-18
Mechanicsburg, PA

3 recommendations

ScrawnyB to m242144

Member

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.
michaelholt
join:2018-10-29
Forest Hills, NY

3 recommendations

michaelholt to yyonline

Member

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.
mario44222
join:2003-11-22
Cliffside Park, NJ

2 recommendations

mario44222

Member

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

phibs to yyonline

Member

to yyonline
Sadly this still isn't fixed
cram501
join:2008-11-29
Ashburn, VA

3 recommendations

cram501 to mario44222

Member

to mario44222
I still get what appears to be a valid trace route using udp.

I still get the truncated trace route with icmp.
michaelholt
join:2018-10-29
Forest Hills, NY

3 recommendations

michaelholt to yyonline

Member

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

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.
Lexatt
join:2017-02-22
USA

3 recommendations

Lexatt

Member

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.
astouffer
join:2006-02-22
East Pittsburgh, PA

3 recommendations

astouffer to yyonline

Member

to yyonline
Happening in Pittsburgh PA too.
sTs950
join:2003-07-29
Bel Air, MD

3 recommendations

sTs950 to yyonline

Member

to yyonline
this just started happening in Bel Air, Maryland... hopefully an indication of ipv6 coming soon?
noebl1
join:2003-01-03
MA, USA

3 recommendations

noebl1 to mikev

Member

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

jades to yyonline

Member

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

Smith6612 to noebl1

MVM

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.
Lexatt
join:2017-02-22
USA

6 recommendations

Lexatt to noebl1

Member

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

nh5 to yyonline

Member

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.