Configuring Basic 4G LTE Connectivity on the Cisco 819 Router

I've recently had the mixed fortune to have set up a couple of Cisco routers for 3G and 4G data services. It turns out to be surprisingly simple, although I found myself having to flit around between a handful of different documents to work out how to get it working. Luckily I was sat next to someone who previously worked in one of the UK's biggest mobile carriers while I was working on it, which saved me a bit of head scratching at times.

As a little bonus I had two different devices to work on - the first being an old Cisco 1841 router with a 3G WIC installed, the second being a Cisco 819 (4G LTE model). As it turns out the concepts are pretty similar but the syntax is moderately different between the two platforms, so in time I'll write up the process for each. This post and its accompanying video will explain the 4G version.

Building Blocks

While there are a few mobile-specific pieces of configuration, anyone who has previously worked on ISDN, async modems or ADSL on Cisco routers will probably find a lot of familiar concepts. Here are the main elements of a 3G / 4G configuration:

Cellular Profile 

This is where the APN address and authentication mode are configured. These are saved to the modem's NVRAM as soon as they are applied. Here's an example of how to set a cellular profile on the two different platforms:

Router#cell 0 lte profile create 1 three.co.uk none

PDP Type = IPv4
Access Point Name (APN) =
Username =
Password =
Authentication = NONE

Profile 1 already exists with above parameters. Do you want to overwrite? [confirm]

Profile 1 will be overwritten with the following values:

PDP type = IPv4
APN = three.co.uk
Username =
Password =
Authentication = NONE

Are you sure? [confirm]
Profile 1 written to modem
Router#

Note that this example is for three, a UK mobile carrier which is interesting because the APN uses no authentication (and barfs if you try to authenticate with it). I found during my testing that an 819 router running IOS 15.2 does not have the option to use authentication type "none". Under 15.3 the option is there and works fine - luckily I had another 819 with 15.3 installed which worked and so a) I knew that's what the problem was and b) I could copy the image across!

Also note that this is applied at the exec prompt rather than in config mode.

Most carriers use CHAP authentication, these just require the authentication type and credentials added to the command, for example:

cell 0 lte profile create 1 everywhere chap eesecure secure

The number "1" here indicates which slot on the modem will be used to store the profile. This is significant later on because there may be multiple APNs configured and the router needs to know which to use when connecting.

Cellular Interface

The physical radio interfaces are referred to using the "Cellular" prefix, in this case Cellular0. The Cellular interface is where the dialer, authentication and IP details are normally configured - I say normally as there are many different ways to configure dialers depending on what kind of load balancing and resilience are required. For a typical 3G / 4G deployment, though, you will only have one physical interface and so the simplest way is to forget about pools and put the config straight onto that.

Here is an example configuration showing the key elements:

interface Cellular0
 ip address negotiated
 encapsulation slip
 dialer in-band
 dialer-group 1
!
dialer-list 1 protocol ip permit

ip route 0.0.0.0 0.0.0.0 Cell0


The key thing to notice here is that unlike the old 3G config there is no "*98*1#" type diaper string. If you want to use alternative profiles you have to mess around with config under the "controller cellular 0" context.

The rest is fairly standard dialer stuff, in this example I've made the dialer-list so that any IP traffic will cause it to connect.

Note that the encapsulation specified on this 4G interface is SLIP. When 4G is not available it will fall back to 3G (which uses PPP encapsulation) - it does this transparently and does not need the encap changed.

Sundry Config

At this point the router should be able to connect to the cellular network. For most purposes, though, you will need to either set up NAT or some sort of VPN tunnel for the connection to be of any use. These are set up the same way as for any other setup.

Testing and Diagnostics

How can you tell whether the cellular connection is coming up? The first clue is that log entries similar to the following should appear:

%LINK-3-UPDOWN: Interface Cellular0, changed state to up

If the above log entries don't appear it could be because the modem is not ready yet. The modems in the 819 routers I was playing with took an incredibly long time to boot. The following logs indicate that the modem has (finally) booted up:

