cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4337
Views
27
Helpful
46
Replies

8200 router cellular interface shutting down

KMNRuser
Level 1
Level 1

We have one of our remote sites connecting back to us using a Cisco C8200L-1N-4T.

 

This router is in a remote location, and the only service we could find out there was cellular.

We have the Cellular interface connected; using "ip address negotiated".

We have 4 Tunnels configured on the box, and 3 of those tunnels pass traffic, but the 4th one, when it tries to pass traffic, will shut down the cellular interface for a period of a few seconds, which takes down the other 3 tunnels, and then once the cellular interface comes back up, connectivity is restored.

Has anyone ever witnessed this behavior before?  What could cause something within the configuration of the one tunnel to shut down the interface when a ping is sent across it?

 

Thanks for any input!

KMNRUser

46 Replies 46

balaji.bandi
Hall of Fame
Hall of Fame
will shut down the cellular interface for a period of a few seconds, which takes down the other 3 tunnels

not sure this was the case how other will shutdown - we need to look at the logs.

You can use EEM script to shutdown the tunnel and test it.

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Leo Laohoo
Hall of Fame
Hall of Fame

Post the complete output to the following commands: 

sh cellular <PORT> firmware
sh cellular <PORT> hardware

Leo,

Thanks for your response!

Here are the outputs of the two respective commands:

Remote_RTR# show cellular 0/2/0 firmware 
Idx Carrier      FwVersion        PriVersion   Status  
1   Generic      32.00.114        1023         Inactive
2   Verizon      32.00.124        2020         Active  
3   ATT          32.00.143        4021         Inactive

 

Firmware Activation mode  =  AUTO

Remote_RTR# show cellular 0/2/0 hardware 
Modem Firmware Version = 32.00.124
Host Firmware Version = 32.00.004_2
Device Model ID =  LM960A18
International Mobile Subscriber Identity (IMSI) = xxxx
International Mobile Equipment Identity (IMEI) = xxxx
Integrated Circuit Card ID (ICCID) = xxxx
Mobile Subscriber Integrated Services
Digital Network-Number (MSISDN) = xxxx
Modem Status = Modem Online
Current Modem Temperature = 30 deg C
PRI version = 2020, Carrier = Verizon
OEM PRI version = 32101006

can you check the CPU
MHM

MHM Cisco World,

Here is the output for show proc cpu

Remote_RTR#sho proc cpu
CPU utilization for five seconds: 1%/0%; one minute: 1%; five minutes: 1%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 3 39 76 0.00% 0.00% 0.00% 0 Chunk Manager
2 657997 1448652 454 0.00% 0.00% 0.00% 0 Load Meter
3 1733 2297 754 0.00% 0.00% 0.00% 866 SSH Process
4 0 1 0 0.00% 0.00% 0.00% 0 Retransmission o
5 0 1 0 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
6 325 17 19117 0.00% 0.00% 0.00% 0 RF Slave Main Th
7 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
8 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers
9 4388764 1103497 3977 0.00% 0.03% 0.04% 0 Check heaps
10 20287 120722 168 0.00% 0.00% 0.00% 0 Pool Manager
11 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
12 0 2 0 0.00% 0.00% 0.00% 0 Timers
13 81 9237 8 0.00% 0.00% 0.00% 0 WATCH_AFS
14 0 1 0 0.00% 0.00% 0.00% 0 MEMLEAK PROCESS
15 591 2881 205 0.00% 0.00% 0.00% 0 ARP Input
16 136027 7552717 18 0.00% 0.00% 0.00% 0 ARP Background
17 0 2 0 0.00% 0.00% 0.00% 0 ATM Idle Timer
18 0 1 0 0.00% 0.00% 0.00% 0 ATM ASYNC PROC
19 0 1 0 0.00% 0.00% 0.00% 0 CEF MIB API
20 14 1 14000 0.00% 0.00% 0.00% 0 AAA_SERVER_DEADT
21 0 1 0 0.00% 0.00% 0.00% 0 Policy Manager
22 2114 125850 16 0.00% 0.00% 0.00% 0 DDR Timers
23 156 27 5777 0.00% 0.00% 0.00% 0 Entity MIB API
24 467 121 3859 0.00% 0.00% 0.00% 0 PrstVbl
25 13 2 6500 0.00% 0.00% 0.00% 0 Serial Backgroun
26 0 1 0 0.00% 0.00% 0.00% 0 RMI RM Notify Wa
27 0 2 0 0.00% 0.00% 0.00% 0 ATM AutoVC Perio
28 0 2 0 0.00% 0.00% 0.00% 0 ATM VC Auto Crea
29 65763 3621275 18 0.00% 0.00% 0.00% 0 IOSXE heartbeat
30 121 12074 10 0.00% 0.00% 0.00% 0 Btrace time base
31 297 8052 36 0.00% 0.00% 0.00% 0 DB Lock Manager
32 111985 7243252 15 0.00% 0.00% 0.00% 0 GraphIt
33 0 1 0 0.00% 0.00% 0.00% 0 DB Notification
34 0 1 0 0.00% 0.00% 0.00% 0 IPC Apps Task
35 0 1 0 0.00% 0.00% 0.00% 0 ifIndex Receive
36 11301 1448123 7 0.00% 0.00% 0.00% 0 IPC Event Notifi
37 98825 7072683 13 0.00% 0.00% 0.00% 0 IPC Mcast Pendin
38 0 1 0 0.00% 0.00% 0.00% 0 Platform appsess

 


