Showing posts with label layer-2 protocols. Show all posts
Showing posts with label layer-2 protocols. Show all posts

Monday, November 7, 2016

Advanced Cisco Configuration: Access Ports, Trunk Ports and Native VLANs

I ran into a very interesting problem today that, in hindsight, was rather obvious. Suppose we have a router with a switchport module in one of its open slots connected to a managed switch. Let's use FastEthernet0/15 for the switchport module interface connected to FastEthernet0/0 on the standalone switch. Fa0/15 on the router's switchport module is configured as an access port on some particular VLAN, say VLAN 10, and Fa0/0 on the standalone switch is configured as a trunk port on some different VLAN, say 238. The problem came to my attention because the log files on the router were filling up with errors along the lines of this:
01:48:19: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/15...

At first glance, I was somewhat confused by this because the CDP error message suggested that the Native VLAN's on the two switchports didn't match (the standalone switch had the native VLAN left at its default, or VLAN 1). I didn't have access to the switch, so I couldn't look at its configuration, but I knew that a trunk port on the switch could NOT communicate with the access port on the router's switch module. What, then, were the techs who originally set this up trying to accomplish? With the VLAN mismatch, there shouldn't have been any traffic flowing from the switch to the router, right?

Well, no.

After mocking things up in GNS3 as well as in hardware with a spare 3825 and a Catalyst 2950 at my desk, I was able to figure out what was actually happening. In short, the managed switch was sending Ethernet frames with a VLAN tag out Fa0/0, which the router was dutifully discarding, since it was expecting untagged frames. However, any traffic on VLAN 1 -- the default native VLAN -- on the switch was being sent out of Fa0/0 as untagged frames...which the router happily accepted as belonging to VLAN 10 when they entered Fa0/15. CDP wasn't happy about this, since it could tell that the native VLAN on the managed switch wasn't the same as the VLAN configured on router's switchport, but since configuring a port as an access port means, "accept any untagged Ethernet frames coming in to this port, and place them in VLAN 10," traffic was still flowing between the switch and the router.

Needless to say, this is bad practice and is very insecure. If you don't match up the native VLAN's between Layer-2 devices, it is very easy to allow traffic across your network that you didn't intend. Even worse, VLAN 1 is the default management VLAN on Cisco switches, so essentially, you are allowing traffic that is supposed to be in one VLAN into the management VLAN on the standalone switch (!). This is why CDP raises an alarm about misconfigurations such as this: in all likelihood, something is happening that you did not intend. In fact, when I mocked this up on a pair of 3640 routers with NM16-ESW switch modules in GNS3, spanning-tree on the 3640 disabled the port until I disabled spanning tree on the affected VLAN:
00:21:54: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet0/15 VLAN106.
00:21:54: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/15 on VLAN106. Inconsistent port type.
R1(config)#no spanning-tree vlan 106

Interestingly enough, the router didn't complain when I set up the connected interfaces as access ports in different VLAN's -- it was only once the router received an Ethernet frame with an 802.1Q VLAN tag that spanning-tree disabled the port on me. Even more interesting, the physical Cisco 3825 router with a 16-port switch module and 2950 switch did not disable any ports with a similar configuration (perhaps Spanning-Tree was not running on the 3825?).

Wednesday, November 13, 2013

JNCIA Lesson 8 -- Link Aggregation

In the lesson on Spanning Tree, we addressed the issue of redundancy, but what if your users are consuming more bandwidth than a single Gig-E uplink port can provide? STP/RSTP/MSTP allows you to connect multiple links between switches, but only ONE path can be active at any time, so you are still limited to 1Gbps between switches (assuming a Gig-E switch, of course).

