cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4573
Views
5
Helpful
3
Replies

Cisco 819 Cellular Interface Drops when FastEthernet comes Up

Kristen Sanders
Level 1
Level 1

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

3 Replies 3

paolo bevilacqua
Hall of Fame
Hall of Fame

Update IOS. If still trouble, contact the TAC.

dmurray14
Level 1
Level 1

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

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. 

 

 

Review Cisco Networking products for a $25 gift card