@KMNRuser wrote:
2   Verizon      32.00.124        2020         Active  

Ok, let's do something basic.  

Upgrade the firmware of the modem.  

The updated file can be found HERE and instructions to upgrade the firmware can be found HERE.

My recommendation is to raise a TAC Case in case the instruction(s) or the firmware is faulty.

KMNRuser
Level 1
Level 1

Thanks to all the Community members whom have responded to this post!  We are not thinking at this point that the cellular interface itself is what is dropping, but rather there is a crypto map attached to the Cellular interface that when manipulated ( we tried to add another cry instance within the crypto map for a new tunnel) seems to drop our connectivity.  

I am not sure whether the appropriate action at this point would be to A) Start a new post about crypto maps, or B) continue dialogue in this post..

What is the appropriate answer here?

Thank you!

KMNRUser

no problem you extend the topic here,

So can you post the configuration what you looking to here ?

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Balaji,

This is the configuration on the cellular interface of the 1100.  As you can see, there is an existing crypto map already on the interface.  It is that crypto map that allows us to have remote connectivity to the router thru other tunnels which connect back to our HQ location and our DR location respectively:

interface Cellular0/2/0
description ***** VzW EVDO Interface *****
ip address negotiated
ip tcp adjust-mss 1388
dialer in-band
dialer idle-timeout 60
dialer watch-group 1
dialer-group 1
ipv6 enable
pulse-time 1
crypto map ICCP_BACKUP
ip virtual-reassembly

 

Here is the existing crypto map entitled "ICCP_BACKUP".  I am changing the IP's as those are public.  You can see there are 4 sequences of the crypto map:

crypto map ICCP_BACKUP 50 ipsec-isakmp
set peer 123.123.123.206
set transform-set ODEC_WAN
match address 100
crypto map ICCP_BACKUP 70 ipsec-isakmp
set peer 134.134.134.218
set transform-set ODEC_WAN
match address 100
crypto map ICCP_BACKUP 80 ipsec-isakmp
set peer 135.135.135.14
set transform-set ODEC_WAN
match address 110
crypto map ICCP_BACKUP 90 ipsec-isakmp
set peer 136.136.136.26
set transform-set ODEC_WAN
match address 120
!

What we have attempted to do without success is add the following sequence # to it without lifting the crypto map off of the interface:

We add the transform set we want to use:

crypto ipsec transform-set BCCSCADA esp-aes esp-sha-hmac

 mode transport

then we set another sequence # (which we are using sequence # 95) within the crypto map entitled "ICCP_BACKUP" as follows:

crypto map ICCP_BACKUP 95 ipsec-isakmp
set peer 137.137.137.26
set transform-set BCCSCADA
match address GREINIPSEC

It is when we apply the additional sequence number 95 that we loose connectivity to the router.

My thoughts are that we are not able to manipulate a crypto map that is attached to an interface.  That is what my memory is telling me from years ago.  Is this accurate?  Is that the reason that when we add the additional sequence number but have not removed it from the interface, that it breaks it?    Thanks as always!

 

KMNRUser

I am not authoritative about these issues, but I would be quite surprised if the issue were really about attempting to manipulate the crypto map without removing it from the interface. My suggestion is that there is something about the new entry in the crypto map that is causing the issue. And I am wondering about the possibility that in adding the additional tunnel you are attempting to send something with a source address that your cellular provider does not recognize. To investigate this would you provide the configuration of the new tunnel interface and of acl GREINIPSEC, and as a point of comparison also post the configuration of one of the working tunnels and its associated acl?

HTH

Rick

Hi Rick,

Thank you for your response.

Here is the new Tunnel interface configuration as it currently exists on the 1100:

interface Tunnel5
ip address 10.101.5.8 255.255.255.0
tunnel source Cellular0/1/0
tunnel destination 123.123.223.46

Thank you!
KMNRuser

ACL entitled GREINIPSEC

ip access-list extended GREINIPSEC
10 permit gre any any
!

 

KMNRUser

Thanks for the additional information. As I asked previously would you also provide the configuration details of one of the tunnels that does work (showing its crypto map entry, its tunnel interface, its acl).

HTH

Rick

Hi Rick,

Apologies for not including that as requested originally..here is the configuration of the other tunnels on the 1100 box which are working.  They appear to be more like DMVPN tunnels.

We have hubs set up at our HQ and our DR sites for these DMVPN type tunnels.  This box is a spoke.  We were originally going to use that type of tunnel here, but i asked a colleague whether or not the spokes needed to communicate with each other, and he indicated that they did not, so that is why I was building out an IPSEC-ISAKMP tunnel.

interface Tunnel1
ip address 10.101.2.8 255.255.255.0
ip mtu 1400
ip nhrp authentication cisco
ip nhrp map 10.101.2.1 10.101.1.1
ip nhrp network-id 100000
ip nhrp holdtime 360
ip nhrp nhs 10.101.2.1
ip tcp adjust-mss 1360
delay 1000
tunnel source Cellular0/2/0
tunnel destination 10.101.1.1
tunnel key 100000

KMNRUser

Thanks for the additional information. From what you have posted it looks like the other tunnels are using cell0/2/0 and the new tunnel is using cell0/1/0. Is that really the case?

In looking at what you have posted it looks like the existing tunnels (that do work) are using private addressing for source and destination (which is appropriate for DMVPN) while it looks like the new tunnel is using Public IP addressing for the peers. Is that the case? If so I am guessing this is the cause of your issue.

HTH

Rick

Review Cisco Networking for a $25 gift card