04-26-2013 10:24 AM - edited 03-04-2019 07:44 PM
Hello,
We're seeing a strange issue with a Cisco 819 that we're testing out. We are able to ping out over the Cellular interface just fine, but as soon as we plug a device into one of the FastEthernet ports we immediately drop the cell connection. The Cell interface then continues to bounce until we unplug the device. We are intending to setup a VPN tunnel, but we've even stripped all that out for the sake of troubleshooting.
What am I missing?!?!
Thanks
Current configuration : 2832 bytes
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname Test
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
memory-size iomem 10
!
!
ip cef
!
!
!
!
!
no ip dhcp conflict logging
ip dhcp excluded-address 172.16.5.1
!
ip dhcp pool mypool
import all
network 172.16.5.0 255.255.255.0
default-router 172.16.5.1
dns-server 4.2.2.2
!
!
!
no ipv6 cef
!
!
multilink bundle-name authenticated
chat-script lte "" "AT!CALL1" TIMEOUT 60 "OK"
license udi pid C819HG-4G-V-K9 sn FTX171182XX
!
!
!
!
!
!
!
controller Cellular 0
!
csdb tcp synwait-time 30
csdb tcp idle-time 3600
csdb tcp finwait-time 5
csdb tcp reassembly max-memory 1024
csdb tcp reassembly max-queue-length 16
csdb udp idle-time 30
csdb icmp idle-time 10
csdb session max-session 65535
!
!
!
!
!
!
!
!
!
interface Cellular0
ip address negotiated
ip mtu 1452
encapsulation slip
dialer in-band
dialer pool-member 1
dialer-group 1
async mode interactive
routing dynamic
!
interface FastEthernet0
switchport access vlan 2
no ip address
!
interface FastEthernet1
switchport access vlan 2
no ip address
!
interface FastEthernet2
switchport access vlan 2
no ip address
!
interface FastEthernet3
switchport access vlan 2
no ip address
!
interface GigabitEthernet0
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0
no ip address
shutdown
clock rate 2000000
!
interface Vlan1
no ip address
!
interface Vlan2
description LAN interface
ip address 172.16.5.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip virtual-reassembly in
no ip route-cache
!
interface Dialer1
ip address negotiated
ip mtu 1452
encapsulation slip
dialer pool 1
dialer idle-timeout 0
dialer string lte
dialer persistent
dialer-group 1
!
ip forward-protocol nd
ip http server
ip http authentication local
no ip http secure-server
!
!
ip nat inside source list 1 interface Cellular0 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
!
dialer-list 1 protocol ip permit
no cdp run
!
!
control-plane
!
!
!
line con 0
no modem enable
transport output telnet
line aux 0
login local
transport output telnet
line 2
no activation-character
no exec
transport preferred none
transport input all
stopbits 1
line 3
exec-timeout 0 0
script dialer lte
modem InOut
no exec
transport input all
transport output all
rxspeed 100000000
txspeed 50000000
line vty 0 4
access-class 23 in
privilege level 15
login local
transport input telnet ssh
!
scheduler allocate 20000 1000
!
end
04-27-2013 05:00 PM
Update IOS. If still trouble, contact the TAC.
08-09-2013 01:28 PM
You probably fixed this by now, but if not, you need to either use NAT on the outbound traffic or (if you have a static with your ISP) put an ACL on the cellular interface making sure only packets with you cellular IP make it out.
In your case, it looks like you were headed in that direction, but forgot "ip nat outside/inside" under the respective interfaces.
It turns out most providers will reset your connection if you send packets with a source IP other than that which they have assigned you. See the following snippet:
. If the LTE connection becomes active but then begins to flap (repeats going down and up periodically,
usually every 5 to 60 seconds), a configuration problem must be resolved.
a. This behavior can be caused by a network disconnect due to IP source address violations. It is resolved by
reconfiguring the traffic to be tunneled, NAT, or access control lists (ACLs) so that no traffic is routed
without being tunneled or subjected to NAT. If you cannot determine which IP address is causing the IP
source violation, contact the Verizon Wireless Enterprise Help Desk (800 922-0204) and ask them to trace
the call and report the IP address that is causing the problem. Then correct or add NAT, ACL, or VPN to
stop any packets without the LTE eHWIC IP address from leaking out.
From this document:
http://www.cisco.com/en/US/prod/collateral/modules/ps5949/ps11540/guide_c07-720271.pdf
12-06-2017 11:10 AM
Using NAT is the right way to go. However, it is not enough to solve the problem unless you have full control over the traffic received through the FastEthernet port. One way to mitigate is to use the "ip verify unicast source reachable-via rx"on the FastEthernet port.
But then, the actually deployment may not want the traffic to reach internet at all. Applying NAT may actually allow unauthorized traffic to leak out to the Internet.
Ultimately, I think we need a feature to ensure only the negotiated IP is allowed to go out of the Cellular interface. It is important because router could be generating ICMP Unreachables that violates the source IP restriction.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide