Options
Strange real life problem...
I am having the strangest issue at work. I am hoping folks smarter than I can help shed some light because Verizon told us to f off. lol
We have a Verizon connection acting as our backup link in the case our Comcast link goes down. We also have configured routing policy for certain devices that sit on our network to get sent to the next-hop of the Verizon link, while not ever having Verizon in our routing table as the default route. We want all traffic exiting Comcast when it is up/up. Here is our policy:
access-list 5 permit 10.10.50.30
!
route-map POLICY_1 permit 10
match ip address 5
set ip next-hop 61.254.218.1
!
interface Vlan100 (This goes to our SonicWALL)
ip address 10.10.50.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip route-cache policy
ip policy route-map POLICY_1
!
Now, 10.10.50.30 is a DNS box that gets NAT'ed in the firewall from 10.10.100.20. Once it hits the 2811 there is a static NAT for the 10.10.50.30 address translating that to 61.254.218.51.
We have 13 IP's from Verizon, and we gave the 2811 F0/1 interface (to Verizon modem) a 61.254.218.50 address. When there is no static NAT it works exactly as it should, with the device PAT'ing and showing getting the .50, which is cool. We can even get it to work by putting, let's say .51 as the primary interface IP, then pinging 61.254.218.1, then creating the static NAT entry of:
ip nat inside source static 10.10.50.20 71.254.218.51
This will work for 4-5 hours with full interwebz access and showing as having an external of .51, but then it will die and it is not usable at all. You cannot even ping the DG of .1. It is driving me nuts! Pings go out, they just never return...
I have ran "debug ip nat 5" which shows it translating as it should, but it is like there is something on the other end saying, "I don't think so silly bastard".
It works perfectly in GNS3/Dynamips so how dare real world do this to me! :P
If anyone has any thoughts on this or has seen something like this, it would be greatly appreciated.
I do find it odd we have basically a 16 block in the .48 network, but our DG is still .1 with a 24-bit mask. I am sure that is just me being a newb to ISP innerworkings.
Thanks for listening.
We have a Verizon connection acting as our backup link in the case our Comcast link goes down. We also have configured routing policy for certain devices that sit on our network to get sent to the next-hop of the Verizon link, while not ever having Verizon in our routing table as the default route. We want all traffic exiting Comcast when it is up/up. Here is our policy:
access-list 5 permit 10.10.50.30
!
route-map POLICY_1 permit 10
match ip address 5
set ip next-hop 61.254.218.1
!
interface Vlan100 (This goes to our SonicWALL)
ip address 10.10.50.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip route-cache policy
ip policy route-map POLICY_1
!
Now, 10.10.50.30 is a DNS box that gets NAT'ed in the firewall from 10.10.100.20. Once it hits the 2811 there is a static NAT for the 10.10.50.30 address translating that to 61.254.218.51.
We have 13 IP's from Verizon, and we gave the 2811 F0/1 interface (to Verizon modem) a 61.254.218.50 address. When there is no static NAT it works exactly as it should, with the device PAT'ing and showing getting the .50, which is cool. We can even get it to work by putting, let's say .51 as the primary interface IP, then pinging 61.254.218.1, then creating the static NAT entry of:
ip nat inside source static 10.10.50.20 71.254.218.51
This will work for 4-5 hours with full interwebz access and showing as having an external of .51, but then it will die and it is not usable at all. You cannot even ping the DG of .1. It is driving me nuts! Pings go out, they just never return...
I have ran "debug ip nat 5" which shows it translating as it should, but it is like there is something on the other end saying, "I don't think so silly bastard".
It works perfectly in GNS3/Dynamips so how dare real world do this to me! :P
If anyone has any thoughts on this or has seen something like this, it would be greatly appreciated.
I do find it odd we have basically a 16 block in the .48 network, but our DG is still .1 with a 24-bit mask. I am sure that is just me being a newb to ISP innerworkings.
Thanks for listening.
policy-map type inspect TACO
class type inspect BELL
drop log
class type inspect BELL
drop log
Comments
-
Options
jezg76
Member Posts: 97 ■■□□□□□□□□
Cisco TAC has had my problem for a week and this is what I get yesterday:
ip nat translation timeout 3600
ip nat translation tcp-timeout 3600
This did not work as I am actually glad it didn't because I could not understand how that would fix the issue I am having.
Strangest damn issue. Works fine for 4-6 hours then breaks. Damn you Verizon. Damn you to hell. :Ppolicy-map type inspect TACO
class type inspect BELL
drop log -
Options
EdTheLad
Member Posts: 2,111 ■■■■□□□□□□
You really need to practice communicating your problems better.The description you provided above was all over the place, i dont know how anyone unfamiliar with your setup could troubleshoot this.Take this as constructive critisism as its very important in this business to be able to communicate your issues.If i was working TAC and received that description, my reply would be draw a diagram, if you cant put the effort in to describe a problem clearly why should someone put the effort in to help you.
Anyway provide some configs, explain your problem with the mindset that we are idiots.Networking, sometimes i love it, mostly i hate it.Its all about the $$$$ -
Optionsjezg76
Member Posts: 97 ■■□□□□□□□□
I appreciate the input Ed. I will most definitely work on that. I did write that with heavy emphasis put on you guys knowing my setup here. My apologies.
Good news, though! We got rid of the Verizon DSL and got a dedicated T1 circuit for other purposes. I configured it exactly the same as I did for the Verizon link and it works perfectly as it did in Dynamips.
When our primary link fails, the T1 acts as the backup link until Comcast is restored, while also allowing one of our DNS boxes to be using the T1 link as its primary link; receiving a public IP on that network, as well.
I am just happy it wasn't my config.
policy-map type inspect TACO
class type inspect BELL
drop log