evilrouters.net

Here’s a lab that might be helpful for those working towards the CCNA examination.

We have a simple topology consisting of three routers. R8 will simply be used as a host on our “internal” network and R7 will be used as our border router (the serial connection between R5 and R7 will represent our connection to the Internet):

The goal is to NAT any traffic originating on our internal network (R8) as it leaves the serial 0/0 interface on R7 on it’s way to the “Internet” (R5). Overloading (having multiple clients all NAT’d to the same IP address) is probably the most common implementation (especially for those of us who run NAT on a Cisco box at home!).

Let’s get basic connectivity working first:

R5# configure terminal
R5(config)# interface serial 0/0
R5(config-if)# ip address 172.16.57.5 255.255.255.0
R5(config-if)# no shutdown

R7# configure terminal
R7(config)# interface serial 0/0
R7(config-if)# ip address 172.16.57.7 255.255.255.0
R7(config-if)# no shutdown
R7(config-if)# interface fastethernet 0/1
R7(config-if)# ip address 172.16.78.7 255.255.255.0
R7(config-if)# no shutdown

R8# configure terminal
R8(config)# no ip routing
R8(config)# interface fastethernet 0/1
R8(config-if)# ip address 172.16.78.8 255.255.255.0
R8(config-if)# no shutdown
R8(config-if)# ip default-gateway 172.16.78.7

On R7, let’s verify we can ping both R5 and R8:

R7(config-if)# do ping 172.16.57.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.57.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R7(config-if)# do ping 172.16.78.8

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.78.8, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 1/2/4 ms

Alright, looks good. Now we can start with configuring NAT. First, let’s define our NAT inside and NAT outside interfaces (fastethernet 0/1 and serial 0/0, respectively):

R7(config-if)# interface fastethernet 0/1
R7(config-if)# ip nat inside
R7(config-if)# interface serial 0/0
R7(config-if)# ip nat outside

Next, we need to create an access-list to match the “internal” IP addresses (the ones we want to be NAT’d). In this case, our internal network is 172.168.78.0/24. Our ACL to match that network is simple:

R7(config-if)# ip access-list standard NAT
R7(config-std-nacl)# permit 172.16.78.0 0.0.0.255

Last, we’ll use the “ip nat …” command to actually instruct the router on what we want to NAT:

R7(config)# ip nat inside source list NAT interface serial 0/0 overload

This tells IOS that any packets coming in the “inside” interface (fastethernet 0/1) that are permitted by the named access-list “NAT” will have their “source” address translated to the IP address assigned to “interface serial 0/0″. In addition, NAT translations will be overloaded — that allows multiple devices inside to be translated to the same IP address.

To verify that NAT is working properly, let’s start a “debug ip icmp” on R5. Then, we’ll attempt to ping R5 from R8 and see what happens:

R5# debug ip icmp 
ICMP packet debugging is on

R8(config)# do ping 172.16.57.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.57.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

We see that our pings were successful. What did R5 see?

R5# debug ip icmp 
ICMP packet debugging is on
R5#
*Mar  1 19:07:25.603: ICMP: echo reply sent, src 172.16.57.5, dst 172.16.57.7
*Mar  1 19:07:25.611: ICMP: echo reply sent, src 172.16.57.5, dst 172.16.57.7
*Mar  1 19:07:25.615: ICMP: echo reply sent, src 172.16.57.5, dst 172.16.57.7
*Mar  1 19:07:25.619: ICMP: echo reply sent, src 172.16.57.5, dst 172.16.57.7
*Mar  1 19:07:25.623: ICMP: echo reply sent, src 172.16.57.5, dst 172.16.57.7

So R5 saw the echo requests and sent echo replies back, but notice the IP addresses. The source IP address of the echo replies is 172.16.57.5 (R5), but the destination IP address is 172.16.57.7 (R7). We can be sure that NAT is working, in part because R5 does not have a valid route to R8’s “real” IP address, 172.16.78.8:

R5# show ip route | begin Gateway
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.57.0 is directly connected, Serial0/0
R5# ping 172.16.78.8

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.78.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Be sure to check out the NAT translation table on R7, which should show a valid translation for the ICMP traffic that originated at R8:

