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 3 – RARP Server + Voice VLAN + CoS to DSCP Mapping + Static MAC Security

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

The last couple of days have been a bit harrowing. Sorry I haven’t been posting more, but frankly I haven’t had much time on the rack. I’ll spare you the details, but suffice it to say that 2 speaking engagements at my church over the last 2 nights, plus a middle of the night Internet cutover at one of our data centers kept me overly occupied yesterday and the day before.

Today, I managed to complete the IPv4 route-check on all routers, and we’re looking good this time. I also completed all IPv6 addressing on all interfaces, including some link-local addresses and EUI-64 addresses. I guess IPv6 addressing is pretty simple and hard to screw up. But it’s still new enough to me that the novelty hasn’t yet worn off. I’d intended to do IPv6 routing protocols as well, but I ran into Yet Another IOS Image Problem. My 2621s need a slightly different image than what they have to support IPv6 OSPF. I figured out the right image with the NMC DOiT appendix PDF, and downloaded it tonight. I’ll blast it into flash tomorrow when I get to work (where my rack lives). So I should be good to do IPv6 routing and redistribution tomorrow night.

To keep making progress on the lab, I skipped over the IPv6 routing, and moved over to some of the Catalyst stuff. And while this isn’t a voice test or security test, I got elements of both to configure on the 3550 tonight. And I got another weird one – the scenario wanted me to configure a RARP server to support diskless Sun workstations that live in a different L3 network than the server their image lives on.

I did not know how to configure the RARP server, or even that a RARP server was the answer to solve the problem. All I knew for sure what that you couldn’t use DHCP services. I went to interface config mode, and stumbled on “ip rarp-server”, and intuitively knew that was part of the answer, but I didn’t know the rest. So here’s the deal.

  1. A diskless Sun workstation is completely brainless. No IP address, no nothing. So he puts a reverse ARP on the wire, looking for a brain.
  2. You’ve configured the router interface with “ip rarp-server xx.xx.xx.xx” where xx.xx.xx.xx is the IP of the server where the diskless workstation’s brain lives.
  3. You’ve also configured “arp xx.xx.xx.xx 1234.5678.90ad arpa” to map the diskless workstation’s MAC to the IP address the router’s RARP service will hand out.
  4. Therefore, the router will respond to the RARP with an IP address for the diskless workstation, and the IP address of the server holding the diskless workstation’s brain.
  5. So now that the diskless workstation has a IP address to talk with, and knows where to get his brain from, he will put an remote procedure call (RPC) on the wire destined to UDP/111. This gets picked up by the router.
  6. Now, you’ve ALSO configured the router with “ip forward-protocol udp 111” from global config, and also “ip helper-address xx.xx.xx.xx” where xx.xx.xx.xx is that same server holding the diskless workstation’s brain.
  7. Since you’ve so masterfully configured those IOS commands, the diskless workstation’s UDP/111 RPC call to the server is forwarded by the router to the server. And thusly, the brainless workstation is now talking to the server holding his brain.

More RARP server reading.

The other thing the scenario wanted me to do was mess with CoS to DSCP mapping, priority tagging, and MAC security on a Cat 3550. This was an issue of understanding what needed to be done (since we’ve been doing more and more QoS stuff at work), but not being familiar enough with the commands to make it happen. So let’s blast through some things here. Remember that we’re talking about a Cat 3550, in a scenario where you’ve got a PC and a Cisco 7960 phone on the same interface:

  1. How do I configure static MAC security? This works whether there’s a phone on the interface or not. It was mentioned that you generally don’t use static MAC security on a phone VLAN, but that it’s acceptable if you’re using dot1p priority tagging for the phone VLAN instead of dot1q trunking.
    1. Enter interface mode.
    2. switchport port-security” will enable port-security.
    3. switchport port-security maximum x” will set the maximum number of MAC addresses allowed on the port. Default is “1”. So if you have a phone AND and a PC on the port, that would be…uh…2 MACs on the port, thus necessitating the use of this command.
    4. switchport port-security mac-address 1234.5678.90ab” will statically assign the MAC address allowed on the port.
  2. How do I override CoS setting on frames that might be coming in from the PC? I think this assumes the frame is coming in through the phone, and that the CoS is actually being overridden by the switch ASIC in the phone. The 3550 will tell the phone to perform this task. I think. I found the documentation a little vague on this point.
    1. Enter interface mode.
    2. switchport priority extend cos 4” would override any CoS (class of service) from whatever it might be to “4”.
  3. How do I configure the switch to forward voice traffic as priority-tagged frames on the “native VLAN”? The magic here is a special class of VLAN called a “voice VLAN”, supported on 3550s.
    1. Enter global config mode.
    2. mls qos” enables QoS on the switch.
    3. Enter interface mode.
    4. switchport voice vlan dot1p” instructs the switch to forward voice traffic as priority tagged frames on the default native VLAN (ergo, an untagged frame with a CoS setting – don’t make this as hard to understand as the documentation tries to make it).
  4. How do I map layer 2 CoS values to layer 3 DSCP values? The idea here is that the 3550 switch is smart enough to look at a frame with CoS value, and then write a DSCP value into the IP packet before forwarding the frame out the egress port. Remember that best practice is to mark packets as close to the source as you can. Also remember that the CoS field is 3 bits, giving you possible values of 0 through 7.

    1. Enter global config mode.
    2. mls qos map cos-dscp 0 8 16 24 32 40 48” would map a CoS of 0 to DSCP of 0…CoS of 1 to DSCP of 8…CoS of 2 to DSCP of 16…and so on.

More port security reading.

More voice VLAN reading.