Fortunately, there is a standardized protocol, known as "Link Aggregation Control Protocol" (LACP) or sometimes simply "LAG" (Link AGgregation) for creating bundled Ethernet links between switches. That is, in much the same way that a T1 line is a bundle of individual 64kbps lines that have been concatenated together to provide 1.544Mbps of bandwidth, there is also a way to bundle several individual Ethernet channels together to create a single, virtual channel with a bandwidth equal to the sum of the physical Ethernet links in the bundle. For example, if we were to take two Gig-E ports on our EX3200 switches and aggregate them together using LACP, we would have a 2Gbps (2 x 1Gbps) uplink between the switches. Even better, having multiple Ethernet ports in a LAG group provides not only increased bandwidth between switches, but also provides redundancy. If a single channel in the LAG group fails, the LAG bundle continues to carry traffic, albeit at a reduced rate.

Fortunately, it is very simple to create a LAG group between ports on the EX3200 switch, taking only four, easy steps:
  1. Create the virtual aggregated interface for the LAG group using the "set chassis aggregated-devices..." command (this will create a new interface, ae0, on the switch);
  2. Delete unit 0 in the interfaces that you want to bundle together;
  3. Use the "set interfaces...ether-options 802.3ad..." command to associate the physical interfaces that you want to aggregate with the virtual aggregated interface that you created in step 1; and
  4. Set the configuration options for the virtual aggregated interface with the "set interfaces...aggregated-ether-options..." and "set interfaces...family ethernet-switching" commands.
Let's set up a LAG group between ge-0/0/22 and ge-0/0/23 on two of our Juniper switches:

root@main3200# set chassis aggregated-devices ethernet device-count 1

[edit]
root@main3200# delete interfaces ge-0/0/22 unit 0

[edit]
root@main3200# delete interfaces ge-0/0/23 unit 0

[edit]
root@main3200# set interfaces ge-0/0/22 ether-options 802.3ad ae0

[edit]
root@main3200# set interfaces ge-0/0/23 ether-options 802.3ad ae0

[edit]
root@main3200# set interfaces ae0 aggregated-ether-options lacp active

[edit]
root@main3200# set interfaces ae0 unit 0 family ethernet-switching

[edit]
root@main3200# commit
commit complete

[edit]
root@main3200#
You now have a working LAG bundle between the switches, but if you try to ping from a host connected to one switch to a host connected on the other, you will find your pings failing with a "destination unreachable" error. Since you have multiple VLANs on the two switches, you will need to tag the VLANs on the aggregated Ethernet port, ae0, before hosts on the two switches can communicate with each other:

root@main3200# edit interfaces ae0 unit 0 family ethernet-switching

[edit interfaces ae0 unit 0 family ethernet-switching]
root@main3200# set port-mode trunk

[edit interfaces ae0 unit 0 family ethernet-switching]
root@main3200# set vlan members 20

[edit interfaces ae0 unit 0 family ethernet-switching]
root@main3200# set native-vlan-id default

[edit interfaces ae0 unit 0 family ethernet-switching]
root@main3200# commit
commit complete

[edit interfaces ae0 unit 0 family ethernet-switching]
root@main3200#


Now, connect a pair of Ethernet cables between the switches -- one from ge-0/0/22 on one switch to ge-0/0/22 on the second switch, and likewise for ge-0/0/23 -- and let's see if we can ping from a host on one switch to a host on the second switch:

me@myllt:~$ ping -c4 192.168.10.8
PING 192.168.10.8 (192.168.10.8) 56(84) bytes of data.
64 bytes from 192.168.10.8: icmp_req=1 ttl=64 time=0.795 ms
64 bytes from 192.168.10.8: icmp_req=2 ttl=64 time=0.502 ms
64 bytes from 192.168.10.8: icmp_req=3 ttl=64 time=0.519 ms
64 bytes from 192.168.10.8: icmp_req=4 ttl=64 time=0.501 ms

--- 192.168.10.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.501/0.579/0.795/0.125 ms
me@myllt:~$


Sweet! We have connectivity :) Now, let's see what happens when we pull an Ethernet cable:

