ISR1K VZ LTE connection

paul amaral · ‎07-17-2019

cisco C1111-4PLTEEA

System image file is "bootflash:c1100-universalk9_ias.16.08.01.SPA.bin"

Recently for the first time I configured a cisco 1111 router with built in dual sim LTE. When I first turn on the router, I skipped the initial script, when the router was fully booted I notice that the LTE connection to VZ was up as well. Verified with sh cellular 0/2/0 connection. I then added a default route to cell0/2/0 and I was online. I know that the sim was on auto sim and the, firmware as set to VZ etc and the APN was already setup by default but how is this possible with no DDR config.

Initial config looks like this

!

interface Cellular0/2/0

ip address negotiated

ipv6 enable

end

Basically, the router came preconfigured to work with VZ LTE and when I turned it on it got connected to VZ with an ip. This is where I’m not understanding how this was possible, looking at the cellulat0/2/0 interface there was no DDR configured. Also, if I turn off the cellular0/2/0 interface after the initial boot it never comes back up again without proper configuration. This is what I would expect to see once the router boots for the first time, instead the cellular interface shows connected with an ip, how is this possible without configuration?

Lastly, I notice while testing that if I turn the cellular interface up/down frequently that at some point it takes a long time for the connection to come back up. Is this something on the carrier end that throttles flapping an penalizes it?

Below is the config I ended up using that working for me on this device.

access-list 1 permit 166.252.xx.xx

access-list 1 permit any

dialer watch-list 1 delay connect 1 ! usually for another DDR backup interface

dialer-list 1 protocol ip permit

controller Cellular 0/2/0

lte sim data-profile 3 attach-profile 3 slot 0 ! choose correct profile might be chosen already by default

interface Cellular0/2/0

ip address negotiated ! default hdlc negotiated

load-interval 30

dialer in-band

dialer watch-group 1 ! keeps interface up and will not go down due to idle you can also set ! dialer idle-timeout 0 in int mode

dialer-group 1

ipv6 enable

pulse-time 1 ! needed in order to wait to reconnect!!

ip route 0.0.0.0 0.0.0.0 Cellular0/2/0 254

TIA, Paul

paul amaral · ‎07-18-2019

I believe cisco embedded plug and play feature (PNP) is responsible for initially bring up the connection. When there is no config present in NV ram PNP kicks in through DHCP. It looks like VZ has PNP capabilities and caused the initial config to obtain an ip from VZ and get connected. When write the config, PNP doesnt no come into play and no ip is obtained.

*Jul 18 14:27:18.643: %PNP-6-HTTP_CONNECTING: PnP Discovery trying to connect to PnP server http://52.205.197.159/pnp/HELLO

*Jul 18 14:27:18.764: %PNP-6-HTTP_CONNECTED: PnP Discovery connected to PnP server http://52.205.197.159/pnp/HELLO

The correct config for VZ LTE is the following,

interface Cellular0/2/0
ip address negotiated
ip nat outside
dialer in-band
dialer idle-timeout 0
dialer watch-group 1
pulse-time 1

!

dialer watch-list 1 ip 5.6.7.8 0.0.0.0
dialer watch-list 1 delay route-check initial 60
dialer watch-list 1 delay connect 1

!

note you dont need watch-group on the cell interface, the watch-list watches for ip 5.6.7.8 0.0.0.0 every 60 seconds and as long as that route is not in the ip routing table it will keep the dialer/cell interface up.

An important note on VZ LTE, if you have multiple WAN connection on your router and VZ sees packets sourced from you router with a non VZ ip it will drop the connection. You need to either nat everything to the VZ ip or make sure nothing is going out to VZ that doesnt have a VZ sourced ip addr.

#sh cellular 0/2/0 connection call-history
Start Time Stop Time Duration
Mon Jul 29 11:38:17 2019 Mon Jul 29 11:43:15 2019 298 seconds

Call disconnect reason

Call end mode =
Session disconnect reason type = (0)
Session disconnect reason = (0)

Mon Jul 29 11:43:47 2019 Mon Jul 29 11:48:45 2019 298 seconds

Call disconnect reason

Call end mode = 3GPP
Session disconnect reason type = 3GPP specification defined(6)
Session disconnect reason = Regular deactivation(36)

Mon Jul 29 11:49:17 2019 Mon Jul 29 11:54:15 2019 298 seconds

Call disconnect reason

Paul