R7(config)# do show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 172.16.57.7:0     172.16.78.8:0      172.16.57.5:0      172.16.57.5:0

Finally, we can use “debug ip nat” on R7 to see what’s happening there. Let’s turn that on, then ping R5 from R8 again:

R7# debug ip nat 
IP NAT debugging is on

R8(config)# do ping 172.16.57.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.57.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

And what do we see on R7?

R7#
*Mar  1 19:15:13.695: NAT: s=172.16.78.8->172.16.57.7, d=172.16.57.5 [5]
*Mar  1 19:15:13.699: NAT*: s=172.16.57.5, d=172.16.57.7->172.16.78.8 [5]
*Mar  1 19:15:13.703: NAT*: s=172.16.78.8->172.16.57.7, d=172.16.57.5 [6]
*Mar  1 19:15:13.707: NAT*: s=172.16.57.5, d=172.16.57.7->172.16.78.8 [6]
*Mar  1 19:15:13.707: NAT*: s=172.16.78.8->172.16.57.7, d=172.16.57.5 [7]
*Mar  1 19:15:13.711: NAT*: s=172.16.57.5, d=172.16.57.7->172.16.78.8 [7]
*Mar  1 19:15:13.715: NAT*: s=172.16.78.8->172.16.57.7, d=172.16.57.5 [8]
*Mar  1 19:15:13.715: NAT*: s=172.16.57.5, d=172.16.57.7->172.16.78.8 [8]
*Mar  1 19:15:13.719: NAT*: s=172.16.78.8->172.16.57.7, d=172.16.57.5 [9]
R7#
*Mar  1 19:15:13.723: NAT*: s=172.16.57.5, d=172.16.57.7->172.16.78.8 [9]
R7#

We can see that the source IP address 172.16.78.8 (R8) is being translated to 172.16.57.7 (R7’s serial 0/0 interface). Success!

Alright, we’ve finally made it to the last of the four-part series on configuring frame-relay. If you haven’t been following along, you may want to check out part one, part two, and part three before continuing.

In part four, we’ll continue on where we left off in part three. Our topology is shown here:

OSPF over frame-relay presents some unique challenges, depending on just how your frame-relay network is architected. Ours is pretty straightforward — we have a simple hub-and-spoke network (R1/R2/R3) as well as a point-to-point connection (R1/R4). We need full reachability between all of these routers, so it’s time to add in some OSPF.

NOTE: Arden Packeer, CCIE 20716 wrote up an excellent five-part series entitled “OSPF Network Types & Frame-Relay Series“. If you’re working with frame-relay and OSPF, I would highly recommend you read them. Because Arden did such a wonderful job (thanks!), I won’t bother repeating what he has already said.

In this article, we’re going to use both point-to-multipoint (R1/R2/R3) and point-to-point (R1/R4) to gain us full reachability throughout our routing domain. I’m a big fan of keeping things simple, and we can accomplish our goal with a minimum of effort.

On all routers, we’ll tell OSPF that we want all interfaces to participate in OSPF (in area 0). On R1, R2, and R3’s serial 0/0 interfaces, we’ll also need to specify that we’re using the point-to-multipoint network type. Let’s configure the routers, starting with R1:

R1# configure terminal
R1(config-router)# interface serial 0/0
R1(config-if)# ip ospf network point-to-multipoint
R1(config)# router ospf 1
R1(config-router)# network 0.0.0.0 255.255.255.255 area 0

R2# configure terminal
R2(config-router)# interface serial 0/0
R2(config-if)# ip ospf network point-to-multipoint
R2(config)# router ospf 1
R2(config-router)# network 0.0.0.0 255.255.255.255 area 0

R3# configure terminal
R3(config-router)# interface serial 0/0
R3(config-if)# ip ospf network point-to-multipoint
R3(config)# router ospf 1
R3(config-router)# network 0.0.0.0 255.255.255.255 area 0

After giving time for the adjacencies to come up, we can verify proper operation on R1:

