evilrouters.net

From eWeek’s article entitled “Cisco, HP Clash over Networking Equipment Pricing”:

HP is looking to focus the debate around its networking equipment competition with Cisco around price.

Since they can’t compete on quality, that only makes sense.

Soderlund also said that HP ProCurve is looking to expand into the enterprise. HP ProCurve has a traditionally strong presence at the edge of the network, but HP is looking to move closer to the enterprise.

Unfortunately, I let HP “move closer”. I wish I hadn’t. They’re fine at the edge, but don’t let them “move closer” than that.

About this time last year, we spent six figures for new gear for one of our buildings. If I had been able to get Cisco gear for the same price as the HP gear (as the article seems to allude to), well, you know…

Personally, I can’t wait to get my hands on a Juniper EX4200. We have a “shovel ready” building construction project and $20 million. While purchasing gear for the new building is still a little ways off, I feel it is my duty as an employee to properly evaluate all the options and make the best recommendation I can.

That reminds me, I need to call the Juniper Sales Manager…

In case you haven’t been paying attention lately, Microsoft has recently released a couple of security advisories: 972890 and 973472.

Both of them are bad news — unpatched vulnerabilities allowing remote code execution. Microsoft has also stated in each of the security advisories:

We are aware of attacks attempting to exploit the vulnerability.

That’s bad news. At this time I’m writing this, the Internet Storm Center is already reporting more than two million infections in China alone.

While there are currently no patches, Microsoft has published workarounds for these issues. They involve setting a grand total of 47 killbits of Class Identifiers. This might be okay if you have only one PC and a couple hours to kill. For those of us who work in large organizations with hundreds or thousands of PCs, that’s just not feasible.

I have posted two administrative templates that can be used in group policy objects (GPOs) to automate this. They can be downloaded here:

• Administrative template for MS 972890
• Administrative template for MS 973472

For those who may not be used to using their own administrative templates to push out registry settings like this, I’ve recorded a video for you. I hope it’s helpful!

• If your screen isn’t “wide” enough, you can watch the video here instead.

A couple hours ago, Jeremy Stretch posted an article entitled “Quick and dirty packet capture data extraction” in which he shows how one can extract a JPEG image from a packet capture containing the HTTP stream.

Stretch’s method uses “foremost” to recover the original file which works, but… there’s an even quicker way to do it. Actually, just like with Perl, TMTOWTDI.

I made two videos showing how to extract files from data streams within Wireshark. Instead of embedding them in this post, I’m linking to them instead as they are quite large (resolution wise).

• Video 1: Extracting objects from HTTP streams (shows how to extract the same JPEG from the same capture)
• Video 2: Extracting a PDF from an HTTP stream (shows how to extract a PDF file from a different capture)

Hopefully this will be helpful to some others, it definitely has been to me. Thanks to Jeremy Stretch for the idea, and the guys who taught my SANS Comprehensive Packet Analysis (SEC 556) class for originally showing me how to do it!

I got an e-mail recently from a reader who asked me about how to set up MD5 authentication between a pair of BGP peers, so I thought I’d do a quick write-up and example.

Setting up MD5 authentication is really simple. For our example, we’ll use a pair of routers connected over their serial 0/0 interfaces:

In addition to the addressing information in the diagram:

• we’ll configure R5’s loopback 0 interface with IP address 5.5.5.5/24,
• we’ll configure R7’s loopback 0 interface with IP address 7.7.7.7/24,
• we’ll advertise both of those networks in BGP,
• R5 is in AS 65005 and R7 is in AS 65007, and
• we’ll use a password of “8F3NHBrisX”.

This is nearly identical to a previous write-up, “Configuring Basic BGP“, with the authentication added in.

First, let’s configure the loopback 0 interfaces:

R5# configure terminal
R5(config)# interface loopback 0
R5(config-if)# ip address 5.5.5.5 255.255.255.0

R7# configure terminal
R7(config)# interface loopback 0
R7(config-if)# ip address 7.7.7.7 255.255.255.0

Now bring up the connection between R5 and R7:

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(config-if)# interface serial 0/0
R7(config-if)# ip address 172.16.57.7 255.255.255.0
R7(config-if)# no shutdown