%CISCO800-2-MODEM_UP: Cellular0 modem is now UP.
%CISCO800-6-SIM_STATUS: SIM in slot 0 is present

However at this point the modem will still need to attach to the cellular network, which can take a little time. To check whether the modem is attached to the radio network, use the following commands:

Router#show cell 0 radio
Radio power mode = ON
Channel Number = 1667
Current Band = LTE
Current RSSI = -60 dBm
Current RSRP = -84  dBm
Current RSRQ = -4  dB
Current SNR = 10.6  dB
LTE Technology Preference = AUTO
LTE Technology Selected = LTE

Router#show cell 0 network
Current System Time = Sun Jan 6 0:1:30 1980
Current Service Status = Normal
Current Service = Packet switched
Current Roaming Status = Home
Network Selection Mode = Automatic
Network = 3
Mobile Country Code (MCC) = 234
Mobile Network Code (MNC) = 20
Packet switch domain(PS) state = Attached
Registration state(EMM) = Registered
Location Area Code (LAC) = 107
Cell ID = 9150878
Primary Scrambling Code = 65535

Note that the band and channel need to be populated, the network should display the expected carrier name and the packet service should show as attached. The actual band and service type will vary depending on carrier, coverage, area and equipment used.

If the radio interface is up but a data connection cannot be established then all the usual debugs may be used:

debug dialer (to verify it is trying to dial)
debug chat (sometimes useful to deduce whether APN is configured correctly)
debug cellular 0 messages callcontrol (shows the cellular network assigning the IP and DNS)

Note on Earlier Releases

Prior to IOS 15.3 you had to define your own chat string and apply it to the line - later releases do this automatically. If your "debug chat" output shows anything about "ATDT" or expecting "CONNECT" then this probably applies to you. Making and applying the chat script is pretty simple:

chat-script lte "" "AT!CALL" TIMEOUT 20 "OK"

line 3

 script dialer lte

!

Basically this says to define a script called "lte" which waits for nothing, sends "AT!CALL" to the modem and expects to get "OK" in return within 20 seconds. Then that script gets attached to line 3, which in the 819 router is the 4G cellular modem.

References

Cisco 4G configuration guide
YouTube clip accompanying this post

How to Get the Chassis Serial Number in IOS-XR

This caught me out the other day and I had to find the answer deep within a Cisco document. To hopefully save someone else having to wade through all that, the commands to find out chassis serial numbers on the ASR9k are as follows:

RP/0/RSP0/CPU0:nodename#admin
Thu Sep 25 14:15:16.645 BST
RP/0/RSP0/CPU0:nodename(admin)#show dsc
Thu Sep 25 14:15:27.080 BST
---------------------------------------------------------
           Node  (     Seq)     Role       Serial State
---------------------------------------------------------
    0/RSP0/CPU0  (       0)   ACTIVE  ABC2345X678 PRIMARY-DSC
RP/0/RSP0/CPU0:nodename(admin)#

Err.... simple?

Crippling CPU Load on Back to Back ASAs

I was recently involved in troubleshooting a problem where an ASA firewall's CPU was hitting 100%. One of its interfaces was seeing much higher traffic levels than the others, so we did some fairly run-of-the-mill troubleshooting including a packet capture. What this showed was the same, seemingly innocuous, packet repeated thousands upon thousands of times.

The payload was identical, in fact everything from the IP layer and up remained identical from one frame to the next. The only thing that varied was that the source and destination MAC addresses were swapped each time - clearly the packet was ping-ponging between two devices.

We checked the MACs and found they were legitimate - one was the local firewall, while the other was its default gateway - another ASA upstream towards the Internet.

This got our attention. First of all there was a routing loop, which is bad enough, but a packet should never be able to loop forever like that. That's why we have Time To Live (TTL) after all - the number which decrements by one each time a packet goes through a routed hop with the packet being thrown away when its value reaches zero. The key thing here is that the packet, including its TTL, was not changing at all so it never got removed from the system.