R1(config-if)# do show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.123.3      0   FULL/  -        00:01:59    172.16.123.3    Serial0/0
172.16.123.2      0   FULL/  -        00:01:34    172.16.123.2    Serial0/0

Now, let’s configure OSPF on R4:

R4# configure terminal
R4(config)# router ospf 1
R4(config-router)# network 0.0.0.0 255.255.255.255 area 0

On R4, we should now see routes to all other devices and networks:

R4(config-router)# do show ip route | begin Gateway
Gateway of last resort is not set

     172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       172.16.14.0/24 is directly connected, Serial0/0.14
O       172.16.123.3/32 [110/128] via 172.16.14.1, 00:00:42, Serial0/0.14
O       172.16.123.2/32 [110/128] via 172.16.14.1, 00:00:42, Serial0/0.14
O       172.16.123.1/32 [110/64] via 172.16.14.1, 00:00:42, Serial0/0.14

Let’s verify we have full reachability:

R4(config-router)# do ping 172.16.123.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
R4(config-router)# do ping 172.16.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms
R4(config-router)# do ping 172.16.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms

Success!

Okay, after much delay here’s part 3 of the “Configuring Frame-Relay” series. In part 3, we’ll combine what we’ve learned from part one and part two and work with this topology:

As you can see from the diagram, we’ll be using the physical serial 0/0 interfaces to connect R1, R2, and R3. In addition, we’ve added a new router, R4, to the diagram. R1 and R4 will be connected over a point-to-point subinterface (serial 0/0.14). The purpose of this part three is to show how we can use both the physical interface and a point-to-point subinterface at the same time (we could also add a point-to-multipoint subinterface if we wanted, but we’ll save that for later).

The initial configurations for R1, R2, and R3 will be identical to what we saw in part one. If you haven’t already viewed the video in part one, I recommend you do that now.

For the sake of completeness, here are the initial configurations for the hub-and-spoke portion of our frame relay network:

R1# configure terminal
R1(config)# interface serial 0/0
R1(config-if)# encapsulation frame-relay
R1(config-if)# no frame-relay inverse-arp
R1(config-if)# ip address 172.16.123.1 255.255.255.0
R1(config-if)# frame-relay map ip 172.16.123.2 102 broadcast
R1(config-if)# frame-relay map ip 172.16.123.3 103 broadcast
R1(config-if)# no shutdown

R2# configure terminal
R2(config)# interface serial 0/0
R2(config-if)# encapsulation frame-relay
R2(config-if)# no frame-relay inverse-arp
R2(config-if)# ip address 172.16.123.2 255.255.255.0
R2(config-if)# frame-relay map ip 172.16.123.1 201 broadcast
R2(config-if)# frame-relay map ip 172.16.123.3 201
R2(config-if)# no shutdown

R3# configure terminal
R3(config)# interface serial 0/0
R3(config-if)# encapsulation frame-relay
R3(config-if)# no frame-relay inverse-arp
R3(config-if)# ip address 172.16.123.3 255.255.255.0
R3(config-if)# frame-relay map ip 172.16.123.1 301 broadcast
R3(config-if)# frame-relay map ip 172.16.123.2 301
R3(config-if)# no shutdown

With this portion up and running (make sure to verify reachability!), we can get to work bringing up the point-to-point connection between R1 and R4. Let’s start with R1. The encapsulation on the physical interface is already configured, so we can skip that part and jump straight in:

R1(config-if)# interface serial 0/0.14 point-to-point
R1(config-subif)# frame-relay interface-dlci 104
R1(config-fr-dlci)# ip address 172.16.14.1 255.255.255.0

Easy enough, right? Now let’s set up R4:

R4# configure terminal
R4(config)# interface serial 0/0
R4(config-if)# encapsulation frame-relay
R4(config-if)# no shutdown
R4(config-if)# interface serial 0/0.14 point-to-point
R4(config-subif)# frame-relay interface-dlci 401
R4(config-fr-dlci)# ip address 172.16.14.4 255.255.255.0

Since we’ve already saw the video in part two, this is a piece of cake as well. At this point, we should be able to ping R1 from R4 and vice versa. Verify:

R4(config-subif)# do ping 172.16.14.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.14.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

R1(config-subif)# do ping 172.16.14.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Success! Our configuration is now complete. Here’s what the routing table looks like on R1:

R1(config-subif)# do show ip route | begin Gateway
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 2 subnets
C       172.16.14.0 is directly connected, Serial0/0.14
C       172.16.123.0 is directly connected, Serial0/0

Note that we don’t have “full reachability”, however. While R1 can talk to all the other routers, R2 and R3 and effectively segmented from R4 — they don’t have a route back and forth. We’ll address that in part four, where we’ll continue on and configure OSPF throughout our frame-relay network.

Here, for your viewing pleasure, is a video walking through the complete configuration from start to finish (without narration this time):

Here’s another quick little lab, using the same topology as last time:

Two routers, R1 and R2, directly connected via their serial 0/0 interfaces. In the previous lab, we were using RIP. This time we’ll use EIGRP and authenticate our routing updates.

Basic configuration

Just like last time, let’s bring up a loopback interface, our serial 0/0 interfaces and verify connectivity:

R1# configure terminal
R1(config)# interface loopback 0
R1(config-if)# ip address 1.1.1.1 255.255.255.255
R1(config-if)# interface serial 0/0
R1(config-if)# ip address 172.16.12.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# end

R2# configure terminal
R2(config)# interface loopback 0
R2(config-if)# ip address 2.2.2.2 255.255.255.255
R2(config-if)# interface serial 0/0
R2(config-if)# ip address 172.16.12.2 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# end

R1# ping 172.16.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/18/36 ms
R1#

Configure EIGRP

Now that we have connectivity, let’s get EIGRP up and running on R1 and R2 (without authentication, at first). We just want to make sure they’re exchanging EIGRP routing updates at this point.

R1# configure terminal
R1(config)# router eigrp 42
R1(config-router)# no auto-summary
R1(config-router)# network 172.16.12.1 0.0.0.0
R1(config-router)# network 1.1.1.1 0.0.0.0
R1(config-router)# end

R2# configure terminal
R2(config)# router eigrp 42
R2(config-router)# no auto-summary
R2(config-router)# network 2.2.2.2 0.0.0.0
R2(config-router)# network 172.16.12.2 0.0.0.0
R2(config-router)# end

Very quickly (EIGRP is *FAST*), we should see an adjacency come up (ignore the timestamps, they’re obviously not correct!):

On R1:

*Mar  1 00:13:12.243: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is up: new adjacency

On R2:

*Mar  1 00:12:47.935: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.1 (Serial0/0) is up: new adjacency

Verify EIGRP

On R1:

R1# sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 172.16.12.2, 00:01:26, Serial0/0

On R2:

R2# sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2297856] via 172.16.12.1, 00:02:00, Serial0/0

We can see that the loopbacks are being advertised by both routers. If we want, we can ping R2’s loopback from R1’s loopback just for good measure:

R1# ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms

Configure EIGRP authentication

Now that we have full reachability and “basic” EIGRP working, it’s time to configure MD5 authentication.

Just like RIP authentication, we need to create a key chain, key identifier, and key string that will be used for authentication. We’ll use the same values as last time, except that we’ll call our key chain “EIGRP” instead of “RIP”:

R1# configure terminal
R1(config)# key chain EIGRP
R1(config-keychain)# key 1
R1(config-keychain-key)# key-string RGjtl5ANYa
R1(config-keychain-key)# end

R2# configure terminal
R2(config)# key chain EIGRP
R2(config-keychain)# key 1
R2(config-keychain-key)# key-string RGjtl5ANYa
R2(config-keychain-key)# end

We have two steps left to complete on each router: we have to specify the keychain that we want to use for authentication, then we enabled EIGRP authentication. Both of these are done in interface configuration mode under (in our case) the serial 0/0 interfaces. Let’s configure R1 first:

R1# configure terminal
R1(config)# interface serial 0/0
R1(config-if)# ip authentication key-chain eigrp 42 EIGRP
R1(config-if)#
*Mar  1 00:21:51.919: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is down: keychain changed
*Mar  1 00:21:52.567: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is up: new adjacency
R1(config-if)# ip authentication mode eigrp 42 md5
R1(config-if)# end
R1#
*Mar  1 00:22:06.083: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.2 (Serial0/0) is down: authentication mode changed

