evilrouters.net

Here’s a fine example of that wonderful HP ProCurve engineering and quality control I’ve grown intimately familiar with:

The following problems were resolved in release K.13.71.

…

IP Communication (PR_0000044004) – Switches running software versions K.13.65 - K.13.68 may experience a resource leak in ICMP that eventually causes loss of IP communication with the following symptoms.

• The switch will stop routing traffic for hosts for which it provides gateway services.
• All dynamic routing protocols stop functioning. The switch will stop sending routing protocol packets, and will not process incoming routing protocol packets sent from its neighbors.
• In-band network management stops functioning. The switch will become inaccessible via Telnet, SSH, WEB, and TFTP.
• Console management may become very sluggish and may appear to be non-responsive.
• Output from the CLI command show ip route will be corrupted.
• A reboot is required to clear up the symptoms.

BUT AT LEAST WE SAVED SOME MONEY!

(Note: Yes, I have been bit by this bug.)

Lately I’ve become interested in MPLS and, unfortunately, have stopped studying what I should be studying and started playing around with MPLS instead. One thing that just fascinates me is AToM, or Any Transport over MPLS. From Cisco:

“Any Transport over MPLS (AToM) is Cisco’s solution for transporting Layer 2 packets over an IP/MPLS backbone.”

In a nutshell, AToM allows us to transport a wide variety of layer 2 traffic (HDLC, PPP, Frame Relay, ATM, Ethernet, …) over an existing IP/MPLS backbone.

To demonstrate, consider the following topology:

In the topology, the P, PE1, and PE2 routers make up the service provider’s IP/MPLS backbone. P, PE1, and PE2 belong to us, the service provider, and CE1 and CE2 belong to a customer of ours. The video will show how we can provide the customer with a 256k serial (HDLC) connection over our IP/MPLS backbone. The raw HDLC frames received on the serial 1/0 interfaces of PE1 and PE2 are encapsulated in MPLS and sent over the backbone to the remote PE router, where they are decapsulated and sent back out the customer-facing serial connection.

Here’s a video demonstration so you can see just how cool this is:

I made a quick video showing how to configure PPP over frame-relay. Well, I went a bit farther than that. Here’s the topology:

First, we create two loopbacks on each router, then create a PPP connection between R1 and R3 and another between R1 and R4. Just for fun, we then throw OSPF into the mix, advertising all networks, and verify that we can ping throughout the network.

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!

Let’s continue on from yesterday’s lab, “Configuring Basic OSPF“. We’ve had a new requirement added to our original design: authenticated OSPF.

Our security team has decided that it is a potential security risk to run unauthenticated OSPF across our network backbone and have asked us to implement a secure method of sending OSPF updates.

OSPF authentication comes in two forms: plain-text and MD5. Because a “secure method” was specified, we have to use MD5 authentication in our environment (plain-text is not “secure”).

Using “pwgen” on an Ubuntu Linux box (“sudo apt-get install pwgen”), I came up with a random key of “xooph8MuBaeph5ee”. This is the authentication key I’ll use for OSPF. You are, of course, free to use something else (and encouraged to do so!).

Since we already have an environment up and running (see the “Configuring Basic OSPF” lab), we just need to add OSPF authentication to our configs and then verify proper operation. Let’s get started.

The actual configuration to enable OSPF authentication is pretty simple. There’s a quick two-part process: 1) create our authentication key (per interface) and 2) tell OSPF to use this authentication key. We’ll knock them both out at once on each router:

ISP# configure terminal
ISP(config)# interface fastethernet 0/0
ISP(config-if)# ip ospf message-digest-key 1 md5 xooph8MuBaeph5ee
ISP(config-if)# router ospf 1
ISP(config-router)# area 0 authentication message-digest 
ISP(config-router)# end
ISP#

Shortly after entering the above configuration, you should have noticed that both of your adjacencies (to Remote1 and Remote2) went from “FULL” to “DOWN”. This is because the ISP router is now sending authenticated OSPF updates and is expecting to receive them as well. Let’s configure the Remote1 router:

REMOTE1# configure terminal
REMOTE1(config)# interface fastethernet 0/0
REMOTE1(config-if)# ip ospf message-digest-key 1 md5 xooph8MuBaeph5ee
REMOTE1(config-if)# router ospf 1
REMOTE1(config-router)# area 0 authentication message-digest 
REMOTE1(config-router)# end
REMOTE1#

What we see on Remote1 is a bit different. After entering the configuration, we should notice two things. First, the adjacency with Remote2 will go down (for the same reasons as with ISP router above). In addition, we should see the adjacency with the ISP router come back up as both are now sending (and expecting to receive) authenticated updates.

If we run “show ip ospf neighbor” on each router, we should see that ISP and Remote1 have an adjacency formed but that Remote2 does not have any adjacencies. Let’s verify this:

ISP# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.3      254   FULL/BDR        00:00:36    10.10.10.3      FastEthernet0/0
ISP#

REMOTE1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.1      255   FULL/DR         00:00:32    10.10.10.1      FastEthernet0/0
REMOTE1#

REMOTE2# show ip ospf neighbor

REMOTE2#

All we need to do to get all of our adjacencies back up is to configure OSPF authentication on Remote2 just like we did the other two routers. We should then see our adjacencies form again:

REMOTE2# configure terminal
REMOTE2(config)# interface fastethernet 0/0
REMOTE2(config-if)# ip ospf message-digest-key 1 md5 xooph8MuBaeph5ee
REMOTE2(config-if)# router ospf 1
REMOTE2(config-router)# area 0 authentication message-digest
REMOTE2(config-router)# end
REMOTE2#

And, indeed, we’ll see the adjacencies form. By looking at the output of “show ip route” we can verify convergence, but how can be know that authentication is actually being used?

Let’s run a “debug ip ospf adj” on ISP router and take a look at the output:

ISP# debug ip ospf adj
OSPF adjacency events debugging is on
ISP#
*Mar  1 00:28:18.055: OSPF: Send with youngest Key 1
ISP#
*Mar  1 00:28:28.055: OSPF: Send with youngest Key 1
ISP#
*Mar  1 00:28:38.055: OSPF: Send with youngest Key 1
ISP#
*Mar  1 00:28:48.055: OSPF: Send with youngest Key 1
ISP#undebug all
All possible debugging has been turned off
ISP#

Success! We’ve now added authentication to our OSPF updates which will make our security team happy — and now they owe us a beer!