me@myllt:~$ ping 192.168.10.8
PING 192.168.10.8 (192.168.10.8) 56(84) bytes of data.
64 bytes from 192.168.10.8: icmp_req=1 ttl=64 time=0.948 ms
64 bytes from 192.168.10.8: icmp_req=2 ttl=64 time=0.312 ms
64 bytes from 192.168.10.8: icmp_req=3 ttl=64 time=0.484 ms
64 bytes from 192.168.10.8: icmp_req=4 ttl=64 time=0.500 ms
64 bytes from 192.168.10.8: icmp_req=5 ttl=64 time=0.493 ms
64 bytes from 192.168.10.8: icmp_req=6 ttl=64 time=0.492 ms
64 bytes from 192.168.10.8: icmp_req=7 ttl=64 time=0.506 ms
64 bytes from 192.168.10.8: icmp_req=9 ttl=64 time=0.496 ms
64 bytes from 192.168.10.8: icmp_req=10 ttl=64 time=0.489 ms
64 bytes from 192.168.10.8: icmp_req=11 ttl=64 time=0.492 ms
64 bytes from 192.168.10.8: icmp_req=12 ttl=64 time=0.493 ms
64 bytes from 192.168.10.8: icmp_req=13 ttl=64 time=0.481 ms
64 bytes from 192.168.10.8: icmp_req=14 ttl=64 time=0.492 ms
64 bytes from 192.168.10.8: icmp_req=15 ttl=64 time=0.505 ms
^C
--- 192.168.10.8 ping statistics ---
15 packets transmitted, 14 received, 6% packet loss, time 13998ms
rtt min/avg/max/mdev = 0.312/0.513/0.948/0.129 ms
me@myllt:~$


Cool -- we only dropped one packet while the Junipers rerouted all of the traffic onto the good Ethernet link, and unlike STP/RSTP/MSTP, when both links are active, we can use all of the available bandwidth, rather than just a single 1Gbps link at a time.

Monday, November 11, 2013

JNCIA Lesson 5 -- VLANs

Up to this point, there has been an "elephant in the room" that we've carefully been sidestepping around. So far, many of our configs have referenced VLANs and Juniper's related -- but significantly different -- concept of "units." Today, we'll dig into VLANs and try to figure out exactly what they are and how to use them. We'll start with a common problem in networking that will hopefully illustrate the use and power of VLANs, then implement a solution for this problem in JunOS.

Suppose you have built a data network for your organization using standard Layer-2-only switches. Shortly afterwards, your internal PBX catastrophically fails beyond any hope of recovery. You decide that continuing to use antiquated POTS telephony is a poor idea, and instead, decide to implement an Asterisk open-source, voice-over-IP (VoIP) PBX system instead. Having done your homework, you are well aware of the common pitfalls associated with VoIP services -- such as Quality of Service (QoS), latency and jitter -- and therefore, you want to roll out the PBX on an entirely new network to minimize contention with other network consumers. However, it seems wasteful to buy additional switches for your enterprise, when you've already got unused ports on the switches you already have in use.

If only there were some way to logically separate the switch ports into separate networks, so that data users would only be in contention with each other for bandwidth while VoIP users could be on their own low-latency network...

Fortunately, this is exactly what VLANs were created to do. VLANs are a logical separation of two (or more) networks using the physical hardware of only one network. Remember when you were a kid and had to share a bedroom with brother or sister? Did you ever get into a fight with your sibling, and draw a line down the middle of the room, declaring something to the effect of, "This is my half of the room, and that is your half. Keep out of my half of the room!" That's basically all a VLAN does -- it splits the switch into separate broadcast domains so that traffic on one virtual LAN (VLAN) does not interact with traffic from other VLANs.

