Taking you one step ahead
Using 3G in a cisco router
A very exciting project, that we have been working on for quite some years now, is to provide connectivity to a cisco router using wireless wan technique. Wireless wan is a term used for using wi-fi as a wan service, but more commonly using cellular services as a wan solution. As you can remember (or if you can't, you still can scroll the menu on the left hand side) there has been an article about using 4G services as a backup solution. Let me assure you right away: this is a completely different solution. Not only, because LTE and HSxPA are totally different from one another, but because that 4G solution had been created with an external, linux-based hardware and a 4G USB stick. Not quite professional, I agree. However, as I always say to our clients: let me worry about the tech details, you just tell me what you need and go back to doing what you do best: your business. I'll deliver a solution that will be engineered perfectly to your circumstances, will do exactly what you want, and will cost as much as you can spend on it. Within reason, of course. Today, I'm happy to introduce a 3G as an out-of-band remote access solution. As this article will be long enough without going into details about the out-of-band princibles and technological challenges over 3G, this article will focus on using the 3G card as a WWAN connection. From there, it's only one additional step to configure a remote access vpn client, so the connectivity works both ways.
We'll have to start with a fairly long introduction, as one would have to understand, that altough the router will have a public IP address on its 3G interface, communications will have to be initiated by the router. This public IP address will not be directly reachable over the cellular network. This is a limitation of how GSM systems work. If you're interested, have a look at how the SGSN and the GGSN works. I can assure you, this was one of the hardest parts for me to understand. For the time being, let's just say that for our client we had to set up a vpn client on the router as well, so we could actually make use of the cellular connection for OOB (out-of-band) purposes. This is beyond the scope of this article and is fairly straightforward. In this article I'll show you how to set up and test the 3G connection on the router itself.
Let's start with the hardware basics. Obviously you'll need a physical device to put the SIM card in. This could be a Cisco 881G router, or it could be any modular router that accepts a HWIC. In this article, I'll use a HWIC-3G-HSPA module. This is a normal HWIC, a High-speed Wan Interface Card that is supported in the Cisco 1841 and above. As with everything in the cellular world, you'll have to consider the continent where you intend to use the module - it comes in two main versions, with multiple subversions. The two main versions being GSM and CDMA, as some parts of the world is not using the GSM standard. Probably the most important one being the USA. You'll have to do your homework and find out which version is supported in your country. For this you'll have to look up frequencies used in the country you intend to use this interface.
Once this is done and you'll end up with the matching HWIC, you'll have to make sure the IOS supports the card. Here is an example output when the IOS is not supporting the card - this is taken from a 1841 router running 12.4(25g):
c1841-r2#sh diag
[...]
WIC/HWIC Slot 0:
Unknown WAN daughter card
WIC module not supported/disabled in this slot
As it's clearly stated on Cisco's website, on this platform, you'll need at least IOS 15.0(1)M or later. Other cards may vary, as for example, HWIC-3G-HSPA-A needs 15.1(1)T1 or later, while HWIC-3G-HSPA-HWIC-3G-HSPA-G requires 15.1(1)T or later. Do check out the datasheet. Once you have the correct IOS version, you'll see in the show version output, that cellular interfaces are now available:
c1841-r2#sh ver | i interface 2 FastEthernet interfaces 1 Serial interface 2 Cellular interfaces c1841-r2#
And you can also see that the diag command now reports a fully working card. Or, if you prefer just to look at the physical card, note the blinking green leds at the front.
c1841-r2#sh diag
[...]
WIC/HWIC Slot 0:
3G WWAN HWIC-HSPA/UMTS/EDGE/GPRS-850/900/1800/1900/2100MHz
Hardware Revision : 1.0
Part Number : 73-11671-02
Top Assy. Part Number : 800-30450-02
[...]
Product (FRU) Number : HWIC-3G-HSPA
So that's that - the basics are covered, we have a module that is recognized by the router, hopefully with a SIM card in the slot that has data services subscribed, and it's time to get started. First, let's verify the minimum requirements: that the module is up and running, the SIM card is accepted by the network and there is at least some sort of 2G/3G connectivity. Look at the command output below. You can see that the modem is online, this is a good thing. You can also make note of the IMSI and IMEI numbers for future reference. The IMSI is the unique number assigned to the SIM card that is inserted into the HWIC (which is why I've masqued it out - the actual number is not relevant to understand the concept). Fun fact: the IMSI has two parts: the first part identifies the provider where you have a subscription (or where you got the sim from), and the second part of the number identifies that particular SIM within all the SIMs that came from the same provider. The first part is made up from the country code (MCC - Mobile Country Code) and the network code (MNC - Mobile Network Code). The remaining numbers are the numbers identifying the subscriber. The IMSI is stored within the SIM and is used for authenticating the SIM (and therefore the subscriber) to the network. And while we're at it: it may be useful to know that while the IMSI is used to authenticate the end-user, the IMSI itself is rarely or never transmitted through the network. Another number, the TMSI (Temporary Mobile Subscriber Identity) is submitted instead. This is to prevent tracking of and to provide some sort of confidentiality for the same user, as the TMSI is randomly generated.
c1841-r2#sh cellular 0/0/0 hardware Modem Firmware Version = K1_0_2_18AP C:/WS/FW Modem Firmware built = 12/29/08 Hardware Version = 1.0 International Mobile Subscriber Identity (IMSI) = 2XXXXXXXXXXXXX7 International Mobile Equipment Identity (IMEI) = 0XXXXXXXXXXXXX8 Integrated Circuit Card ID (ICCID) = 8XXXXXXXXXXXXXXX1 Mobile Subscriber International Subscriber IDentity Number (MSISDN) = 4XXXXXXXXXX5 Factory Serial Number (FSN) = CXXXXXXXXXXXXX6 Modem Status = Online Current Modem Temperature = 34 deg C, State = Normal PRI SKU ID = 9992680, SKU Rev. = 1.3 c1841-r2#
What else can we see that is worth mentioning. Oh, the IMEI, which I'm sure you already know - all cellular devices have one and is hopefully unique amongst all radio-enabled devices. It's like the MAC address of an ethernet interface. The abbreviation stands for International Mobile Station Equipment Identity. Another interesting thing is the MSISDN number which is to put simply: the phone number that belongs to the SIM card. It starts with the country code, so you can now surely tell that I'm in Europe :). This is because country codes starting with 3 and 4 are reserved for Europe. After looking at the temperature value (34C) we can move an and check other interesting data from the cellular interface.
c1841-r2#show cellular 0/0/0 network Current Service Status = Normal, Service Error = None Current Service = Combined Packet Service = HSPA (Attached) Packet Session Status = Inactive Current Roaming Status = Home Network Selection Mode = Automatic Country = XXX, Network = XXXXXXXX Mobile Country Code (MCC) = 2XX Mobile Network Code (MNC) = XX Location Area Code (LAC) = XXX Routing Area Code (RAC) = XXX Cell ID = 26325 Primary Scrambling Code = 415 PLMN Selection = Automatic Registered PLMN = 3 , Abbreviated = Service Provider =
This is rather interesting. So as you can see, the modem is working and is accepted by the network. If you have a different output or no output at all, you need to check the SIM in a normal phone. Maybe it's not activated or has expired. Pay attention to the Roaming Status line: you definitely don't want data when roaming, it usually costs a fortune (at least at the time of writing). The country code and network code is also visible in the output, these are human readable formats and will indicate your country name and network provider name respectively. Not really useful, but interesting to see the MCC and MNC codes - you can verify how the IMSI number (seen in the previous step) is made up of these two. The LAC and RAC are again, not relevant for most users, unless you're troubleshooting call routing. Out of pure interest, the base stations (forming cells) are grouped together into locations, the LAC is a code for a specific location. Each mobile device or handset is reporting its LAC to the network on a regular interval, and also stores the last couple LACs on the SIM as a form of a cache. These values are not relevant from our point of view, you just need to make sure that some value is present, as it indicates a connection to the mobile network. And while at it, let's see how good of a connection are we talking about:
c1841-r2#show cellular 0/0/0 radio
Radio power mode = ON
Current Band = WCDMA 2100, Channel Number = 10564
Current RSSI = -105 dBm
Band Selected = Auto
Number of nearby cells = 1
Cell 1
Primary Scrambling Code = 0x19F
RSCP = -106 dBm, ECIO = -10 dBm
The only value that we care about here is the RSSI value, which is the Radio Signal Strength Indicator. There is an RSSI led on the HWIC as well, so you can judge the quality of the network connection just by monitoring the led. If the led is solid amber, that means no connection at all. If the led is off, that indicates a bad connection, which is generally -100 dBm or less. A slow blinking indicates a better connection (-90 to -99 dBm), fast blinking an even better quality (-70 to -89 dBm) and a solid green is the best you can get: a signal with stronger than -69 dBm. This is as good as it gets. There are more attributes to look at, but this is all we need now: making sure that we're good to proceed with the configuration as on the hardware side everything is ready.
The configuration is not simple, but follows cisco-logics. Configure small pieces and then tie these together to one big configuration which will make the whole thing work. These small pieces are the interface configuration (ip addressing, encapsulation), the authentication configuration (credentials etc), defining interesting traffic (probably any at this point), defining a profile (APN, chat script), and finally connecting the dots: putting all the previous pieces together. Let's get to it then.
Let's start with the profile. As our client is based in the United Kingdom, I'll be configuring a profile to a provider in the UK called Three, as this was the choice of the customer. So for the profile, the details need to be obtained from the provider - look for their website for APN information. In this particular case, the profile is configured as profile 1 as below:
c1841-r2#cellular 0/0/0 gsm profile create 1 three.co.uk Profile 1 already exists. Do you want to overwrite? [confirm] Profile 1 will be overwritten with the following values: PDP type = IPv4 APN = three.co.uk Are you sure? [confirm] Profile 1 written to modem c1841-r2#
Three things can be noted from the above. One is that there already was a profile in slot 1. Second is that the profile is saved on the modem, not on the running config. So if you swap a card - make sure to reconfigure the profiles with it! Third: you don't need to be in configuration mode to configure the modem. You just need to be in enable mode. After noting all these, let's verify the profile configuration:
c1841-r2#show cellular 0/0/0 profile 1 Profile 1 = INACTIVE -------- PDP Type = IPv4 Access Point Name (APN) = three.co.uk Authentication = None Username: Password:
All looks OK so far. If my provider required authentication, I would have configured it with the above command, appending pap or chap as the authentication type, followed by the username and password. In my case, there is no authentication. Also, make a note that the above is configured for profile 1. You'll need this number later when configuring the chat script, as it will reference this number (in the ATDT*98*#
interface Cellular0/0/0 ip address negotiated encapsulation ppp dialer in-band dialer idle-timeout 60 dialer string gsm-script dialer-group 1 async mode interactive
As you can see, PPP is used on this interface and the IP address will be given by the provider. The dialer in-band command enables DDR, so the router will actually 'dial in' to establish connectivity when needed. The idle timeout is set to 60 seconds, so the connection will be terminated if nothing is using the interface for a minute. The dialer script 'gsm-script' is yet to be created, and also, the interface is put into dialer group 1, which as no attributes at this point. Let's configure the latter.
access-list 10 permit any dialer-list 1 protocol ip list 10
So dialer-list 1 is created, and is using ACL 10 to define interesting traffic - for which the cellular connection should be brought up. As you can see, any IP traffic will trigger this, this is good for now. Let's create the missing bit: a script called gsm-script which is the string to dial. You'll also have to define this script as the default string to dial, under the line configuration for the relevant cellular interface.
line 0/0/0 script dialer gsm-script
And finally the script itself:
chat-script gsm-script "" "ATDT*98*1#" TIMEOUT 60 "CONNECT"
All of this looks fine, all we need is now actual traffic to go towards this cellular interface - for the purpose of this testing, I'll just create a default route that points to this interface, and shut every other interface down (I'm on the console anyway). So if any traffic is leaving the router, it must be doing so via the GSM network.
ip route 0.0.0.0 0.0.0.0 cellular 0/0/0
All set, time to test with a ping command. We'll expect the first couple of pings to time out, as it takes some time to establish the 3G connection, especially with this RSSI value.
c1841-r2#ping 8.8.8.8 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds: . *Jun 2 21:38:27.387: %LINK-3-UPDOWN: Interface Cellular0/0/0, changed state to up. *Jun 2 21:38:29.403: %LINK-5-CHANGED: Interface Cellular0/0/0, changed state to reset... Success rate is 0 percent (0/5) *Jun 2 21:38:34.403: %LINK-3-UPDOWN: Interface Cellular0/0/0, changed state to down c1841-r2#
Time for the best part: troubleshooting! Now we can see that the RSSI value is low, so the signal strength is weak. But it's there and is suitable for traffic. So let's start with the basics and see if the authentication works? After enabling PPP authentication debugging (debug ppp authe), we can see the following:
*Jun 2 21:38:48.591: %LINK-3-UPDOWN: Interface Cellular0/0/0, changed state to up *Jun 2 21:38:48.595: Ce0/0/0 PPP: Using dialer call direction *Jun 2 21:38:48.595: Ce0/0/0 PPP: Treating connection as a callout *Jun 2 21:38:48.595: Ce0/0/0 PPP: Session handle[4C000007] Session id[7] *Jun 2 21:38:48.611: Ce0/0/0 PPP: No authorization without authentication *Jun 2 21:38:48.611: Ce0/0/0 CHAP: I CHALLENGE id 1 len 35 from "UMTS_CHAP_SRVR" *Jun 2 21:38:48.611: Ce0/0/0 PPP: Sent CHAP SENDAUTH Request *Jun 2 21:38:48.611: Ce0/0/0 PPP: Received SENDAUTH Response FAIL *Jun 2 21:38:48.611: Ce0/0/0 CHAP: Unable to authenticate for peer *Jun 2 21:38:48.611: Ce0/0/0 PPP: Sending AAA radius abort. *Jun 2 21:38:50.615: %LINK-5-CHANGED: Interface Cellular0/0/0, changed state to reset
Clearly it's an authentication problem, the interface is brought up correctly, and is being reset when there is an AAA abort. So the key thing is that despite the fact that there is no authentication, we must set a hostname (username) and a password. The hostname must be the same as the APN name, the password can be anything. So the amended interface configuration looks like:
interface Cellular0/0/0 ip address negotiated encapsulation ppp dialer in-band dialer idle-timeout 60 dialer string gsm-script dialer-group 1 async mode interactive ppp authentication chap callin ppp chap hostname three.co.uk ppp chap password 0 three
Interesting to see how we get assigned a private IP address, use debug ppp negotiation for this:
*Jun 2 22:07:50.859: Ce0/0/0 IPCP: Protocol configured, start CP. state[Initial] *Jun 2 22:07:50.859: Ce0/0/0 IPCP: Event[OPEN] State[Initial to Starting] *Jun 2 22:07:50.859: Ce0/0/0 IPCP: O CONFREQ [Starting] id 1 len 10 *Jun 2 22:07:50.859: Ce0/0/0 IPCP: Address 0.0.0.0 (0x030600000000) [...] *Jun 2 22:07:52.423: Ce0/0/0 IPCP: Address 10.10.147.107 (0x03060A0A936B) *Jun 2 22:07:52.423: Ce0/0/0 IPCP: O CONFREQ [ACKsent] id 3 len 10 *Jun 2 22:07:52.423: Ce0/0/0 IPCP: Address 10.10.147.107 (0x03060A0A936B) *Jun 2 22:07:52.423: Ce0/0/0 IPCP: Event[Receive ConfNak/Rej] State[ACKsent to ACKsent] *Jun 2 22:07:52.427: Ce0/0/0 IPCP: I CONFACK [ACKsent] id 3 len 10 *Jun 2 22:07:52.427: Ce0/0/0 IPCP: Address 10.10.147.107 (0x03060A0A936B)
So looking at the test results, it does seem like a cellular connection, as the RTT (Round Trip Time) values are significantly higher than on a wired connection - this is normal on 3G connections. Also, to check the externally visible IP address, I used telnet to port 80 to a well-known provider who will display my IP address on the resulting webpage. Look at both tests below:
c1841-r2#ping 8.8.8.8 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 540/717/1036 ms c1841-r2#telnet 66.117.47.214 80 Trying 66.117.47.214, 80 ... Open GET /What is my IPv6 Address? [...] 188.29.165.152 [...]
So there we go, an RFC1918 address on the cellular interface, translated to a public one, somewhere in the provider's network, and the connection is now working. Let's take a look at the negotiated attributes / parameters, just for fun:
c1841-r2#sh cellular 0/0/0 connection
Data Transmitted = 16716 bytes, Received = 16716 bytes
Profile 1, Packet Session Status = ACTIVE
IP address = 10.55.190.67
Negotiated QOS Parameters:
Precedence = Normal Priority, Delay = Class 3
Reliability = Unack GTP, LLC, Ack RLC, Protected data
Peak = 256 kB/sec, Mean = 50000 kB/hr
Traffic Class = Interactive
Uplink Max = Subscribed, Guaranteed = Subscribed
Downlink Max = 14.4Mbps, Guaranteed = Subscribed
Max SDU size = 1500 bytes
SDU error ratio = 1E-4, BER = 1E-5
As you can see, this commands shows the IP address received, the QoS parameters, and the negotiated maximum speed - this is 14.4 Mbps from above, which happens to be the maximum of what HSPA can deliver. From here, you're good to start establishing VPN conenctions, or anything similar to have bidirectional connectivity and be able to use the 3G interface for OOB management. Enjoy!
- Log in to post comments