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 16 – Entire Class B=128.0.0.0/2 + NTP Authentication + IPv6 RIP Split-Horizon + 3550 MQC Policer

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

Another successful NetMasterClass.com DOiT completion today, this time scenario 16 in about 7 hours, 20 minutes. And it only took that long because I chose to spend over an hour on the multicast, scrutinizing mroute tables, looking at IGMP snooping output on the 3550s, and so on. If I’d just hammered out the multicast, I would have been done in 6h45m instead of 7h20m.

Like scenario 15 yesterday, this one felt “too easy”. I know I’m not that good yet. It was good practice, but nothing to blow your mind too badly if you’d been paying attention in the first 15 scenarios. And, as with every scenario, there were things I learned that I didn’t know before. As always, please feel free to register and blog your own comments if you’re also doing these scenarios. Some things that didn’t catch my attention or I’m too lazy to write up may have been significant for you. The more information that gets blogged, the smarter we all get. :) At least that’s the idea.

  • Practically every NMC scenario offers a bizarre frame-relay layout with OSPF layered on top. If you’re doing your own practice labs without a vendor, invent the most confusing, illogical frame-relay scenario you can conjure up, and then make OSPF work using any and all OSPF network types. You’ve got to know intuitively how frame-relay inverse-arp, hub-and-spoke topologies, and OSPF network types will play together.
  • Wording is important, yet again I discovered. A task told me to summarize “the entire Class B range”, which I took to mean, the entire /16 that was being used in the scenario. I’m sorry, but that’s incorrect…<buzz> – tell ’em what he would have won, Bob! <Crowd goes “awwwww”.> I would have won getting the points for that task. By “entire Class B range”, they meant 128.0.0.0/2. You know, all of it…the entire thing.
  • The BGP scenario was typical of what I’ve been seeing. Filter prefixes, use route-reflectors and confederations (both at once in this case), be aware of synchronization and next-hop issues, and force traffic to go a particular way by tweaking NLRI attributes via route-maps. I think that pretty well covers “core” BGP – the bare minimum of stuff you have to know to get by. There’s more esoterica about BGP, though…that’s the stuff that scares me. There are lots of little features that aren’t always obvious why or when you’d use them.
  • I’ve seen configuring an IOS DHCP server come up several times in the NMC scenarios. it’s easy to do, but I still have to look at Univercd for the syntax. But…I know right exactly where to find it.
  • The NTP scenario was a little weird. I had some trouble getting one device to accept the NTP traffic from the other. It was because I didn’t set up the NTP authentication correctly. The task was to make R1 be a stratum 5 NTP server. Make R2 an R1 client. Make CAT2 and R2 peer, but make sure CAT2 only accepts NTP from R2, and only if R2 authenticates. The winning code follows – take a close look at the CAT2 statements and look them up. I messed up on the “ntp trusted-key” (missing completely) and “ntp peer” statement (key parameter missing at the end).

    R1
    conf t
    !
    ntp master 5
    !
    exit
    !
    wri mem

    R2
    conf t
    !
    ntp authentication-key 220 md5 NMC16
    ntp server 160.60.101.1
    ntp source Lo102
    !
    exit
    !
    wri mem

    CAT2
    conf t
    !
    ntp authentication-key 220 md5 NMC16
    ntp authenticate
    ntp trusted-key 220
    ntp peer 160.60.102.1 key 220
    ntp access-group peer 2
    access-list 2 permit 160.60.102.1
    !
    exit
    !
    wri mem

  • To disable ipv6 RIP split-horizon, do so under the ipv6 RIP routing process paragraph. You can’t do it per interface (that I could find). It’s all or nothing. NMC points out that disabling split-horizon is generally considered to be A Very Bad Idea (although sometimes you do what you got to do). They recommend that even in a stable topology where you know it’s a non-issue, you should put inbound filters on neighbor routers so that the “no split-horizon” router doesn’t advertise a router’s routes back to it.
  • 3550 QoS – configure a rate-limiter so that traffic from a specific VLAN destined to a specific VLAN on UDP/5011 flowing inbound to CAT1 Fa0/24 doesn’t exceed 8000bps. This is accomplished with an easy-breezy MQC policer. Don’t forget to enable “mls qos” on the switch first. Behold:

    CAT1
    conf t
    !
    mls qos
    !
    ip access-list extended UDP5011
    permit udp 1.1.1.0 0.0.0.255 160.60.10.0 0.0.0.255 eq 5011
    exit
    !
    class-map match-all POLICE-THIS
    match access-group name UDP5011
    exit
    !
    policy-map POLICER
    class POLICE-THIS
    police 8000 8000 exceed-action drop
    exit
    exit
    !
    interface Fa0/24
    switchport
    switchport mode access
    switchport access vlan 100
    service-policy in POLICER
    no shut
    exit
    !
    exit
    !
    wri mem

    CAT1#show mls qos interface fa0/24 policers
    FastEthernet0/24
    policymap=POLICER
    type=Single, id=0 rate=8000, qlimit=8000, drop=1

    CAT1#

That’s all for this round. There’s certainly more I could blog, but I’m going to get set up for tomorrow. Scenario 17 awaits in the morning.