Basic Internet Connectivity Setup Using HWIC-3G-GSM Card

In addition to working on some spanking new 4G Cisco 819 devices, I've occasionally had to slum it by providing Internet access with a normal 1800 / 2800 series router and an HWIC-3G-GSM card. Once you know what's involved the config is remarkably simple but it can be difficult to understand what's what at first.

The video below takes a very quick walk through setting this up, some further explanation is given beneath that for those interested.

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/0/0 gsm profile create 1 three.co.uk
Profile 1 will be created with the following values:                            
PDP type = IPv4                                                                 
APN = three.co.uk                                                               
Are you sure? [confirm]                                                         

Profile 1 written to modem                                                      

Router#

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

This example is for three, a UK mobile carrier which is interesting because the APN uses no authentication. If your APN requires authentication, simply follow the APN with either a pap or chap keyword, the username and finally the password.

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

Cellular Interface

The physical radio interfaces are referred to using the "Cellular" prefix, in this case Cellular0/0/0. 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 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/0/0
 ip address negotiated
 encapsulation ppp
 dialer in-band
 dialer string "*98*1#"
 dialer-group 1
 ppp chap refuse
!
dialer-list 1 protocol ip permit

ip route 0.0.0.0 0.0.0.0 Cell0/0/0

The key thing to notice here is the "*98*1#" dialer string. The "*98*" and "#" are fixed, the "1" refers to the profile slot number used earlier. If you used a different slot, refer to it here.

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.

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/0/0, changed state to 
up

To check whether the modem is attached to the radio network, use the following commands:

Router#show cell 0/0/0 network                                                  
Current Service Status = Normal, Service Error = None                           
Current Service = Combined                                                      
Packet Service = HSDPA (Attached)                                               
Packet Session Status = Active                                                  
Current Roaming Status = Home                                                   
Network Selection Mode = Automatic                                              
Country = GBR, Network = 3 UK                                                   
Mobile Country Code (MCC) = 234                                                 
Mobile Network Code (MNC) = 20                                                  
Location Area Code (LAC) = 24                                                   
Routing Area Code (RAC) = 24                                                    
Cell ID = 14827                                                                 
Primary Scrambling Code = 81                                                    
PLMN Selection = Automatic                                                      
Registered PLMN = 3 , Abbreviated =                                             
Service Provider =                                                              
Router#show cell 0/0/0 radio                                                    
Radio power mode = ON                                                           
Current Band = WCDMA 2100, Channel Number = 10564                               
Current RSSI = -76 dBm                                                          
Band Selected = Auto                                                            
Number of nearby cells = 1                                                      
Cell 1

        Primary Scrambling Code = 0x51
        RSCP = -77 dBm, ECIO = -0 dBm           
                                                                                
Router#

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 network status remains in "Emergency Only" and you get no MSISDN showing in your show cell 0/0/0 hardware command, particularly if it is accompanied by messages saying "%CELLWAN-2-SIM_LOCKED: [Cellular0/0/0]: SIM is locked", then you have probably locked the SIM (i.e. by setting up a startup PIN on a phone handset) and will need to unlock it as follows:

Router #cell 0/1/0 gsm sim unlock 1234
!!!WARNING: SIM will be unlocked with pin=1234(4).
Do not enter new PIN to unlock SIM. Enter PIN that the SIM is configured with.
Call will be disconnected!!!
Are you sure you want to proceed?[confirm]

*Dec  7 22:15:38.035: %LINK-3-UPDOWN: Interface Cellular0/0/0, changed state to up
Router#

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 ppp negotiation (shows the PPP negotiation process from agreeing basic link properties and authentication type, through the authenticating stage and up to IP being allocated)

A full deep-dive into these debugs wouldn't really be appropriate for this post, in any case it's usually fairly evident where the problem lies. UPDATE: The promised dialer / PPP debugging guide is available here - it's written for PPPoE but the vast majority of it is applicable to cellular interfaces as well.

References

Video accompanying this blog post

A Better Way to Compare 7750 Configs