Note that our adjancency bounced right after we configured the key chain. Then, after actually enabling MD5 authentication, we see in the last log message that the adjacency went down. This is because R1 is now using MD5 authentication, but R2 has not yet been configured to do the same. Let’s run a “debug eigrp packets” and see what’s going on over there:

R2# debug eigrp packets
R2#
*Mar  1 00:24:18.751: EIGRP: Sending HELLO on Serial0/0
*Mar  1 00:24:18.755:   AS 42, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar  1 00:24:19.087: EIGRP: Serial0/0: ignored packet from 172.16.12.1, opcode = 5 (authentication off or key-chain missing)
R2# undebug all
All possible debugging has been turned off

Now let’s enable authentication on R2’s side and we should see the adjacency come right back up:

R2# configure terminal
R2(config)# interface serial 0/0
R2(config-if)# ip authentication key-chain eigrp 42 EIGRP
R2(config-if)# ip authentication mode eigrp 42 md5
R2(config-if)# end
R2#
*Mar  1 00:26:23.495: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 42: Neighbor 172.16.12.1 (Serial0/0) is up: new adjacency

Verifying EIGRP authentication

We can verify that authentication is being used using “debug eigrp packets” again:

R2# debug eigrp packets
R2#
*Mar  1 00:28:32.711: EIGRP: received packet with MD5 authentication, key id = 1
*Mar  1 00:28:32.711: EIGRP: Received HELLO on Serial0/0 nbr 172.16.12.1
*Mar  1 00:28:32.711:   AS 42, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
R2# undebug all
All possible debugging has been turned off

Looks good, let’s verify we still have full reachability:

R1# ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms

I found this post saved and realized that it had never been uploaded to the site, so here you go.

Two routers, R1 and R2, directly connected via their serial 0/0 interfaces. We want to authenticate the routing updates sent and received by these two routers. Note that we have to use RIP version 2 (RIPv2), since RIP version 1 does not support authentication.

For RIP authentication, we have two options: plain text or MD5. I would recommend never using plain-text anything, but we’ll configure both for the sake of completeness. Let’s get started:

Let’s configure a loopback interface on each router and then get our serial connection up and running:

R1# configure terminal
R1(config)# interface loopback 0
R1(config-if)# ip address 1.1.1.1 255.255.255.255
R1(config-if)# interface serial 0/0
R1(config-if)# ip address 172.16.12.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# end

R2# configure terminal
R2(config)# interface loopback 0
R2(config-if)# ip address 2.2.2.2 255.255.255.255
R2(config-if)# interface serial 0/0
R2(config-if)# ip address 172.16.12.2 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# end

Verify connectivity:

R1# ping 172.16.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/25/64 ms
R1#

Configure RIPv2

It’s back to basics time. Before we jump right into authentication, let’s get just basic RIP working and exchanging updates first:

R1# configure terminal
R1(config)# router rip
R1(config-router)# no auto-summary
R1(config-router)# version 2
R1(config-router)# network 1.0.0.0
R1(config-router)# network 172.16.0.0
R1(config-router)# end

R2# configure terminal
R2(config)# router rip
R2(config-router)# no auto-summary
R2(config-router)# version 2
R2(config-router)# network 2.0.0.0
R2(config-router)# network 172.16.0.0
R2(config-router)# end

Verify RIP

Verify that the routers are exchanging routes via RIP:

R1# sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/1] via 172.16.12.2, 00:00:02, Serial0/0

R2# sh ip route rip
     1.0.0.0/32 is subnetted, 1 subnets
R       1.1.1.1 [120/1] via 172.16.12.1, 00:00:11, Serial0/0

Excellent! Let’s create our key chain, key, and key string that we’ll use for authentication:

Configure authentication parameters

R1# configure terminal
R1(config)# key chain RIP
R1(config-keychain)# key 1
R1(config-keychain-key)# key-string RGjtl5ANYa
R1(config-keychain-key)# end

