Adjusting timestamps in PCAP files

Many times in the past I've had to look at a pair of pcap files side by side in order to troubleshoot an issue. More often than not, one of the PCAP files was produced on a ropey old laptop whose clock is "almost right" - the timestamps between the two files then don't tie up and it is a pain to keep working out "if it's time X in that file, I need to look at time Y in this file..."

This week I overheard a colleague in the office having exactly that problem and thought it wouldn't be too hard to build a utility to time shift pcap files by a specified amount. So here it is:

https://github.com/theclam/capshift

Installation

As explained in the readme, it should be possible to compile on any system with gcc using only the standard libraries. Just download the capshift.c and capshift.h files and compile (gcc -o capshift capshift.c), or download a binary if one exists for your system.

Usage

Capshift takes three arguments, all mandatory:

• The input pcap file, specified using -r
• The output pcap file, specified using -w
• The time offset value (positive or negative), specified using -o

Here's an example:

Harrys-MacBook-Air:capshift foeh$ tshark -ta -r before.cap
  1 15:30:45.978539 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4748/35858, ttl=128
  2 15:30:45.979407 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4748/35858, ttl=255
  3 15:30:46.979315 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4749/36114, ttl=128
  4 15:30:46.980274 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4749/36114, ttl=255
  5 15:30:47.980323 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4750/36370, ttl=128
  6 15:30:47.981215 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4750/36370, ttl=255
  7 15:30:48.981387 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4751/36626, ttl=128
  8 15:30:48.982277 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4751/36626, ttl=255
Harrys-MacBook-Air:capshift foeh$ capshift -r before.cap -w after.cap -o -0.5

Parsing capfile, attempting to shift backward by 0.500000 seconds...

8 frames processed.
Harrys-MacBook-Air:capshift foeh$ tshark -ta -r after.cap
  1 15:30:45.478539 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4748/35858, ttl=128
  2 15:30:45.479407 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4748/35858, ttl=255
  3 15:30:46.479315 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4749/36114, ttl=128
  4 15:30:46.480274 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4749/36114, ttl=255
  5 15:30:47.480323 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4750/36370, ttl=128
  6 15:30:47.481215 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4750/36370, ttl=255
  7 15:30:48.481387 192.168.1.25 -> 192.168.1.1 ICMP 74 Echo (ping) request  id=0x0001, seq=4751/36626, ttl=128
  8 15:30:48.482277 192.168.1.1 -> 192.168.1.25 ICMP 74 Echo (ping) reply    id=0x0001, seq=4751/36626, ttl=255

As usual, if you find this useful or have any feedback (good or bad) please leave a comment!

Bending the MPLS Security Model - part 3 (Layer 2 Injection)

Attack 1 - layer 2 injection

Back in the days when I did solution validation and regression testing for a living, I normally had to set up full solutions in the lab, built to specific designs. I would then often need test egress QoS policies, filters and so on. To be sure that ingress QoS and filters did not invalidate the results, I had a few options:

1. Temporarily remove the ingress policies, making sure they were re-applied correctly afterwards and that nobody else tested in the mean time

2. Build a duplicate service but instead of terminating the far end on a real device, emulate everything from IGP up on a tester

3. Cheat

Option 1 is pretty risky as "temporary" easily turns into "permanent" if you're not very careful. Option 2 is a lot of work and runs the risk of compromising the design in order to inter-operate with the tester.

Given that the drawbacks of the other available options, I usually fell back on option 3. What I would do is set up the service as per design, then attach the tester somewhere in the MPLS core - basically any port that would label switch. The tester didn't need to peer any protocols at all, saving huge amounts of setup and troubleshooting time, as the packets would be hand crafted in true "dirty hack" style. All I had to do was look at the label bindings on the egress PE to work out what service label to use and on the first hop router to see what transport label needed to be used.

I'll make this example a little simpler by getting a router to do the ARP, work out the transport label and encapsulate the packets. Rest assured that it's perfectly possible to do this by hand if you don't have a real PE. We'll take a simple pseudowire service as an example. We have the following setup:

We want to make our traffic from device X come out of the PE towards LAN B, as if it had been sent through from LAN A. Two things are needed for this:

1. The transport label that will get traffic forwarded to router B
2. The service label that PE B expects to receive for the pseudowire

Now in my lab example, I could just log onto each of the devices and get these. The transport label to get to PE B can be found in the output of the neighbouring router's "show mpls ldp bindings" or similar, in our example we will just let the "evil" PE learn it via LDP.  The service label could be found in the bindings list for PE A or PE B, may be sniffed from live traffic if you have access to somewhere in the switching path, or can be guessed using the information in the previous post.

Anyway, we can use the evil PE to do most of the donkey work for us as far as encapsulation goes. With a fairly simple config, the PE can be made to inject into whatever service we like. Because this is a static config, the evil PE doesn't tell any other devices we are doing this.