One of the tasks I regularly have to perform as part of my job is to audit router configurations against basebuild templates and occasionally against each other. This can be quite labour-intensive, particularly as good, old-fashioned diff doesn't cope very well with hierarchical configs such as the 7750's. There are many things that make life difficult with traditional diff:

1. Diff is more-or-less reliant on order being preserved between the files being compared. Some config elements are split across the config file when it is saved. Others may be stored in different locations depending on the software release. Certain items such as layer 3 interfaces are stored in the order that they were added, so two configs may contain the same interfaces but in a different order and traditional diff can't generally work that out.
2. Traditional diff does not appreciate the significance of policy names, sequence numbers or service IDs in determining what should be compared to what. Ad-hoc insertions and deletions of policy entries or service often causes diff to get completely out of step, making it compare apples to oranges.
3. Traditional diff does not provide context for differences. Quite often you just get a load of "shutdown" "no shutdown" pairs. It is possible to include a fixed number of lines pre- or post- difference, but even that does not always show the configuration context where the difference actually occurred and brings a load of junk with it. The only sure-fire way is to turn on side by side diff, which shows both configurations in full side by side with changes marked in a centre column.

Point 2 is the real killer, making traditional diff basically useless for audits where a handful of known policies must be validated within a config containing many other policies. Below is a (fairly common) worst case when working with diff - one policy has been removed and another two added:

Traditional diff makes a horrible job of this. Even seeing the two configs side by side it is confusing to look at and it is not immediately apparent what has changed.

I poked and played with a number of "diff" type tools to try and find something that would handle this kind of thing more gracefully but I eventually came to the conclusion that nothing currently existed. I had a rough idea of what I wanted:

•  It must only compare the contents of like policies, i.e. policy "A" should only be compared to policy "A" and never to policy "B".
• It must compare configuration elements that appear in a different order in one config to the other.
• It should, ideally, report the full context of each difference within the hierarchy.

To address these points I decided to write a tool from scratch and called it, unimaginatively, 7750diff. Here's how 7750diff reports the same changes:

D:\7750diff>7750diff a.cfg b.cfg
Unique to a.cfg:
configure
    qos
        scheduler-policy "20000kbps" create
            description "20000kbps Scheduler"
            tier 1
                scheduler "tier1" create
                    rate 20000 cir 20000
                exit
            exit
        exit
    exit
exit
Unique to b.cfg:
configure
    qos
        scheduler-policy "25000kbps" create
            description "25000kbps Scheduler"
            tier 1
                scheduler "tier1" create
                    rate 25000 cir 25000
                exit
            exit
        exit
        scheduler-policy "40000kbps" create
            description "40000kbps Scheduler"
            tier 1
                scheduler "tier1" create
                    rate 40000 cir 40000
                exit
            exit
        exit
    exit
exit

D:\7750diff>

That's not only much clearer (IMHO), but I can take the output and copy / paste it directly into the node to build the missing configuration. Happy days!

How it Works

The basic methodology used by 7750diff is to:

• Read each config into a hierarchical tree structure based on indent levels
• Recursively compare the trees starting at the root:
• For each branch of config A, search for an identical branch on config B within the same context.
• If a match is found, check for subordinate "child" configuration elements.
• If any children exist, recursively process them.
• If no children are then present, remove the matching elements.

Once all elements have been compared only the elements unique to each config will remain, along with the parent elements required to reach the configuration context of the change. The trees can then be output as a list of differences between the two files. In many cases, thanks to the inclusion of context, big chunks of 7750diff output can be directly entered into one node to bring its config into line with the other.

Since the whole thing runs on indents it is not 7750 specific. It "may" work on ISAM configs, it may work on any other sort of config that uses indent / whitespace to denote hierarchy - I just haven't tested it. Try your luck :)

Obtaining the Tool

As usual, the tool is available for download at my github: https://github.com/theclam/7750diff - there is the C source code plus a Windows binary available to download.

The code is pretty horrible as this was my first bit of C coding in over a decade. I may decide to clean the code up at some point but it is quite stable now, meaning I haven't found a config that upsets it for the last couple of versions. I've been running a nightly cron job for quite some time now which pulls down an entire lab's configs and 7750diffs each one against the previous day's and it works great.

If you download 7750diff, please let me know how you get along with it.