The cause of the routing loop was relatively easily found by looking at the source and destination IPs on the packet. The setup was as follows:

What had happened here was that a RAS user had connected to the tenant firewall using their IPSec client and started talking to some devices on the server LAN:

At some point the IPSec session had ended while an internal device was still sending traffic towards the user. This creates an interesting corner case:

The routing is "correct" here - the multi-tenant firewall needs to route the RAS subnet via the tenant firewall so that RAS users can connect to shared resources. The tenant firewall needs to route the traffic outwards for it to hit the right crypto maps. The problem comes when a packet is destined for an IP in the RAS pool which is not associated with a live VPN session.

Our bodge to get us out of the immediate hole was to put a deny entry inbound on the mutli-tenant firewall for anything targeted at a RAS pool address. These packets should never make it onto the transit LAN as any legitimate traffic to that range would need to be tunneled via IPSec and therefore the multi-tenant firewall would see a public IP as the destination. After a lot of thinking we couldn't come up with a better answer than this and decided just to stop calling it a bodge.

OK, so first problem solved. Next question, why was the packet looping forever without ever reducing its TTL?

Root Cause

As it turns out this is by design on the ASA (and the good old fashioned PIX & FWSM before it). The idea is that if the firewall behaved like any other routed hop and decremented the TTL then it would be visible in traceroutes. To be fair if it did decrement TTL it would just appear as a black hole in the trace as the ASA doesn't really "do" unreachables unless you force its hand. This normally doesn't cause any problems, even if there is a routing loop. Take a typical deployment where an ASA is attached to a router as shown below:

If we get a loop between the ASA and a traditional router then the packet will eventually be taken out of the loop. Even though the ASA doesn't decrement the TTL, the router does so it eventually gets dropped - half as fast as normal and always by the router (which will punt the packet to the CPU and usually generate an ICMP TTL expired, which can be pretty CPU intensive on small devices), but it does get dropped eventually.

The problem comes when we have a pair of non-decrementing devices (ASAs) back to back at layer 2. Both devices route the packet but neither device decrements the TTL, so if there is a loop between the two it the packet will go around and around forever. Eugh...

The moral of the story is that it's probably best not to put ASAs back to back. I could have sworn I'd seen this setup in Cisco whitepapers before but, now that I look, I can't find it anywhere. The closest I can find is IOS firewall back to back with ASA or two ASAs with a server between. Perhaps there's a good reason for that :)

As with my situation, though, in most cases by the time you get to realise there is a problem the hardware has long since been bought, installed and is carrying live service. So what can you do?

Well, as noted above you can use ACLs to block potential loop traffic but in all honesty that just fixes by exception. You could be fairly liberal with what you block (e.g. drop all RFC 1918 addresses where you would expect to only see public IPs) but it's still imperfect.

Making the ASA decrement TTL

A better idea would be to have at least one of the ASAs decrement TTL. It's a bit uncomfortable to retro-fit but there is a way built in to ASA versions 8.0(3) and above using "set connection decrement-ttl" under a policy map. There are two different ways to do it, one is to adjust the "global_policy" policy map which applies to the entire device by default, or you can create a new policy map to apply to a single interface.

Here's how to apply it to the entire device:

policy-map global_policy
 class class-default
  set connection decrement-ttl
!

The effect is immediate as the global_policy is applied to all traffic by default. Alternatively, if you only want to apply it to specific interfaces, you can create a separate policy map and apply it as follows:

policy-map asa_workaround
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp
  inspect icmp
 class class-default
  set connection decrement-ttl
!
service-policy asa_workaround interface interface-name

The above is modeled on the standard default policy & inspections, if you've changed yours from default you probably don't need to be reading this!

Summary

So there you have it - ASAs back to back is a bit dangerous unless you take measures to protect against routing loops. This can be in the form of strict ACLs or by enabling TTL decrement, either globally or on specific interfaces.

References

Cisco guide to enabling traceroute through ASA

Cisco guide to modular policy framework on ASA