This was one of my favorite scenarios thus far. It was a kick in the tail, but I learned a lot, plus solidified some concepts I’d been introduced to in earlier practice labs.
A major challenges of this lab was that the frame-relay cloud contained mismatched link-types. One side point-to-point, the other side multipoint. One side physical, the other point-to-point, etc. Now you might be thinking, “How hard can it be to configure frame-relay? Slap on your interfaces and DLCI statements and off you go! Stop being such a baby…” The issue comes with inverse-arp, the mechanism frame-relay uses to know what PVC to use to deliver a particular packet. Just like ethernet puts an ARP on the wire to know what destination MAC to put in the header that will frame an IP packet, frame-relay needs to know layer 2 information. How inverse-arp behaves varies among frame-relay network types. So when you mix ‘n’ match your network types, you end up with odd connectivity issues. Simple solution – you disable inverse-arp and use frame-relay map statements on your interfaces. That way, you rely on hard facts to forward your frames – inverse-arp working or not working is no longer an issue.
In this scenario, inverse-arp killed me. I was long past configuring the frame-cloud, and I had 100% connectivity on every link. Everyone could ping everyone else. The sun was shining. A rainbow was in the sky. A fawn was nibbling grass outside my window. All was peace and light. Right up until I needed to reboot my frame-relay switch because of an unrelated problem. When the frame switch came back up, the sun was hidden behind ominous clouds, the rainbow was long gone, and the fawn had been shot dead. I had nothing left of my frame connectivity. Nothing at all. The problem? Inverse-arp. I’d been relying on inverse-arp to make the frame links work. When I rebooted the frame switch, all my cached inverse arp entries were removed. And when the frame switch came back up, inverse arp wasn’t getting the job done anymore. Why it had worked earlier, and then failed to work later, I’m not entirely sure without digging through my CCIE prep book, which had a great chapter on exactly this problem. But I do know that as soon as I disabled inverse-arp and manually mapped my IPs to DLCIs, the sun came back out, the rainbow hoisted itself skyward, and the fawn shook off the bullet like nothing had happened.
There were a number of other challenges aside from frame-relay. Here’s the highlights.
- Configure IOS DHCP server to serve a specific address to a specific host. Strictly speaking, this is NOT what the scenario called for. But it’s how I interpreted the task. The scenario really just wanted you to build a boring old scope and exclude all addresses but one, allowing the only other device on the link (a router) to be served that address. But I actually set up DHCP server a bit fancier, using a manual binding. Here’s the IOS code I used to create the manual binding on router R6, to serve address 22.214.171.124 to client R1.
ip dhcp pool ROUTER1
host 126.96.36.199 255.255.255.0
You might be wondering where I got that crazy “client-identifier” string. If you’re an old-school DHCP admin, you reserve addresses for specific hosts based on the MAC address, right? Well, it’s a little different in IOS-land. Cisco.com tells you to figure out the client-identifier by running a debug.
So here’s the log entries you see from a “debug ip dhcp server packet” when R1 comes on the wire looking for an address. This shows a successful lease event; before I had the correct client-identifier in the IOS code above, the lease request kept failing over and over. But I could still copy ‘n’ paste the client identifier from the debug to get it into my code.
*May 18 12:23:17.901: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d30.3030.652e.3833.3038.2e31.3237.302d.4661.302f.302e.3136 on interface FastEthernet0/0.16.
*May 18 12:23:17.901: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.3030.652e.3833.3038.2e31.3237.302d.4661.302f.302e.3136 (188.8.131.52).
*May 18 12:23:17.901: DHCPD: broadcasting BOOTREPLY to client 000e.8308.1270.
*May 18 12:23:17.905: DHCPD: DHCPREQUEST received from client 0063.6973.636f.2d30.3030.652e.3833.3038.2e31.3237.302d.4661.302f.302e.3136.
*May 18 12:23:17.905: DHCPD: No default domain to append – abort update
*May 18 12:23:17.905: DHCPD: Sending DHCPACK to client 0063.6973.636f.2d30.3030.652e.3833.3038.2e31.3237.302d.4661.302f.302e.3136 (184.108.40.206).
*May 18 12:23:17.905: DHCPD: broadcasting BOOTREPLY to client 000e.8308.1270.
- What do you do on an OSPF ethernet network when you’ve got 3 routers (R1, R2 and R3) in the same VLAN, but R1 & R3 can talk only R2? R1 can talk to R2, and R3 can talk to R2, but R1 can’t talk to R3. The default OSPF network type for an ethernet network is broadcast. So when R1 learns a route that originated from R3, he gets a next-hop of R3, right? But he can’t forward to R3 because he can’t talk to R3 (because of “switchport protected” in case you were wondering). So therein is the problem. How to resolve? Change the OSPF network type from broadcast to point-to-multipoint instead. OSPF point-to-multipoint does not assume a fully-meshed environment, and so next-hop attributes are always of the advertising router, not necessarily the originating router on the segment. In this example, R3 would advertise to R2. R2 would in turn advertise to R1. R1 would get R2 as a next-hop instead of R3, now that we’ve changed the OSPF network type from broadcast to point-t0-multipoint.
More in the next post…