Almost, but not quite as far as I’d planned to get today, in part because one of my 3745s had booted to an unexpected version of IOS. I hadn’t noticed. Everything was fine until I got to RIP routing. I had to set up RIPv2 to do unicast updates only (where you set “passive-interface default”, and then use “neighbor” statements in the “router rip” paragraph. According to my “debug ip rip” output, I had unicast RIP updates working like a champ, with no multicast updates to 220.127.116.11 (where RIPv2 multicasts to), except on one router (the hub router, naturally). That one router would see inbound RIP updates, but wasn’t sending a thing unless I took off passive-interface default, whether I had neighbor statements in the config or not. After a half-hour of poking at things and scratching the top of my balding pate, I did a “show ver” and discovered the router was running the wrong IOS. I did a “boot system flash” pointing to the correct binary and rebooted. And after that, all was well. Problem solved.
So today, I built out the frame-relay clouds (2 of them), with a mix of physical and logical interfaces, plus a mix of point-to-point and multipoint. I configured the L2/L3 interfaces on the Catalysts and routers, building 802.1q trunks, including one going to a router. I set up RIP through the frame cloud and OSPF with link-based MD5 authentication and only area 3 (no area 0). And I actually did most of this from memory, without having to peek at the answer key or cisco.com/univercd.
Surprises of the day (you know, stuff I didn’t get right):
- Split-horizon issues on the frame-relay interfaces. I have to get it through my thick skull that on multipoint frame interfaces, split-horizon is a major concern for the hub router assuming a partial mesh hub-and-spoke topology. I just sort of forget to check the routing table route by route on all participating routers once I see the IGP working. Must…break…habit…
- Split-horizon is ON by default on logical frame interfaces (meaning that the router won’t advertise routes back out he gets in).
- Split-horizon is OFF by default on physical frame interfaces (meaning that the router WILL advertise routes back out that he gets in). I noticed this today as routes that were looping out in the RIP database, with metrics greater than 16.
- So therefore, when configuring a frame network, you have to consider a few things regarding split-horizon:
- The logical multipoint frame interfaces. Split horizon is ON by default, so will you have to disable split-horizon for all needed routes to propagate? You’ll have to look at your topology and decide. If your router is a hub router, and the spokes do not have PVCs to one another, then YES, you’ll have to turn split-horizon off.
- The physical frame interfaces (which are multipoint by definition). Split-horizon is OFF by default, so will you have to enable split-horizon to prevent a routing loop? Again, it depends on the topology.
- Bridging 2 fast ethernet subinterfaces on a router. I didn’t catch the fact that on the diagram, there was the same IP address space living in 2 separate VLANs. It should have leapt off the page and slapped me up-side the head, but I didn’t catch it. Duh. Even if I’d caught it, while I would have known I needed to bridge the interfaces on the router, I wouldn’t have known how. Conceptually, it’s similar to what we do with fallback bridging on a switch, only we do it on a router. So here’s how (making a LOT of assumptions that I am actually grasping how this is working):
- “bridge 1 protocol IEEE”, which creates what is more or less a VLAN on the router.
- “bridge IRB” fires up the Integrated Routing and Bridging process.
- “interface BVI1” creates a router interface for the bridge you can assign an IP to.
- “bridge 1 route IP” instructs the router to route with the BVI interface. Normally, the router would just bridge the traffic flowing through the BVI.
- On the interfaces you wish to participate in the bridging, use “bridge-group 1”.
- Now traffic can be forwarded at layer 2 between the interfaces on the router, or routed by the layer 3 address assigned to the BVI. Ugly as a heart attack on a highway, but it works.
- Read more about a router’s ability to bridge here. Focus on the transparent bridging sections to address what I picked up from this scenario.
I just had a thought – isn’t it strange that a goodly portion of the first scenario and now the second has had to do with a switch’s ability to bridge multiple VLANs (which you generally never want to do), and a router’s ability to bridge (when what you really want a router to do is ROUTE)? Ah, well.