R2# configure terminal
R2(config)# key chain RIP
R2(config-keychain)# key 1
R2(config-keychain-key)# key-string RGjtl5ANYa
R2(config-keychain-key)# end

A couple of quick notes:

• The key chain name, “RIP”, is user-defined and can be whatever you want it to be. It does not need to be the same on both routers.
• The identifier number of the authentication key, “key 1″, does not need to be identical UNLESS you are using MD5 authentication.
• The key string, “key-string RGjtl5ANYa”, is the actual password. It does, of course, need to match on both sides.

The only things left to do are enable authentication on the serial 0/0 interfaces and to specify the authentication method we’re going to use. Plain text authentication is the default, and can be left out.

Configure plain-text authentication

R1# configure terminal
R1(config)# interface serial 0/0
R1(config-if)# ip rip authentication key-chain RIP
R1(config-if)# end

R2# configure terminal
R2(config)# interface serial 0/0
R2(config-if)# ip rip authentication key-chain RIP
R2(config-if)# end

Verify plain-text authentication

We can verify that authentication is enabled by using “debug ip rip”, as shown here:

R1# debug ip rip
RIP protocol debugging is on
R1#
*Mar  1 01:36:50.743: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (172.16.12.1)
*Mar  1 01:36:50.747: RIP: build update entries
*Mar  1 01:36:50.747:   1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
R1#
*Mar  1 01:37:02.695: RIP: received packet with text authentication RGjtl5ANYa
*Mar  1 01:37:02.695: RIP: received v2 update from 172.16.12.2 on Serial0/0
*Mar  1 01:37:02.695:      2.2.2.2/32 via 0.0.0.0 in 1 hops
R1#
*Mar  1 01:37:05.111: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)
*Mar  1 01:37:05.111: RIP: build update entries
*Mar  1 01:37:05.111:   2.2.2.2/32 via 0.0.0.0, metric 2, tag 0
*Mar  1 01:37:05.111:   172.16.12.0/30 via 0.0.0.0, metric 1, tag 0
*Mar  1 01:37:05.111: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of our addresses)
R1# undebug all

Note that our password (key string) is plainly visible in the received RIP updates. Not only are they visible to us, but they would be visible to any eavesdroppers on the network as well. Plain-text authentication really gets us nothing. A much better choice is MD5 authentication.

Configure and verify MD5 authentcation

With everything else in place, MD5 authentication is just one command away. In interface configuration mode, we specify the type of authentication being used with the “ip rip authentication mode …” command. It defaults to plain-text, which is why we did not need to specify it above.

Let’s set the authentication mode to MD5 on R1, then we’ll start a debug on R2 before setting MD5 authentication there as well:

R1# configure terminal
R1(config)# interface serial 0/0
R1(config-if)# ip rip authentication mode md5
R1(config-if)# end

R2# debug ip rip
RIP protocol debugging is on
R2#
*Mar  1 01:50:29.963: RIP: ignored v2 packet from 172.16.12.1 (invalid authentication)
R2# configure terminal
R2(config)# interface serial 0/0
R2(config-if)# ip rip authentication mode md5
R2(config-if)# end
R2#
*Mar  1 01:50:56.823: RIP: received packet with MD5 authentication
*Mar  1 01:50:56.827: RIP: received v2 update from 172.16.12.1 on Serial0/0
*Mar  1 01:50:56.831:      1.1.1.1/32 via 0.0.0.0 in 1 hops
R2# undebug all

In the “debug ip rip” on R2, we see that we have ignored a packet due to “invalid authentication”. This is because MD5 authentication had already been enabled on R1, but not on R2. R1 was sending MD5 authenticated updates but R2 was still configured to use plain-text authentication so it discarded the update. Once we configured MD5 authentication on R2 as well, we see that we received an update “with MD5 authentication”. Note that the authentication key is NOT visible, as opposed to when we used plain-text authentication.

RIP authentication is extremely easy to configure and there is no good reason not to use MD5 authentication, as is (hopefully) clearly visible from the exercises above.

May all your updates be secure!