laltobelli
asked on
Dual WAN router creates loop
Hello,
I have an RV042 dual WAN router setup with two WAN connections, one is static and the other is dynamic. I am trying to setup a VPN connection using the static IP, but I get no response. When I Ping the static IP I get "TTL expired in transit", indicating some kind of loop. Doing a tracert I get:
10 87 ms 86 ms 87 ms cr1.n54ny.ip.att.net [12.122.80.226]
11 89 ms 88 ms 92 ms cr2.cgcil.ip.att.net [12.122.1.2]
12 88 ms 90 ms 90 ms cr1.cgcil.ip.att.net [12.122.2.53]
13 88 ms 88 ms 86 ms cr1.sffca.ip.att.net [12.122.4.121]
14 87 ms 86 ms 91 ms 12.123.155.117
15 88 ms 90 ms 88 ms 151.164.99.234
16 88 ms 90 ms 88 ms 151.164.99.233
17 88 ms 87 ms 87 ms 151.164.99.234
18 90 ms 92 ms 89 ms 151.164.99.233
19 88 ms 91 ms 87 ms 151.164.99.234
20 90 ms 90 ms 87 ms 151.164.99.233
21 89 ms 87 ms 87 ms 151.164.99.234
22 87 ms 87 ms 87 ms 151.164.99.233
23 87 ms 87 ms 87 ms 151.164.99.234
24 89 ms 87 ms 87 ms 151.164.99.233
25 86 ms 87 ms 87 ms 151.164.99.234
26 87 ms 87 ms 91 ms 151.164.99.233
27 88 ms 86 ms 87 ms 151.164.99.234
28 91 ms 88 ms 86 ms 151.164.99.233
29 88 ms 87 ms 87 ms 151.164.99.234
30 96 ms 90 ms 87 ms 151.164.99.233
You can see the loop, it's not happening within my network, but external.
Any suggestions?
Thanks
lalto
I have an RV042 dual WAN router setup with two WAN connections, one is static and the other is dynamic. I am trying to setup a VPN connection using the static IP, but I get no response. When I Ping the static IP I get "TTL expired in transit", indicating some kind of loop. Doing a tracert I get:
10 87 ms 86 ms 87 ms cr1.n54ny.ip.att.net [12.122.80.226]
11 89 ms 88 ms 92 ms cr2.cgcil.ip.att.net [12.122.1.2]
12 88 ms 90 ms 90 ms cr1.cgcil.ip.att.net [12.122.2.53]
13 88 ms 88 ms 86 ms cr1.sffca.ip.att.net [12.122.4.121]
14 87 ms 86 ms 91 ms 12.123.155.117
15 88 ms 90 ms 88 ms 151.164.99.234
16 88 ms 90 ms 88 ms 151.164.99.233
17 88 ms 87 ms 87 ms 151.164.99.234
18 90 ms 92 ms 89 ms 151.164.99.233
19 88 ms 91 ms 87 ms 151.164.99.234
20 90 ms 90 ms 87 ms 151.164.99.233
21 89 ms 87 ms 87 ms 151.164.99.234
22 87 ms 87 ms 87 ms 151.164.99.233
23 87 ms 87 ms 87 ms 151.164.99.234
24 89 ms 87 ms 87 ms 151.164.99.233
25 86 ms 87 ms 87 ms 151.164.99.234
26 87 ms 87 ms 91 ms 151.164.99.233
27 88 ms 86 ms 87 ms 151.164.99.234
28 91 ms 88 ms 86 ms 151.164.99.233
29 88 ms 87 ms 87 ms 151.164.99.234
30 96 ms 90 ms 87 ms 151.164.99.233
You can see the loop, it's not happening within my network, but external.
Any suggestions?
Thanks
lalto
ASKER
Those devices are not on my network they are on the internet and are possibly owned by sbcglobal.net or ATT... via a couple of reverse IP lookups....
Is AT&T your ISP? If so you you need to contact AT&T.
If AT&T is not your ISP, you need to contact your ISP first and find out what is going on.
If AT&T is not your ISP, you need to contact your ISP first and find out what is going on.
ASKER
No my ISP is Charter (where I am pinging from) and the ISP at the dual WAN router is Verizon. The packets had long left the Charter servers, between hop 6 and 7.
You will want to contact Verizon. They are responsible for making sure AT&T has the correct routing entries for IP addresses they own.
Do you have the same problem when to a trace route to any/all of your IP addresses at the Verizon end?
Do you have the same problem when to a trace route to any/all of your IP addresses at the Verizon end?
15 88 ms 90 ms 88 ms 151.164.99.234
16 88 ms 90 ms 88 ms 151.164.99.233
this is not a loop ...you see this repetedly because of provider ..sometime provider blocks trace & ping because of it when you do trace you won't see all the hops..and your outputs results in this way..
show this output to your provider.
16 88 ms 90 ms 88 ms 151.164.99.233
this is not a loop ...you see this repetedly because of provider ..sometime provider blocks trace & ping because of it when you do trace you won't see all the hops..and your outputs results in this way..
show this output to your provider.
guptasan26, I have to disagree with you. I have seen blocks and I have seen routing loops. This looks like a routing loop to me.
If it were a simple block the traceroute to that hop would simply timeout and you would get no results for the hop that is blocking the ICMP.
This is a case where it appears that 151.164.99.233 thinks the next hop should be 151.164.99.234 and thus forwards the request to it. Then 151.164.99.234 thinks the next hop should be 151.164.99.233 and forwards it back.
If it were a simple block the traceroute to that hop would simply timeout and you would get no results for the hop that is blocking the ICMP.
This is a case where it appears that 151.164.99.233 thinks the next hop should be 151.164.99.234 and thus forwards the request to it. Then 151.164.99.234 thinks the next hop should be 151.164.99.233 and forwards it back.
what I mean from "not a loop" is that this is not a routing loop..it is the problem from provider and it apprears because providers blocks ping & trace sometimes.
I understand what you are saying and I am saying I disagree with your assessment of the situation based on my experience. Not saying your wrong, just base on what I have experienced I think it is something different.
Typical when ICMP is blocked you would see request timeout on the hop blocking ICMP. Not bouncing it back and forth between two routers. Especially two routers in the "middle" of the network. On the edge between the ISP and the customer, maybe, but the two routers that are going back and forth are AT&T and the customers ISP is Verizon.
If what you are saying is true that would mean that either AT&T is blocking ICMP in the middle of their network, on the edge between them and Verizon, or Verizon is blocking ICMP in between them and AT&T. Although that is possible, I personally have never seen it with AT&T or Verizon and I have used both of them as ISP's for close to 15 years now.
I have seen routing loops also and they look just like the output from laltobelli post. Now, I will say normally when I encounter a routing loop it is due to a link being down and routers are trying to find a way to get to the next hop.
Typical when ICMP is blocked you would see request timeout on the hop blocking ICMP. Not bouncing it back and forth between two routers. Especially two routers in the "middle" of the network. On the edge between the ISP and the customer, maybe, but the two routers that are going back and forth are AT&T and the customers ISP is Verizon.
If what you are saying is true that would mean that either AT&T is blocking ICMP in the middle of their network, on the edge between them and Verizon, or Verizon is blocking ICMP in between them and AT&T. Although that is possible, I personally have never seen it with AT&T or Verizon and I have used both of them as ISP's for close to 15 years now.
I have seen routing loops also and they look just like the output from laltobelli post. Now, I will say normally when I encounter a routing loop it is due to a link being down and routers are trying to find a way to get to the next hop.
ASKER
Ok, I tried this from a comcast account and got some interesting results. The hops got to a Verizon server and then timed out. Trace is below, I think it's time to call Verizon....
5 10 ms 13 ms 11 ms te-8-1-ur01.natick.ma.bost on.comcast .net [68.87.144.197]
6 16 ms 19 ms 15 ms te-0-15-0-6-ar01.needham.m a.boston.c omcast.net [68.85.69.94]
7 38 ms 47 ms 47 ms he-2-9-0-0-cr01.newyork.ny .ibone.com cast.net [68.86.90.57]
8 36 ms 37 ms 37 ms pos-0-4-0-0-pe01.111eighth ave.ny.ibo ne.comcast .net [68.86.85.22]
9 * 45 ms * Vlan569.icore1.NTO-NewYork .as6453.ne t [209.58.26.137]
10 38 ms 37 ms 37 ms Vlan590.icore1.NTO-NewYork .as6453.ne t [209.58.26.94]
11 52 ms 53 ms 47 ms 0.ge-4-0-0.BOS-BB-RTR2.ALT ER.NET [152.63.20.110]
12 46 ms 56 ms 46 ms so-7-1-0-0.BOS-CORE-RTR2.v erizon-gni .net [130.81.20.87]
13 47 ms 47 ms 47 ms A4-0-0-1711.BOS-DSL-RTR1.v erizon-gni .net [130.81.7.22]
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
5 10 ms 13 ms 11 ms te-8-1-ur01.natick.ma.bost
6 16 ms 19 ms 15 ms te-0-15-0-6-ar01.needham.m
7 38 ms 47 ms 47 ms he-2-9-0-0-cr01.newyork.ny
8 36 ms 37 ms 37 ms pos-0-4-0-0-pe01.111eighth
9 * 45 ms * Vlan569.icore1.NTO-NewYork
10 38 ms 37 ms 37 ms Vlan590.icore1.NTO-NewYork
11 52 ms 53 ms 47 ms 0.ge-4-0-0.BOS-BB-RTR2.ALT
12 46 ms 56 ms 46 ms so-7-1-0-0.BOS-CORE-RTR2.v
13 47 ms 47 ms 47 ms A4-0-0-1711.BOS-DSL-RTR1.v
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
That indicates that whatever hops are after 139.81.7.22 are blocking/dropping ICMP requests.
The name of the last router that responded implies that it is a DSL device, in Boston perhaps. Could this be the last Verizon device before hitting your work place router/firewall?
Does the rotuer/firewall at your work place allow ICMP through?
The name of the last router that responded implies that it is a DSL device, in Boston perhaps. Could this be the last Verizon device before hitting your work place router/firewall?
Does the rotuer/firewall at your work place allow ICMP through?
ASKER
The router is an RV042, as I understand this model cannot filter on protocol. I can ping the DHCP wan port without a problem.
This could be the last device before hitting my router, my router location is just outside of Boston.
This could be the last device before hitting my router, my router location is just outside of Boston.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi giltjr,
You hit it. Although I've used this router in the past and do not remember having to disable "Block WAN Request"
Anyways that appears to have resolved the issue and not only can I ping I can now access VPN>
Thanks,
laltobelli
You hit it. Although I've used this router in the past and do not remember having to disable "Block WAN Request"
Anyways that appears to have resolved the issue and not only can I ping I can now access VPN>
Thanks,
laltobelli
151.164.99.233
151.164.99.234
What does the routing table look like on those devices?