Make sure we have connectivity:

R5(config-if)# do ping 172.16.57.7

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

Now we can begin configuring BGP. R5 will be in AS 65005, advertise the 5.5.5.0/24 network, and peer with 172.16.57.7 (AS 65007) using our password “8F3NHBrisX”:

R5(config-if)# router bgp 65005
R5(config-router)# network 5.5.5.0 mask 255.255.255.0
R5(config-router)# neighbor 172.16.57.7 remote-as 65007
R5(config-router)# neighbor 172.16.57.7 password 8F3NHBrisX

We’ll configure R7 in a similar manner. It is in AS 65007, will advertise the 7.7.7.0/24 network, and peer with 172.16.57.5 (AS 65005) using the same password:

R7(config-if)# router bgp 65007
R7(config-router)# network 7.7.7.0 mask 255.255.255.0
R7(config-router)# neighbor 172.16.57.5 remote-as 65005
R7(config-router)# neighbor 172.16.57.5 password 8F3NHBrisX

We’ll see the BGP adjacency come up…

R7(config-router)#
*Mar  1 00:05:31.191: %BGP-5-ADJCHANGE: neighbor 172.16.57.5 Up

…and can see that we’re exchanging routes:

R7(config-router)# do show ip route bgp
     5.0.0.0/24 is subnetted, 1 subnets
B       5.5.5.0 [20/0] via 172.16.57.5, 00:01:07

We should now be able to ping loopback to loopback:

R7(config-router)# do ping 5.5.5.5 source 7.7.7.7

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

Here’s the whole thing, from start to finish:

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):

Now that we have RIP authentication working, let’s take a look at how we can use the “distribute-list” to suppress network advertisements.

In this lab, we have three routers. R1 and R2 are connected via their serial 0/0 interfaces, and R2 and R3 are connected over their fast ethernet 0/1 interfaces:

R1 will have four loopback interfaces that we’ll use to simulate connected networks:

• 10.1.1.1/24
• 10.1.2.1/24
• 10.1.3.1/24
• 10.1.4.1/24

We’ll just use s0/0 and fa0/1 on R2 and fa0/1 on R3.

Let’s bring up R1 and R2’s serial interfaces…

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

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

…and the fast ethernet interfaces on R2 and R3…

R2(config-if)# interface fastethernet 0/1
R2(config-if)# ip address 172.16.23.2 255.255.255.0
R2(config-if)# no shutdown

R3# configure terminal
R3(config)# interface fastethernet 0/1
R3(config-if)# ip address 172.16.23.3 255.255.255.0
R3(config-if)# no shutdown

On R2, let’s verify we can ping both R1 and R3:

R2(config-if)# do ping 172.16.12.1

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

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

Excellent, now let’s bring up those four loopback interfaces on R1:

R1(config-if)# interface loopback 1
R1(config-if)# ip address 10.1.1.1 255.255.255.0
R1(config-if)# interface loopback 2
R1(config-if)# ip address 10.1.2.1 255.255.255.0
R1(config-if)# interface loopback 3
R1(config-if)# ip address 10.1.3.1 255.255.255.0
R1(config-if)# interface loopback 4
R1(config-if)# ip address 10.1.4.1 255.255.255.0

Let’s go ahead and configure RIP (version 2) on R2 and R3:

R2(config-if)# router rip
R2(config-router)# version 2
R2(config-router)# no auto-summary
R2(config-router)# network 172.16.0.0

R3(config-if)# router rip
R3(config-router)# version 2
R3(config-router)# no auto-summary
R3(config-router)# network 172.16.0.0

Let’s take a look at R3’s RIP routing table before we go any further:

R3(config-router)# do sh ip route rip
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.12.0 [120/1] via 172.16.23.2, 00:00:05, FastEthernet0/1

As you can see, we’re receiving the route for 172.16.12.0/24 from R2. Let’s configure RIP on R1 now:

R1(config-if)# router rip
R1(config-router)# version 2
R1(config-router)# no auto-summary
R1(config-router)# network 172.16.0.0
R1(config-router)# network 10.0.0.0

Now we should see something like this on R3:

