From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

NMC DOiT Vol.2 Scenario 2 Day 1 – Multipoint Frame Split-Horizon + Integrated Routing & Bridging (IRB)

801 Words. Plan about 5 minute(s) to read this.

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 (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

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.