Here's the config from the evil PE (Cisco IOS):

mpls label range 100 1048575 static 16 99

!

interface GigabitEthernet1/1

 no ip address

 xconnect 10.255.255.2 100 encapsulation mpls manual

  mpls label 99 19

  mpls control-word

!

The blue section simply reserves part of the label range for static allocation. The actual numbers aren't important but in order to build the bogus EoMPLS service we need to statically assign an incoming label (even though it will never be used). By default, IOS doesn't reserve any of the label space for static allocation and, until you do, you can't assign a manual label. In this example we designate that labels 100 - 1048575 are to be used for dynamic allocation (i.e. given out by LDP, BGP) and labels 16 - 99 are reserved for static allocation, though the actual numbers aren't important.

The red section looks very similar to a normal EoMPLS service build, except for the use of the keyword "manual" and the MPLS tweaks inside. The manual keyword does exactly what you would expect, i.e. it tells the router that this VC will not be signalled using LDP but rather the parameters are going to be manually (statically) configured. 

Once in the xconnect context we define what labels the service will use in each direction - inbound first (we don't care what this is) and then outbound (this has to match the label expected by the EoMPLS service into which we are trying to inject traffic). Remember, you may have to guess the outbound label if you don't have access to either of the serving PEs.

Finally, depending on the vendor and / or configuration of the serving PEs you may need to adjust the control-word setting. Cisco and recent Junipers default to enabled, Alcatel-Lucent and older Junipers default to disabled. 

Now, assuming the label is correct, any frames attacker "X" sends into the Evil PE will come out of the MPLS core and hit user B as if they had been sent by user A. This is unidirectional so the potential for "connecting" to anything is not really there, however there is a massive amount of harm that can be done at this point. Possible attacks range from a simple flood to spanning tree & LACP attacks, even creating IP conflicts or interfering with the operation of routing protocols.

Worked Example

Here's an example showing how an attacker can use the setup above to wreak havoc by throwing in some random PVST packets. The customer setup is as below, with a Cisco switch attached to each of the provider edge routers and a layer 2 service running between.

Note, the switches are running PVST over the link as per default. If a switch sees a BPDU marked as being from the "wrong" VLAN it will decide the port is "broken" (Cisco's terminology, not mine) and block it.

As an attacker we can use this to our advantage by sending frames for 2 different VLAN IDs towards one of the switches. That way, whatever the native VLAN ID of the receiving port is set to, at least one of the VLAN IDs will be incorrect and force the switch to block.

Here's a scruffy scapy loop to do that:

>>> import time
>>> outint='eth0'
>>> bridgemac='\x00\x00\x00\x00\x00\x01'

>>> while True:
...   sendp(Dot3(src='00:00:00:00:00:01', dst='01:80:c2:00:00:00')/LLC(dsap=170,ssap=170,ctrl=3)/Raw(load='\x00\x00\x0c\x01\x0b\x00\x00\x00\x00\x00\x80\x00'+bridgemac+'\x00\x00\x00\x00'+'\x80\x00'+bridgemac+'\x80\x01'+'\x00\x00\x14\x00\x02\x00\x0f\x00\x00'+'\x00\x00\x00\x02'+'\x00\x02'),iface=outint)
...   time.sleep(10)

...   sendp(Dot3(src='00:00:00:00:00:01', dst='01:80:c2:00:00:00')/LLC(dsap=170,ssap=170,ctrl=3)/Raw(load='\x00\x00\x0c\x01\x0b\x00\x00\x00\x00\x00\x80\x00'+bridgemac+'\x00\x00\x00\x00'+'\x80\x00'+bridgemac+'\x80\x01'+'\x00\x00\x14\x00\x02\x00\x0f\x00\x00'+'\x00\x00\x00\x02'+'\x00\x03'),iface=outint)
... 
.
Sent 1 packets.
^C

As long as the loop continues, the port will always remain down. A nice DoS that would be pretty hard to figure out, even if the console messages are quite clear (below from a single BDPU):

SW2#

*Mar  1 02:04:21.755: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 3 on FastEthernet0/1 VLAN1.

*Mar  1 02:04:21.755: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet0/1 on VLAN1. Inconsistent local vlan.

SW2#PVST+: restarted the forward delay timer for FastEthernet0/1

SW2#

*Mar  1 02:04:36.831: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/1 on VLAN1. Port consistency restored.

SW2# PVST+:Inconsistency timer expired. inconsistency 0

                 cleared for FastEthernet0/1

One bad PVST+ BPDU will generally cause the port to block for anywhere between 10 and 50s. It's extremely efficient :)

References

http://www.cisco.com/c/en/us/td/docs/ios/mpls/configuration/guide/15_0s/mp_15_0s_book/mp_atom_pseud_prov.html

http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/layer-two-circuits-overview-solutions.html

Removing VLAN/MPLS/PPPoE/GRE/GTP/VXLAN Encapsulation Headers from pcap Files

Many years ago, when I worked in a school, I used to port mirror our proxy server to an old PC running driftnet and leave the screen where the kids could see it as a warning that staff could "see what you're doing on the Internet". I haven't played with driftnet since but certainly at the time it could only handle native frames (no VLAN tags, certainly no MPLS or PPPoE). I vaguely remember some other tools being similar, unfortunately I can't remember which ones.

Looking at the analytics for this blog, I can see I'm not the only one who's had the problem. It's certainly not the number one issue that people are searching for when they get here but there have been a few and the thought occurred that the packet processing engine I wrote for dechap would be really good for this task - it already stripped back VLANs and MPLS, plus it knows how to detect PPPoE and L2TP.

After a couple of hours it was working to the point of being able to strip VLANs and MPLS off, with a little more effort PPPoE also gave way. GRE came quite easily, too, as it has simple headers and uses the same etypes as Ethernet.

Anyway, here is "stripe" (from STRIP Encapsulation), a command line tool which takes a pcap file as input, re-assembles IP fragments and strips off all the encap it can (currently VLAN tags, MPLS shim headers, PPPoE, L2TP, GRE GTP and VXLAN) then outputs another pcap containing just payload over Ethernet.

**UPDATE** - Version 0.3b now adds support for VXLAN.

Download

Stripe is available from my github: https://github.com/theclam/stripe

Usage

The command line is pretty straightforward, as shown in the online help:

Harrys-MacBook-Air:stripe foeh$ ./stripe
stripe: a utility to remove VLAN tags, MPLS shims, PPPoE, L2TP headers,
etc. from the frames in a PCAP file and return untagged IP over Ethernet.
Version v0.1 alpha, November 2014

Usage:
./stripe -r inputcapfile -w outputcapfile

Where inputcapfile is a tcpdump-style .cap file containing encapsulated IP 
outputcapfile is the file where the decapsulated IP will be saved

Harrys-MacBook-Air:stripe foeh$ 

Simply specify the files you want to read encapsulated packets from (-r) and write the cleaned up packets to (-w). Stripe will remove as many layers of encap as it can until you are left with straight payload over Ethernet.

How it Works

The majority of stripe's work is done by the "decap" function. This function takes in a block of memory, a length parameter, a data type hint and a frame template. The process runs as follows:

1. If the type is Ethernet, populate the source / destination MACs of the frame template
2. If the type has an Ethertype or protocol type field, use this to populate the ethertype of the frame template
3. If the next protocol is possibly or definitely payload, set the payload pointer of the frame template to the address of the next protocol and return
4. If the next protocol is possibly or definitely encapsulation, call decap against the remainder of the packet

So essentially it eats up encap, recording MACs and protocol types as it goes, until there is no more encap left. By the end there is a fully populated frame template with source and destination MAC (the innermost copy if there are multiple as in the case of MPLS pseudowires), the etherype of the payload and the payload itself. Piecing these together gives a minimally encapsulated frame, i.e. one with just an Ethernet header and payload.

Here is a worked example for a frame with VLAN, MPLS, GRE over IP and an IP payload:

Step 1 - The "decap" function is called on the entire frame. Since the first header is Ethernet, the frame template gets populated with the source / destination MACs and the etype from the Ethernet header. The frame template's length field gets populated with the size of the frame minus the Ethernet header and the payload pointer is adjusted to point at the next header. The decap function then calls itself on the remainder of the frame, hinting that the type is VLAN tag based on the current header's etype.

Step 2 - The decap function now considers the partial frame starting at the VLAN tag. Since the VLAN tag has an etype associated, the frame template's etype is overwritten with the one from the VLAN header. The length is overwritten with the length of the payload after the VLAN header and the pointer adjusted to point at the next header. The decap function then calls itself again with a hint of MPLS, based on the etype in the VLAN header.

Step 3 - The decap function now considers the partial frame starting at the MPLS label. Since the MPLS label is bottom of stack, we know there are no more MPLS labels left . Unfortunately there is no protocol type in an MPLS header (these are signaled on the control plane) so we have to take a peek at the byte immediately following the label. If we find a "4" or a "6" in the high order nibble then we have to guess that the next protocol is IPv4 or IPv6, respectively. If the following four bytes are all zeroes then we assume Ethernet over MPLS with control word, otherwise we assume Ethernet over MPLS without control word. In this case we find a 4 in the low nibble, so call decap with an "IP" hint.

Step 4 - The IP header tells us that GRE is the next protocol so for now nothing changes in the frame template (the remainder could be decodable or not). We just call decap again on the GRE part...

Step 5 - The GRE header is decoded and the etype is copied into the frame header. The length of the remaining payload is updated in the frame template and the pointer is adjusted. Decap is called on the next header, which is IP. When the decap function inspects the IP payload it can go no further and just returns the frame template.

In essence, the process has started with a deeply encapsulated frame and ended with IP over Ethernet. The source and destination MACs are taken from the innermost ones found (which in this case is the outermost Ethernet header) but with the etype changed to match the payload, which is the first non-encapsulating payload found in the frame, in this case the second IP.

References

https://tools.ietf.org/html/rfc2784
https://tools.ietf.org/html/rfc1701
http://www.ieee802.org/1/pages/802.1Q.html
http://www.3gpp.org/DynaReport/29060.htm

Troubleshooting PPPoE Client on Cisco Routers

There are are essentially a handful of stages involved in bringing up a PPPoE client session on a Cisco router, each of which could fail for a distinct set of reasons. This guide takes a walk through the entire process, step by step, highlighting the most common causes of problems at each stage.

Routing

Even though PPP itself is peer to peer, PPPoE is inherently client-server. That means that the connection has to be originated by the client and, in most cases, the client will only do that when it has some traffic to send over PPPoE. Therefore, the router must know the dialer as its next hop interface for some destination, i.e. it must have a route. It sounds trivial but it's surprising how often people go to all the trouble of putting in a perfectly good PPPoE config, then forget to put a default route in for the traffic!

More broadly, though, there are other things that could stop a route from being installed. For example, if you configure a dialer as a backup interface to another interface then there are some gotchas. Shutting down the primary will usually not enable its backup, also you still need a (static) route pointing traffic towards the dialer in order to make it dial - a step which is often forgotten. It's usually best to remove the backup interface configuration while testing the dialer, then re-apply it when that has been proven to work.

Dialer

Once traffic hits the dialer interface, the router will only attempt to bring up a PPPoE session if its dialer becomes activated. If a route exists but the dialer is not trying to connect then enable dialer debugging as follows:

Client#debug dialer packet
Dial on demand packets debugging is on
Client#debug dialer event
Dial on demand events debugging is on

Now generate some traffic that should bring up the link, for example by sending a ping:

Client#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:
*Nov  5 21:44:34.147: Di0 DDR: ip (s=10.10.10.10, d=8.8.8.8), 100 bytes, outgoing interesting (ip PERMIT)
*Nov  5 21:44:34.151: Di0 DDR: Cannot place call, no dialer string set.
*Nov  5 21:44:41.491: %DIALER-6-BIND: Interface Vi2 bound to profile Di0
*Nov  5 21:44:41.503: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Nov  5 21:44:41.503: Vi2 DDR: Dialer statechange to up
Client#
*Nov  5 21:44:42.195: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
Client#

*Nov  5 21:44:42.371: Vi2 DDR: dialer protocol up

When the "dialer protocol up" message is received, the dialer has been activated correctly and troubleshooting should move on to the PPPoE stage.

Common problems:

• If no debug messages are generated at all:
• Verify that traffic is being routed towards the dialer interface
• Verify that the dialer-list is configured correctly and referenced by the dialer
• Verify that the dialer's encapsulation is configured to ppp
• Di0 DDR: Cannot place call, no dialer string set. 
• Appears to be spurious, no dialer string is required for PPPoE and it dials anyway
• Di0 DDR: ip (s=10.10.10.10, d=8.8.8.8), 100 bytes, outgoing uninteresting (no dialer-group defined).
• Exactly what it says - dialer is not associated with a dialer list. Ensure a dialer-list is configured and is referred to by the dialer with the "dialer-group x" command.
• Di0 DDR: ip (s=10.10.10.10, d=8.8.8.8), 100 bytes, outgoing uninteresting (dialer-list 2 not defined).
• Again, exactly what it says. The dialer is associated with a non-existent dialer-list. Either re-point the dialer using the "dialer-group x" command or create a new dialer-list with the appropriate number.
• Di0 DDR: ip (s=10.10.10.10, d=8.8.8.8), 100 bytes, outgoing interesting (ip PERMIT)
• Repeated interesting traffic lines but no dialling can occur if the dialer references an empty dialer pool - ensure your PPPoE interface is configured with both "pppoe enable" and "pppoe-client dial-pool-number x". Also ensure that the interface is admin up.
• Could also be due to PPPoE discovery phase failing, see below.

PPPoE Discovery

In order to bring up a PPP session over Ethernet, a PPPoE session must be set up to create a point-to-point connection over a broadcast Ethernet network. This is established using PPPoE Auto-Discovery, where the PPPoE client (our router) searches for a PPPoE access concentrator which is willing to terminate its connection. This phase should operate as follows:

PPPoE Discovery Phase

The client sends a PPPoE Auto Discovery Initiate (PADI) frame, asking any available access concentrators to make themselves known. The access concentrator(s) then respond(s) with a PADO (offer) frame to indicate its availability. The client then sends a PADR (request) frame to its chosen access concentrator which, all being well, will respond with a PADS (session) message to indicate that the PPPoE session is now up. At any time either device may issue a PADT to close the PPPoE session.

To see what is happening at this stage, run the following command:

Client#debug pppoe packet

*Nov  5 20:38:52.107: pppoe_send_padi: 
contiguous pak, size 60
FF FF FF FF FF FF 00 01 02 03 04 05 88 63 11 09
00 00 00 10 01 01 00 00 01 03 00 08 2A 00 00 01
00 00 06 CD 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
*Nov  5 20:38:52.143: PPPoE 0: I PADO  R:0011.2233.4455 L:0001.0203.0405 Fa0/0
contiguous pak, size 66
00 01 02 03 04 05 00 11 22 33 44 55 88 63 11 07
00 00 00 2E 01 01 00 00 01 03 00 08 2A 00 00 01
00 00 06 CD 01 02 00 06 4C 61 62 2D 41 43 01 04
00 10 D5 60 38 B8 05 81 B6 69 29 1B 5E 82 77 A0
5E 91
*Nov  5 20:38:54.155: OUT PADR from PPPoE Session
contiguous pak, size 66
00 11 22 33 44 55 00 01 02 03 04 05 88 63 11 19
00 00 00 2E 01 03 00 08 2A 00 00 01 00 00 06 CD
01 02 00 06 4C 61 62 2D 41 43 01 04 00 10 D5 60
38 B8 05 81 B6 69 29 1B 5E 82 77 A0 5E 91 01 01
00 00
*Nov  5 20:38:54.355: PPPoE 14: I PADS  R:0011.2233.4455 L:0001.0203.0405 Fa0/0
contiguous pak, size 66
00 01 02 03 04 05 00 11 22 33 44 55 88 63 11 65
00 0E 00 2E 01 03 00 08 2A 00 00 01 00 00 06 CD
01 02 00 06 4C 61 62 2D 41 43 01 04 00 10 D5 60
38 B8 05 81 B6 69 29 1B 5E 82 77 A0 5E 91 01 01
00 00
*Nov  5 20:38:54.363: [0]PPPoE 0: O PADT  R:0000.0000.0000 L:0000.0000.0000 Fa0/0
contiguous pak, size 60
00 00 00 00 00 00 00 01 02 03 04 05 88 63 11 A7
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

Client#

The mark of a successful PPPoE Discovery phase is that a PADS packet is received - at this point the PPPoE session is up and troubleshooting focus should shift to the PPP stage.

Common problems:

• Only PADI seen:
• Layer 1 or 2 issue between client and server
• PPPoE traffic being filtered between client and server, max sessions per MAC exceeded
• Sometimes possible even if interface is admin down!
• PADT messages received after PADI or PADR:
• Restrictions on Access Concentrator (e.g. max sessions per MAC exceeded)
• PADT message received after PADS:
• Generally a problem further up the stack, continue troubleshooting

Note - PPPoE discovery may occur without the dialer even being activated.

PPP Negotiation (LCP)

With the PPPoE session up, Link Control Protocol (LCP) will attempt to negotiate the parameters for the actual PPP session. These include useful parameters such as the MRU and authentication type, plus potentially many less applicable parameters such as callback, compression or PPP multilink.

The process is that each side will send proposals (CONFiguration REQuests or CONFREQs) to the other indicating its preferred settings. The opposite device can then respond in one of the following ways:

• Send a CONFiguration ACKnowledgement (CONFACK) to indicate agreement to the proposal
• Send a CONFiguration Negative AcKnowledgement (CONFNAK) to indicate a particular setting should be changed and providing a suggested alternative value. If multiple values need to change, there will be multiple CONFNAKs.
• Send a CONFiguration REJect (CONFREJ) to indicate that either the type or the value of the parameter proposed is completely unacceptable.

Only once all the parameters are agreed between the two peers can the connection be established and higher layer protocols be negotiated. Bear in mind that PPP is inherently peer to peer, so both sides will play the roles of both requester and approver / rejecter.

To see what is happening at this stage, run the following command:

Client#debug ppp negotiation
PPP protocol negotiation debugging is on
*Nov  5 22:11:39.191: %DIALER-6-BIND: Interface Vi2 bound to profile Di0
*Nov  5 22:11:39.207: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Nov  5 22:11:39.211: Vi2 PPP: Sending cstate UP notification
*Nov  5 22:11:39.219: Vi2 PPP: Processing CstateUp message
*Nov  5 22:11:39.251: PPP: Alloc Context [670153F8]
*Nov  5 22:11:39.255: ppp22 PPP: Phase is ESTABLISHING
*Nov  5 22:11:39.259: Vi2 PPP: Using dialer call direction
*Nov  5 22:11:39.259: Vi2 PPP: Treating connection as a callout
*Nov  5 22:11:39.263: Vi2 PPP: Session handle[F4000016] Session id[22]
*Nov  5 22:11:39.263: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Nov  5 22:11:39.267: Vi2 PPP: No remote authentication for call-out
*Nov  5 22:11:39.267: Vi2 LCP: O CONFREQ [Starting] id 1 len 10
*Nov  5 22:11:39.271: Vi2 LCP:    MagicNumber 0x03BD43E3 (0x050603BD43E3)
*Nov  5 22:11:39.271: Vi2 LCP: Event[UP] State[Starting to REQsent]
*Nov  5 22:11:39.323: Vi2 LCP: I CONFREQ [REQsent] id 1 len 19
*Nov  5 22:11:39.323: Vi2 LCP:    MRU 1492 (0x010405D4)
*Nov  5 22:11:39.327: Vi2 LCP:    AuthProto CHAP (0x0305C22305)
*Nov  5 22:11:39.327: Vi2 LCP:    MagicNumber 0x02C2DFB3 (0x050602C2DFB3)
*Nov  5 22:11:39.331: Vi2 LCP: O CONFNAK [REQsent] id 1 len 8
*Nov  5 22:11:39.331: Vi2 LCP:    MRU 1500 (0x010405DC)
*Nov  5 22:11:39.335: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to REQsent]
*Nov  5 22:11:39.395: Vi2 LCP: I CONFACK [REQsent] id 1 len 10
*Nov  5 22:11:39.395: Vi2 LCP:    MagicNumber 0x03BD43E3 (0x050603BD43E3)
*Nov  5 22:11:39.399: Vi2 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
*Nov  5 22:11:39.439: Vi2 LCP: I CONFREQ [ACKrcvd] id 2 len 19
*Nov  5 22:11:39.439: Vi2 LCP:    MRU 1500 (0x010405DC)
*Nov  5 22:11:39.443: Vi2 LCP:    AuthProto CHAP (0x0305C22305)
*Nov  5 22:11:39.443: Vi2 LCP:    MagicNumber 0x02C2DFB3 (0x050602C2DFB3)
*Nov  5 22:11:39.447: Vi2 LCP: O CONFACK [ACKrcvd] id 2 len 19
*Nov  5 22:11:39.447: Vi2 LCP:    MRU 1500 (0x010405DC)
*Nov  5 22:11:39.451: Vi2 LCP:    AuthProto CHAP (0x0305C22305)
*Nov  5 22:11:39.451: Vi2 LCP:    MagicNumber 0x02C2DFB3 (0x050602C2DFB3)
*Nov  5 22:11:39.455: Vi2 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
*Nov  5 22:11:39.467: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Nov  5 22:11:39.467: Vi2 LCP: State is Open
Client#

To explain the above transaction, I have highlighted the two conversations in different colours. "O" indicates an outbound frame, "I" an inbound frame.

The blue conversation is what we (the client) are proposing to the access concentrator. The client sends an essentially empty proposal with only a magic number (used for loop detection). The access concentrator responds with an acknowledgement, after all there's nothing to argue about!

The red conversation (where the access concentrator is proposing settings) is slightly more interesting. The first proposal contains a proposed maximum receive unit (MRU) size of 1492 and a proposal to use CHAP authentication. In the next frame our client sends a NAK message to indicate it would prefer the access concentrator used an MRU of 1500. Following that, the access concentrator sends a new proposal with an MRU of 1500 and CHAP authentication, which our client then acknowledges.

Now that both sides are in agreement, the state changes to "Open", which is PPP talk for "up".

Common Problems:

• MRU mismatch - many access concentrators are strictly RFC 2516 compliant and allow a maximum MRU of 1492. This is because 1492 bytes IP + 6 bytes PPPoE + 2 bytes PPP is the largest that can fit inside a standard 1500 byte Ethernet payload. It may be necessary to tweak the MTU on the Ethernet interface using the "pppoe-client ppp-max-payload xxxx" command.
• Authentication type mismatch - if one peer is set for CHAP only while the other is set to PAP only or no authentication, they are not going to talk. A common mistake is forgetting the authentication callin option, which means that the client asks the server to authenticate itself - this is almost invariably not.

General Note:

If you examine the debug output, it will be clear what the local device is saying (marked with "O" for output) and what the other end is saying (marked with "I" for input). Whichever options are being rejected (CONFREJ'd) will be at the root of the problem - just work out which end is rejecting what and the rest should fall into place.

PPP Authentication

PPP has the ability to authenticate either, both or neither of the peers. In a typical deployment, the access concentrator will require the client to authenticate, but will refuse to authenticate itself to the client. This is typically done using CHAP as in the example below (output from "debug ppp negotiation"):

*Nov  5 22:11:39.259: Vi2 PPP: Treating connection as a callout
*Nov  5 22:11:39.263: Vi2 PPP: Session handle[F4000016] Session id[22]
*Nov  5 22:11:39.263: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Nov  5 22:11:39.267: Vi2 PPP: No remote authentication for call-out
-- SNIP --
*Nov  5 22:11:39.467: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Nov  5 22:11:39.527: Vi2 CHAP: I CHALLENGE id 1 len 27 from "Lab-AC"
*Nov  5 22:11:39.543: Vi2 CHAP: Using hostname from interface CHAP
*Nov  5 22:11:39.543: Vi2 CHAP: Using password from interface CHAP
*Nov  5 22:11:39.543: Vi2 CHAP: O RESPONSE id 1 len 30 from "pppoeuser"
*Nov  5 22:11:39.835: Vi2 CHAP: I SUCCESS id 1 len 4
*Nov  5 22:11:39.839: Vi2 PPP: Phase is FORWARDING, Attempting Forward

The output clearly shows that this connection is considered to be a "callout", i.e. we are the initiating party. Next, the debug informs us that we do not require the remote party to authenticate.

Following that, the peer (the access concentrator) asks us to authenticate. It sends us a "CHALLENGE", we send a "RESPONSE", then it sends us a "SUCCESS" message, indicating that our credentials were accepted.

Common problems:

• It is worth noting the lines which state we are using the hostname and password from interface CHAP. This means that the hostname (in practice essentially a username) and password are configured under the dialer interface with the "ppp chap hostname xxx" and "ppp chap password xxxx". If these are not specified, the router will use its actual hostname and the password will be taken from the local user database, under a user named after the the peer's hostname. Usually that's not what you want.
• A response of "CHAP: I FAILURE id 1 len 25 msg is "Authentication failed"" means exactly what it looks like it means. Check both the username and password are configured correctly.
• A response of "CHAP: Unable to authenticate for peer" indicates that the device does not  know what password to use to authenticate with the peer. This can be because a "ppp chap hostname" is configured but a "ppp chap password" is not, there is not even a "ppp chap hostname" configured or in the case where local usernames are being used it means there's no local username which matches the AC's hostname.

IPCP

Once the PPP session has been brought up (negotiated through LCP), the next stage is to negotiate each of the protocols that will run through the PPP tunnel. Normally this is just IPv4, which is negotiated using IPCP, but there are also IPv6CP, CDPCP and so on, collectively known as Network Control Protocols or NCPs. Below is some example debug (output from "debug ppp negotiation"), with the AC's IP negotiation in blue and the client's IP negotiation in red:

*Nov  5 22:11:39.867: Vi2 PPP: Queue IPCP code[1] id[1]
*Nov  5 22:11:39.883: Vi2 PPP: Phase is ESTABLISHING, Finish LCP
*Nov  5 22:11:39.887: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
*Nov  5 22:11:39.899: Vi2 PPP: Phase is UP
*Nov  5 22:11:39.903: Vi2 IPCP: Protocol configured, start CP. state[Initial]
*Nov  5 22:11:39.903: Vi2 IPCP: Event[OPEN] State[Initial to Starting]
*Nov  5 22:11:39.907: Vi2 IPCP: O CONFREQ [Starting] id 1 len 10
*Nov  5 22:11:39.907: Vi2 IPCP:    Address 0.0.0.0 (0x030600000000)
*Nov  5 22:11:39.911: Vi2 IPCP: Event[UP] State[Starting to REQsent]
*Nov  5 22:11:39.915: Vi2 PPP: Process pending ncp packets
*Nov  5 22:11:39.915: Vi2 IPCP: Redirect packet to Vi2
*Nov  5 22:11:39.915: Vi2 IPCP: I CONFREQ [REQsent] id 1 len 10
*Nov  5 22:11:39.919: Vi2 IPCP:    Address 1.1.1.1 (0x030601010101)
*Nov  5 22:11:39.923: Vi2 IPCP: O CONFACK [REQsent] id 1 len 10
*Nov  5 22:11:39.923: Vi2 IPCP:    Address 1.1.1.1 (0x030601010101)
*Nov  5 22:11:39.927: Vi2 IPCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
*Nov  5 22:11:39.987: Vi2 IPCP: I CONFNAK [ACKsent] id 1 len 10
*Nov  5 22:11:39.987: Vi2 IPCP:    Address 172.16.0.6 (0x0306AC100006)
*Nov  5 22:11:39.991: Vi2 IPCP: O CONFREQ [ACKsent] id 2 len 10
*Nov  5 22:11:39.991: Vi2 IPCP:    Address 172.16.0.6 (0x0306AC100006)
*Nov  5 22:11:39.995: Vi2 IPCP: Event[Receive ConfNak/Rej] State[ACKsent to ACKsent]
*Nov  5 22:11:40.055: Vi2 IPCP: I CONFACK [ACKsent] id 2 len 10
*Nov  5 22:11:40.059: Vi2 IPCP:    Address 172.16.0.6 (0x0306AC100006)
*Nov  5 22:11:40.059: Vi2 IPCP: Event[Receive ConfAck] State[ACKsent to Open]
*Nov  5 22:11:40.071: Vi2 IPCP: State is Open
*Nov  5 22:11:40.075: Di0 IPCP: Install negotiated IP interface address 172.16.0.6
*Nov  5 22:11:40.131: Di0 Added to neighbor route AVL tree: topoid 0, address 1.1.1.1
*Nov  5 22:11:40.135: Di0 IPCP: Install route to 1.1.1.1

Common Problems:

• If no IPCP appears at all, it could be that both ends have "ppp ncp passive" set.

• If you see a message similar to "O PROTREJ [Open] id 2 len 16 protocol IPCP (0x0101000C030601010101)" this is because IP is not configured on the local dialer interface. Usually you just want to add "ip address negotiated" under the dialer to fix this.

At this point your session is up and you should be able to pass traffic OK. If you're still looking, it may help to read my blog post on the theory behind bringing up a PPPoE session.

References

http://tools.ietf.org/html/rfc2516 (PPPoE)
http://tools.ietf.org/html/rfc4638 (PPPoE large MRU)
http://tools.ietf.org/html/rfc1661 (PPP)

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

Quiet Mode on ME3x00 Platforms

The Cisco ME3x00 range of devices comes with automatic lockout for SSH as default. If too many bad login attempts are made within a short period of time, the device will go into a locked down state called "quiet mode" which blocks any new management connections.

In a default configuration, entering quiet mode causes the device to completely refuse any and all new telnet, SSH and port 80 sessions directed towards it. Existing (open) sessions are not affected. If you've ever tried a couple of credentials out, then suddenly started getting "connection refused", you have probably run into this feature!

The default threshold and timer values are as follows:

• An artificial 1 second delay is added to each login
• 5 bad logins within 60 seconds triggers a lockout
• lockout lasts 5 minutes

If that's all you needed to know then I suppose you can go now :)

If you're interested in checking / tweaking the settings, read on.

The commands to view and edit settings relevant to this feature all centre around "login", for example:

ME3x00#show login
     A default login delay of 1 seconds is applied.
     No Quiet-Mode access list has been configured.

     Router enabled to watch for login Attacks.
     If more than 5 login failures occur in 60 seconds or less,
     logins will be disabled for 300 seconds.

     Router presently in Normal-Mode.
     Current Watch Window remaining time 37 seconds.
     Present login failure count 1.

ME3x00#

One thing to note here is that if you try to authenticate with public keys (like openssh and others do by default) it will refuse and count that as a failure. If you bail out at the password prompt (i.e. ctrl-C or leave it time out) then that also counts as a failure. It doesn't take long to get to 5! Attempts blocked by the VTY ACLs don't count.

If you would like to force a longer delay between login attempts, you can adjust the value (between 1 and 10 seconds) under config mode as follows:

ME3x00(config)# login delay 5

The lockout thresholds can easily be changed using the following command:

ME3x00(config)# login block-for 120 attempts 10 within 60

This example would cause the device to trigger a two minute lockdown into quiet mode if it saw 10 failed logins within 60 seconds.

Now the 5 minute default logout is quite a long time and being able to force a lockdown could be advantageous to attackers - if you can prevent an administrator from being able to log into a device then it makes it far more difficult for him to detect and / or mitigate attacks on the network. Luckily there is a feature available to effectively whitelist management traffic that should always be allowed through, even when the device goes into lockdown. This comes in the form of the "login quiet-mode access-class", which basically decides what access controls are put in place when the device enters quiet mode. By default, the quiet-mode access-class is set to "sl_def_acl", which is an omnipresent ACL which looks like this:

ME3x00#show ip access-list sl_def_acl
Extended IP access list sl_def_acl
    10 deny tcp any any eq telnet (7 matches)
    20 deny tcp any any eq www
    30 deny tcp any any eq 22 (72 matches)
    40 permit ip any any

ME3x00#

In order to provide back door access when the device enters quiet mode, simply define an ACL which permits the desired traffic but blocks all other management traffic, such as:

ME3x00(config)#ip access-list extended quiet_mode_access

ME3x00(config-ext-nacl)#permit tcp host 10.1.1.1 any eq 22
ME3x00(config-ext-nacl)#deny tcp any any eq telnet
ME3x00(config-ext-nacl)#deny tcp any any eq www
ME3x00(config-ext-nacl)#deny tcp any any eq 22 
ME3x00(config-ext-nacl)#exit

Then apply it to the box using:

ME3x00(config)#login quiet-mode access-class quiet_mode_access 

That way a dedicated management box (10.1.1.1) will always be able to connect and manage the device, even if it is in quiet mode, while everything else will be locked out.

Logging

The device also generates some helpful syslog messages to tell you what it's doing, for example here is my device going into quiet mode:

%SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 22 secs, [user: billybob] [Source: 10.10.10.10] [localport: 22] [Reason: Login Authentication Failed] [ACL: sl_def_acl] at 16:30:00 BST Sun Oct 5 2014

And coming out again:

%SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 16:35:00 BST Sun Oct 5 2014

References

Cisco IOS Security Configuration Guide

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