R3(config-router)# do sh ip route rip
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.12.0 [120/1] via 172.16.23.2, 00:00:13, FastEthernet0/1
     10.0.0.0/24 is subnetted, 4 subnets
R       10.1.3.0 [120/2] via 172.16.23.2, 00:00:13, FastEthernet0/1
R       10.1.2.0 [120/2] via 172.16.23.2, 00:00:13, FastEthernet0/1
R       10.1.1.0 [120/2] via 172.16.23.2, 00:00:13, FastEthernet0/1
R       10.1.4.0 [120/2] via 172.16.23.2, 00:00:13, FastEthernet0/1

Now let’s say that, for whatever reason, we:

• do want R1 to advertise all the 10.1.x.0/24 networks to R2, but
• don’t want R3 to receive the route for 10.1.3.0/24

How would we accomplish that? “distribute-list out”, of course!

Okay, so the first thing we need to do is create an access-list. Since we simply want to block 10.1.3.0/24 from being advertised, we can accomplish this fairly easily:

R2(config-router)# exit
R2(config)# access-list 3 deny 10.1.3.0 0.0.0.255
R2(config)# access-list 3 permit any

Here, our access list just deny’s the 10.1.3.0/24 network and allows all others (note that we could use prefix-lists, too). Now we need to tell R2 to suppress the affected networks from being advertised:

R2(config)# router rip
R2(config-router)# distribute-list 3 out

Easy, right!? Let’s take a quick look at R3’s routes again:

R3(config-router)# do sh ip route rip
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.12.0 [120/1] via 172.16.23.2, 00:00:09, FastEthernet0/1
     10.0.0.0/24 is subnetted, 4 subnets
R       10.1.3.0 [120/2] via 172.16.23.2, 00:00:36, FastEthernet0/1
R       10.1.2.0 [120/2] via 172.16.23.2, 00:00:09, FastEthernet0/1
R       10.1.1.0 [120/2] via 172.16.23.2, 00:00:09, FastEthernet0/1
R       10.1.4.0 [120/2] via 172.16.23.2, 00:00:09, FastEthernet0/1

Look at the route for 10.1.3.0/24. Note that it’s been 36 seconds since R3 received an update for this network. Let’s give it a few minutes (four, by default) for the “flush” timer to expire, then check out R3’s routes again:

R3(config-router)# do sh ip route rip
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.12.0 [120/1] via 172.16.23.2, 00:00:00, FastEthernet0/1
     10.0.0.0/24 is subnetted, 3 subnets
R       10.1.2.0 [120/2] via 172.16.23.2, 00:00:00, FastEthernet0/1
R       10.1.1.0 [120/2] via 172.16.23.2, 00:00:00, FastEthernet0/1
R       10.1.4.0 [120/2] via 172.16.23.2, 00:00:00, FastEthernet0/1

See that the route for 10.1.3.0/24 has disappeared? Is it still on R2? It certainly is:

R2(config-router)# do sh ip route rip
     10.0.0.0/24 is subnetted, 4 subnets
R       10.1.3.0 [120/1] via 172.16.12.1, 00:00:12, Serial0/0
R       10.1.2.0 [120/1] via 172.16.12.1, 00:00:12, Serial0/0
R       10.1.1.0 [120/1] via 172.16.12.1, 00:00:12, Serial0/0
R       10.1.4.0 [120/1] via 172.16.12.1, 00:00:12, Serial0/0

It seems that our distribute-list is doing the job we wanted it to do. Just for good measure, let’s make sure that we can ping 10.1.3.1 from R2, but not from R3:

R2(config-router)# do ping 10.1.3.1

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

R3(config-router)# do ping 10.1.3.1

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

All of the other 10.1.x.1 addresses are, of course, still reachable from R3:

R3(config-router)# do ping 10.1.1.1

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

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

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

Note that there’s also a “distribute-list in” command that we could have used on R3 instead of “distribute-list out” on R2. If, for example, there was another interface on R2, we may not have wanted to filter out the updates going out that interface. In that case, we would have two options: we could use “distribute-list in” on R3, or we could have specified an interface with “distribute-list out”, such as this:

R2(config-router)# no distribute-list 3 out
R2(config-router)# distribute-list 3 out fastethernet 0/1

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!