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 22 – Multipoint GRE with NHRP + Strategy Ramblings + rotary + autocommand

1,047 Words. Plan about 7 minute(s) to read this.

Here’s my tech highlights for NetMasterClass.com DOiT Volume 2 Scenario 22. As always, I don’t blog about every single detail I could. Due to lack of time or sheer laziness, I don’t cover every topic from a scenario that I might. If you are also doing these scenarios and wish to add your own insights, please register on the blog so that you can post your comments.

  • In my lab strategy, I have combined router serial link configuration with ethernet link configuration. This way, I’m doing one less router login when getting that initial layer 1/2 topology built. I’m comfortable enough with the serial configurations that I don’t need to treat it as a separate task anymore. Now I just built out all the router interfaces no matter what they are in one big task. The follow-up step is to provision the switch interfaces and trunking. Once I’ve configured all the router links and followed up with the switch links, then I do link checks, and fix whatever issues show up. I think turning up all the links in one step, rather then doing the serial links then the ethernet links, has saved me about 15 minutes.
  • OSPF adjacencies will not form across secondary IP addresses. Check out the “usage guidelines” section for the OSPF network area command: “For OSPF to operate on the interface, the primary address of the interface must be covered by the network area command. If the network area command covers only the secondary address, it will not enable OSPF over that interface.” That was a new discovery for me doing this scenario. I assumed a secondary address was the answer the way the OSPF task read, essentially to create a new 135.15.10.0/24 network that ran in conjunction with the existing 135.15.20.0/24 network, and then run OSPF across the 135.15.10.0/24 network. And you couldn’t solve it with bridging, if you were thinking of some sort of dual-VLAN IRB arrangement <shudder>. The answer was to create a multipoint GRE tunnel using NHRP to get from one point to another, then run OSPF through the multipoint tunnel. Here’s a look at the code to create this.

    R4
    conf t
    !
    interface Fa0/0
    ip address 135.15.20.4 255.255.255.0
    exit
    !
    interface Tunnel10
    ip address 135.15.10.4 255.255.255.0
    no ip redirects
    ip mtu 1500
    ip nhrp map 135.15.10.5 135.15.20.5
    ip nhrp map multicast 135.15.20.5
    ip nhrp map 135.15.10.7 135.15.20.7
    ip nhrp map multicast 135.15.20.7
    ip nhrp network-id 10
    tunnel source FastEthernet0/0
    tunnel mode gre multipoint
    tunnel key 10
    exit
    !
    exit
    !
    wri mem

    R5
    conf t
    !
    interface Fa0/0
    ip address 135.15.20.5 255.255.255.0
    exit
    !
    interface Tunnel10
    ip address 135.15.10.5 255.255.255.0
    no ip redirects
    ip mtu 1500
    ip nhrp map 135.15.10.4 135.15.20.4
    ip nhrp map multicast 135.15.20.4
    ip nhrp map 135.15.10.7 135.15.20.7
    ip nhrp map multicast 135.15.20.7
    ip nhrp network-id 10
    tunnel source FastEthernet0/0
    tunnel mode gre multipoint
    tunnel key 10
    exit
    !
    exit
    !
    wri mem

    FRS
    conf t
    !
    interface Fa2/0
    ip address 135.15.20.7 255.255.255.0
    exit
    !
    interface Tunnel10
    ip address 135.15.10.7 255.255.255.0
    no ip redirects
    ip mtu 1500
    ip nhrp map 135.15.10.4 135.15.20.4
    ip nhrp map multicast 135.15.20.4
    ip nhrp map 135.15.10.5 135.15.20.5
    ip nhrp map multicast 135.15.20.5
    ip nhrp network-id 10
    tunnel source FastEthernet2/0
    tunnel mode gre multipoint
    tunnel key 10
    exit
    !
    exit
    !
    wri mem

  • The redistribution was a little nuts. On 3 different routers, you were required to perform mutual distribution into 3 different protocols – RIP, OSPF, and EIGRP. Plus, some other routers were doing 2 protocol mutual redistribution. In fact, there were more routers doing redistribution than were not. My strategy was fine with the redistribution. I went the direction of making access lists of routes native to IGP domains, then using those lists to define what I would redistribute where. I only had an issue with one specific loopback address. I killed a LOT of time getting that one loopback address to stabilize in the routing topology. I find that when my carefully crafted solutions don’t work as planned, I go into shotgun-mode, just blasting away at the problem, hoping this trick or that will fix it. I really have to stop that. In hindsight, I know that if I’d thought more carefully (and QUICKLY) about the problem I was having, I would have been able to fix it in maybe half the time it took. Maybe less.
  • BGP was simple, but I did have some trouble with a link between 2 AS’s, where a forwarding loop cropped up. I was eventually able to resolve this. Here’s what’s sad though: it took me about 15 minutes before I used “traceroute” to see where the forwarding problem was. Before the bold thought of “traceroute” popped into my head, I was hopping from router to router, looking at the routing tables manually to see where each hop was forwarding. Can you believe it? Duh.
  • There was a traffic control task, where traffic from a specific source to a specific destination was to be forwarded along a particular path, symmetrically. I was thinking I’d use PBR to do this – seemed logical. But then the last step of the task stated that you couldn’t make a forwarding decision based the source and destination addresses. Somehow, I misconstrued that to mean I couldn’t use PBR. I went down the road of creating a tunnel and customizing routing tables, trying to get the traffic to naturally flow via the routing tables I’d manipulated. I never quite got it working, and it was the totally wrong answer. And again, here’s what’s sad: there was a later task that gave you a HUGE hint about how to solve the problem. PBR was totally fine. PBR can make forwarding decisions based on lots of criteria other than source/destination IP. The QoS task involved marking traffic for that specific source/destination IP with IP precedence 2. If I’d caught that detail on my first read-through of the lab, I would have known that I needed to do PBR using precedence value to make the forwarding decision. Another “duh” moment.
  • The “rotary” command, when applies to a “line vty” paragraph, sets that router’s telnet daemon listening on port 3000 + the rotary number. The “autocommand” command will execute a specific command when a user connects to that particular line. In this example, R6 has configured line vty 6 to listen on telnet port 3006, authenticate the user with local credentials, and then execute a command of “telnet 135.15.102.1 3007” when a successful connection is made.

    R6#show run | s line vty 6
    line vty 6
    login local
    rotary 6
    autocommand telnet 135.15.102.1 3007
    R6#

More in the next post regarding SNMPv3 security, multicast with Anycast-RP and MSDP, and rcmd.