There are two ways for this split to occur, and typically, both methods will be used. First, you can separate the VLANs by port -- ports 1, 5, and 18-24 all belong to VLAN 10, while the remaining ports belong to VLAN 20, for example -- or you can separate traffic into separate VLANs by adding a tag into the Ethernet frame to mark certain frames as belonging to one VLAN and other frames as belonging to another VLAN. Each frame can belong to one and only one VLAN; there is no way to define a frame as belonging to multiple VLANs. Generally speaking, if the port will be connected to a client device -- a desktop, laptop, VoIP telephone, etc. -- you will define the VLAN by port, what is often referred to as an "untagged" or "access" VLAN port. On the other hand, if the port will be used to connect another network device, such as another switch or a router or sometimes even a server -- in other words, any time you potentially want more than one VLAN to transit an Ethernet link -- you will "tag" the frames coming from that port, creating a "tagged" or "trunk" port.

Let's take the example of the VoIP network and look at how we would implement such a design on the EX3200 switches. We've decided to use ports 0-7 on each EX3200 switch for the VoIP service because these ports support Power over Ethernet (PoE), which we can use to power the VoIP telephones (we'll just accept that statement as-is for the time being, as a full discussion of PoE is beyond the scope of this discussion). Additionally, we'll need a port for the Asterisk server, so we will add ge-0/0/8 to the VoIP VLAN, as well. We'll start the configuration by defining the Voice over IP VLAN on the switches:

root@main3200# edit vlans

[edit vlans]
root@main3200# set voip vlan-id 20

[edit vlans]
root@main3200#


Next, we need to define the VLAN interface:

root@main3200# top edit interfaces

[edit interfaces]
root@main3200# set vlan unit 20

[edit interfaces]
root@main3200#


If we wanted this VLAN to be routed, this is where we would add a Layer-3 address to the VLAN interface. Since we have three offices connected over a Layer-3 network, let's go ahead and add the IP address 192.168.10.1/24 to the main3200 router:

root@main3200# delete vlan unit 20 family ethernet-switching

[edit interfaces]
root@main3200# set vlan unit 20 family inet address 192.168.10.1/24

[edit interfaces]
root@main3200#


Now that we have defined the VLANs and the virtual interfaces through which the EX3200 will communicate, we'll need to assign these VLANs to the Gigabit Ethernet ports on the switch. The default VLAN is assigned to each switchport by, well, default. Therefore, we'll only need to add VLAN 20 the Ethernet ports that are used by the VoIP phones and PBX. We've already decided to put ge-0/0/0 through ge-0/0/8 into the VoIP VLAN, so let's make it so:

root@main3200# top

[edit]
root@main3200# set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members voips

[edit]
root@main3200# set interfaces ge-0/0/3 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/4 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/5 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/6 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/7 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/8 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# commit
commit complete

[edit]
root@main3200#


We now have nine Ethernet ports, ge-0/0/0 through ge-0/0/8 in the "voip" VLAN (VLAN 20). You hook up Linux hosts to two of the ports, connect a third Linux host to ge-0/0/10 (in the "default" VLAN), configure all of their IP addresses to all be in the 192.168.1.0/24 subnet, and start testing. As expected, hosts on ge-0/0/0 through ge-0/0/8 can talk to each other, but the host on ge-0/0/10 cannot reach either of the other two hosts, since it is in a different VLAN:

root@ge-0-0-2:/root# ping 192.168.1.238
PING 192.168.1.238 (192.168.1.238) 56(84) bytes of data.
64 bytes from 192.168.1.238: icmp_seq=1 ttl=64 time=0.436 ms
64 bytes from 192.168.1.238: icmp_seq=2 ttl=64 time=0.241 ms
64 bytes from 192.168.1.238: icmp_seq=3 ttl=64 time=0.234 ms
64 bytes from 192.168.1.238: icmp_seq=4 ttl=64 time=0.212 ms

--- 192.168.1.238 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.212/0.280/0.436/0.092 ms
root@ge-0-0-2:/root#
...
root@ge-0-0-10:~# nmap -sP 192.168.1.0/24

Starting Nmap 6.00 ( http://nmap.org ) at 2013-10-25 11:09 AKDT
Nmap scan report for 192.168.1.134
Host is up.
Nmap done: 256 IP addresses (1 host up) scanned in 11.12 seconds
root@ge-0-0-10:~# ip addr | egrep eth0 | egrep inet
inet 192.168.1.134/24 brd 192.168.1.255 scope global eth0
root@ge-0-0-10:~#
...
root@ge-0-0-6:~# ping -c4 192.168.1.134
PING 192.168.1.134 (192.168.1.134) 56(84) bytes of data.
From 192.168.1.238 icmp_seq=1 Destination Host Unreachable
From 192.168.1.238 icmp_seq=2 Destination Host Unreachable
From 192.168.1.238 icmp_seq=3 Destination Host Unreachable
From 192.168.1.238 icmp_seq=4 Destination Host Unreachable

--- 192.168.1.134 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3014ms
root@ge-0-0-6:~# ping -c4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.96 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.176 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.164 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=0.165 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.164/0.617/1.965/0.778 ms
root@ge-0-0-6:~#


Perfect! Now, let's see if we can get ge-0/0/23 configured to do 802.1q tagging so we can use it as an uplink port from the second switch in the Main Office LAN:

root@main3200# edit interfaces ge-0/0/23 unit 0 family ethernet-switching

[edit interfaces ge-0/0/23 unit 0 family ethernet-switching]
root@main3200# set port-mode trunk

[edit interfaces ge-0/0/23 unit 0 family ethernet-switching]
root@main3200# set vlan members 20

[edit interfaces ge-0/0/23 unit 0 family ethernet-switching]
root@main3200# set native-vlan-id default

[edit interfaces ge-0/0/2 unit 0 family ethernet-switching]
root@main3200# commit
commit complete

[edit interfaces ge-0/0/2 unit 0 family ethernet-switching]
root@main3200#


Now, connect a cross-over cable between the two switches, and connect two hosts to each switch, one host (per switch) on ge-0/0/2 and one host (per switch) on ge-0/0/10. First we'll try pinging from a PC in the default VLAN on the first switch (main3200, ge-0/0/10) to all three other hosts:

root@mo-ge-0-0-10# ping -c4 mo2-ge-0-0-10.example.com
PING mo2-ge-0-0-10.example.com (192.168.1.134) 56(84) bytes of data.
64 bytes from 192.168.1.134: icmp_seq=1 ttl=64 time=0.590 ms
64 bytes from 192.168.1.134: icmp_seq=2 ttl=64 time=0.383 ms
64 bytes from 192.168.1.134: icmp_seq=3 ttl=64 time=0.363 ms
64 bytes from 192.168.1.134: icmp_seq=4 ttl=64 time=0.392 ms

--- mo2-ge-0-0-10.example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.363/0.432/0.590/0.091 ms
root@mo-ge-0-0-10/root# ping -c4 mo-ge-0-0-2.example.com
PING mo-ge-0-0-2.example.com (192.168.1.17) 56(84) bytes of data.
From 192.168.1.250 icmp_seq=1 Destination Host Unreachable
From 192.168.1.250 icmp_seq=2 Destination Host Unreachable
From 192.168.1.250 icmp_seq=3 Destination Host Unreachable
From 192.168.1.250 icmp_seq=4 Destination Host Unreachable

--- mo-ge-0-0-2.example.com ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms, pipe 3
root@mo-ge-0-0-10:/root# ping -c4 mo2-ge-0-0-2.example.com
PING mo2-ge-0-0-2.example.com (192.168.1.129) 56(84) bytes of data.
From 192.168.1.250 icmp_seq=1 Destination Host Unreachable
From 192.168.1.250 icmp_seq=2 Destination Host Unreachable
From 192.168.1.250 icmp_seq=3 Destination Host Unreachable
From 192.168.1.250 icmp_seq=4 Destination Host Unreachable

--- mo2-ge-0-0-2.example.com ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms, pipe 3
root@mo-ge-0-0-10:/root#


Exactly what I expected to see: the host on switch one, port ge-0/0/10 can ping the host on switch two, port ge-0/0/10, but cannot ping the hosts on ge-0/0/2 on either switch. Perfect! Let's make sure the hosts on ge-0/0/2 can ping each other but not hosts on ge-0/0/10:

root@mo-ge-0-0-2:/root# ping -c4 mo2-ge-0-0-10
PING mo2-ge-0-0-10 (192.168.1.134) 56(84) bytes of data.
From 192.168.1.17 icmp_seq=1 Destination Host Unreachable
From 192.168.1.17 icmp_seq=2 Destination Host Unreachable
From 192.168.1.17 icmp_seq=3 Destination Host Unreachable
From 192.168.1.17 icmp_seq=4 Destination Host Unreachable

--- mo2-ge-0-0-10 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms pipe 4
root@mo-ge-0-0-2:/root# ping -c4 mo2-ge-0-0-2
PING mo2-ge-0-0-2 (192.168.1.129) 56(84) bytes of data.
64 bytes from 192.168.1.129: icmp_req=1 ttl=64 time=0.509 ms
64 bytes from 192.168.1.129: icmp_req=2 ttl=64 time=0.233 ms
64 bytes from 192.168.1.129: icmp_req=3 ttl=64 time=0.247 ms
64 bytes from 192.168.1.129: icmp_req=4 ttl=64 time=0.283 ms

--- mo2-ge-0-0-2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.233/0.318/0.509/0.111 ms
root@mo-ge-0-0-2:/root# ping -c4 mo-ge-0-0-10
PING mo-ge-0-0-10 (192.168.1.250) 56(84) bytes of data.
From 192.168.1.17 icmp_seq=1 Destination Host Unreachable
From 192.168.1.17 icmp_seq=2 Destination Host Unreachable
From 192.168.1.17 icmp_seq=3 Destination Host Unreachable
From 192.168.1.17 icmp_seq=4 Destination Host Unreachable

--- mo-ge-0-0-10 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3015ms pipe 3
root@mo-ge-0-0-2:/root#


Again, that's exactly what I wanted to see! The hosts on ge-0/0/2 on both switches can ping each other, but can't ping hosts on ge-0/0/10. Since both VLANs are working properly across the uplink between the two switches, we know that VLAN 20 (VoIP) is being 802.1q tagged properly on ge-0/0/21, and the default VLAN (PCs and servers) is being carried as the native (untagged) VLAN on the same port.

Since the EX3200 contains routing code as well as switching code, we can configure our routing protocols to route from one VLAN to the other, if we choose:

root@main3200# show protocols ospf
export ospf-default;
area 0.0.0.0 {
    interface ge-0/0/21.0;
    interface vlan.0 {
        passive;
    }
    interface vlan.20 {
        passive;
    }
    interface ge-0/0/19.0 {
        passive;
    }
}

[edit]
root@main3200#


By placing both vlan.0 and vlan.20 into the OSPF process, the router will now route between the two VLAN interfaces (what is called, "Routing-on-a-Stick," or sometimes, a "one-armed router").

Tuesday, October 8, 2013

Lesson 14 -- Advanced WAN Configurations, Part 1

In Lesson 5 you set up a very simple WAN between your main office 2651 router and the remote site's 3640 router. The configuration for this link was pretty minimalist:

interface Serial0/1
description T1 to lab3640rtr
bandwidth 1544
ip address 192.168.3.5 255.255.255.252


This configuration used HDLC -- the default on Cisco routers -- to establish the WAN link to the 3640 router, set the bandwidth (used by routing protocols that consider bandwidth in their metrics) to 1.544Mbps, and establishes a /30 (two host) subnet between the routers, one IP address for each endpoint. However, you decide that you would like to implement PPP rather than HDLC, since PPP can be configured to use PAP or CHAP to authenticate the routers on each side of the link, and because if you manage to scrounge a couple of new T1 cards (and the funds to buy a second leased line) you can use Multilink PPP to give you a 3Mbps channel between sites. You telnet to the remote router, issue a "reload in 30" command to return the 3640 to its original configuration if you botch the changes (it's saved my backside more than once), then get started on configuring PPP:

lab3640rtr#conf t
lab3640rtr(config)#int serial 0/1
lab3640rtr(config-if)#encapsulation ppp


Your telnet session locks up, but you expected that. Now, configure the local side:

lab2651rtr#conf t
lab2651rtr(config-if)#encapsulation ppp
lab2651rtr(config-if)#exit
lab2651rtr(config)#exit
lab2651rtr#sho int ser0/1
Serial0/1 is up, line protocol is up


You return to your telnet session to the 3640 router, and hit the "Enter" key a couple of times to make sure it's responding again, and it is. Woohoo! You've enabled PPP successfully. You type "reload cancel" and "write mem" on both routers to save the current configurations, then set up PPP authentication using CHAP. To do this, you'll need to configure a user name on each router that matches the host name of the other router and assign the same password to both user names. That is, on the lab3640rtr router, you will create a user "lab2651rtr" and on the lab2651rtr, you will create a user "lab3640rtr":

lab2651rtr#conf t
lab2651rtr(config)#username lab3640rtr password myChapPw


...and on the remote router:

lab3640rtr#conf t
lab3640rtr(config)#username lab2651rtr password myChapPw


Next, in the Serial 0/1 interface configurations, you will tell the routers to authenticate using CHAP (substitute the word "pap" for "chap" in the config if you would rather use PAP):

lab3640rtr(config)#int ser0/1
lab3640rtr(config-if)#ppp authentication chap


...and on the local router:

lab2651rtr(config)#int serial 0/1
lab2651rtr(config-if)#ppp authentication chap


...and that's it!

Note 1: No joke about using the "reload in 30" before making config changes to the management interfaces on a remote router. It can be the difference between being the hero of the day and the idiot who had the misfortune to execute a career-limiting move. True story from the IT trenches: I work in Anchorage, Alaska, but manage network devices in Bethel, Alaska, 500 miles to the west (and there are no roads to Bethel from Anchorage -- it's a one hour flight via Alaska Airlines if you have to go in person). One day, I was working on my LAN router/firewall in Bethel, and fortunately, I heard that little voice inside my head telling me to run the "/sbin/shutdown -r +15 &" command (it's a Linux-based router, but that's the equivalent of Cisco's "reload in 15" command). I did, even though I was sure what I was going to do wouldn't lock me out of the router. I started making changes, and when I restarted the network interfaces, I lost my SSH connection to the router. I tried to create a new SSH session, but no joy. I tried to ping the router...nothing. I even ran "nmap -sP" just to make sure it was really off-line, but I already knew it would be (and it was). About two minutes later, my boss hollers at me from his office, "I think we just lost the Bethel router!" I calmly replied, "Yep, but it should be back in...<...checks watch...>...maybe ten minutes." I explained what happened, and he just said, "Let me know when it's back on-line." It's never good to take a LAN/WAN router off-line in the middle of the business day without arranging a scheduled outage, but, well, (*cough*) excrement occurs sometimes. However, had I not had the foresight ("luck") to tell the router reboot itself in fifteen minutes before I started working on it, I would have been in a much less comfortable position when my boss asked about the router being off-line.

Note 2: Notice how I made changes to the remote router before making changes to the local router every time? That's not by coincidence :) I lost my connection to the remote router when I removed HDLC encapsulation and added PPP encapsulation. If I had made the changes to lab2651rtr first, I would not have been able to reach lab3640rtr to make the changes that would restore the connection. It's obvious in hindsight, but maybe not so obvious the first time you are making changes in the middle of the night so as to not take users off-line during the business day. Yep, been there and done that, too :)

Note 3: Extra-credit: want to make sure that PPP really is doing what you think it's doing? Delete the "username lab3640rtr password myChapPw" from the config, then shut/no shut the interface, and run "sho ip int brief". You should see the hardware up and the line protocol down on the serial interface, indicating that there is a misconfiguration on the layer-2 protocols you are using on the serial interface.