1,819 Words. Plan about 12 minute(s) to read this.
Last night was Friday night, and I was just wiped out from the week’s events. Long week, lots going on, and I wasn’t up for the rack. I was feeling a bit like Bilbo upon reaching his one-hundred-and-eleventieth birthday – like butter scraped over too much bread. Some days, it’s just hard to come home and hack IOS. So, I put off completion of NMC scenario 2 until today. In retrospect, I’m glad I did. I was better rested, and better able to deal with the rest of the scenario.
Today, I worked through a number of issues:
- Basic HSRP with interface tracking, preemption, authentication and tweaked hello and hold timers. I don’t consider HSRP a terribly complicated topic, so I’m not going to blog about it, at least not today. GLBP & VRRP I probably will, when I get to those in the scenarios, because they aren’t as common as HSRP on production Cisco networks.
- Basic multiple spanning-tree (802.1s). This was straightforward, creating multiple spanning tree instances, mapping certain VLANs to certain instances, tweaking bridge priority of the MST instances to force root, and tweaking port priority and path cost to force certain interfaces to forward and others to block. I may blog about MST more another time. Just remember that MST is essentially rapid spanning tree, except that instead of every VLAN running its own STP instance, you can map a bunch of VLANs to one instance. Within the MST domain, you can have multiple STP instances. It’s a nice way to reduce the number of spanning-trees your switches have to pay attention to. I’ll probably blog about MST when I get a more complicated scenario involving connectivity back to a legacy 802.1d spanning-tree domain, something like that.
- Remote SPAN. Spanning is where you copy traffic from one source (a port, a range of ports, a VLAN, etc.) and send the copy to a destination port. Spanning is commonly used to feed data to a packet sniffer or IPS device without the device having to be in-line. Regular old boring SPAN sessions, that most of use have set up many times, happen on the same switch. Remote SPAN gives you the ability to send source traffic on one switch to a destination on a different switch, assuming the switches are in the same layer 2 domain. Encapsulated Remote SPAN (which is NOT covered today, I assume I might hit ERSPAN later in a scenario) allows you to send source traffic on one switch to a destination on another switch, while traversing a layer 3 boundary.
Quick RSPAN config:
- SOURCE SWITCH: Define a remote-span VLAN. This VLAN will only be used to carry your RSPAN traffic between the source switch and destination switch. You can carry the RSPAN VLAN via a trunk between the switches. (1) “vlan 995” would create a VLAN 995. (2) Inside the VLAN paragraph, type “remote-span” to define VLAN 995 as a special VLAN to be used for remote span traffic. Do this on both switches.
- SOURCE SWITCH: Define your source traffic. I won’t go into all the options, but you can define your source traffic as coming from a VLAN or range of interfaces, and can decide whether you want to see traffic coming into the vlan, leaving the VLAN, or both. Be aware that if the VLAN is a transit VLAN (common on a core or distribution layer 3 switch), and you define “both”, that you’ll get 2 copies of the frame – one when the packet enters the VLAN (ingress), and another as it leaves the VLAN (egress). “monitor session 1 source interface Gi1/0/7 both” defines a span source of gigabit ethernet 1/0/7 for span session 1, and sends copies of both ingress and egress frames. If you don’t want that condition, use “tx” or “rx” instead of “both“.
- SOURCE SWITCH: Define a source filter if needed. If your source interface is a vlan trunk, but you don’t want to see all the vlans on the trunk, you can filter to only capture traffic for certain vlans. “monitor session 1 filter vlan 100 , 200” would only capture vlan 100 and 200 traffic from your source port. The filter directive tells the switch what vlan traffic we want to capture, NOT what we want to ignore.
- SOURCE SWITCH: Define a destination. In other words, now that we know what we want to look at, we have to send that traffic somewhere. Since we’re talking about remote-span (not local span), the command looks like this: “monitor session 1 destination remote vlan 995” where vlan 995 is the special remote-span vlan we defined in the beginning.
- DESTINATION SWITCH: Define the same remote-span VLAN as you did on the source switch.
- DESTINATION SWITCH: Define a traffic source. The source is, very simply, going to be the remote span vlan. “monitor session 1 source remote vlan 995” tells the switch to look at remote span VLAN 995 for source traffic. If you didn’t catch this before, this is why it’s really important that you’ve got the remote-span vlan (VLAN 995 in my example) common between the 2 switches.
- DESTINATION SWITCH: Define a destination. The destination is the interface you wish to output the spanned traffic to. This is the interface you’d plug in your sniffer/IPS, or what have you. “monitor session 1 destination interface Gi1/0/1” sets gigabit ethernet 1/0/1 as the destination port for the remote span traffic.
- Multicast with a static rendezvous point. I’m not going to blog too much about this, because I really struggled. I am still a multicast bonehead. I’m not sound enough on the theory for possible solutions to leap out at me when there are problems connecting to leaves in the multicast tree. Configuring the basic multicast was easy. Getting all the routers that participated in the 220.127.116.11 group to respond to ping traffic from the multicast source was hard.
- Type global-config “ip multicast-routing” on all the routers I was going to run PIM on.
- Type interface command “ip pim sparse-mode” on all interfaces that would participate in the tree. You need sparse-mode for a shared-tree, which this scenario called for. Since it also called for a static rendezvous point, I didn’t do sparse-dense mode.
- Type global-config “ip pim rp-address xx.xx.xx.xx” where xx.xx.xx.xx was my static rendezvous point.
- Then use loopbacks that were going to act as receivers for 18.104.22.168 multicast traffic with “ip igmp join-group 22.214.171.124“. Okay, so far things were easy, no real surprises. PIM adjacencies formed, etc. Once that was done, the idea was do go to a specific router in the topology, and do a ping to the multicast group IP. That’s a handy way in the lab to create traffic coming from a multicast source. If you get ping responses back from all the routers that you configured to join the group, then bang – you’re done. Life is good. Cherubim sing as the clouds part and glorious sunlight shines through. But this is a CCIE practice lab, and you aren’t going to hear a peep out of those cherubim until that e-mail with the number in it, right? Right. So of course, I had one router not responding, and some cranky cherubim.
- Long story short: in this particular scenario, the solution to the one router that wasn’t responding to pings was to do a lot of “show ip mroute” command on various routers in the multicast tree, interpret the output, and then tweak the multicast routing table with “ip mroute” static multicast routes (NOT static unicast routes, as static unicast routes were forbidden in the scenario).
- The goal was to tweak the multicast routing table so that all routers could receive the multicast traffic without the Right And Noble Laws Of Multicast Forwarding leaving an orphaned multicast receiver. And that’s the problem I was (and still am) having. I don’t know those Right And Noble Multicast Laws nearly well enough. I generally understood the problem, and after a review of the solution, I implemented it to verify that it worked. But I don’t 100% “get it” yet. So I will dutifully review general multicast principles again to see if I can get multicast crammed into my braincase.
- IPv6 routing basics. The last thing I did on the scenario today was IPv6 routing, which was the last thing I had left to do. I would normally have done IPv6 routing earlier, but I needed to upgrade the IOS on 6 routers for various reasons. I got that taken care of on Friday. With the IOS FINALLY correct (I really think I got it this time), I was able to do all of the requested IPv6 routing tasks in the scenario. This post is long already, so I’m going to put down some tips I’ve picked up relating to IPv6 routing thus far. So, no explanations or “how to”, just a hodge-podge of stuff.
- You must enable IPv6 routing in global config with “ipv6 unicast-routing“.
- You don’t have to have a “router” paragraph to get the IPv6 routing protocol going. You can turn on the routing protocol per-interface. You may still need to use a global “ipv6 router” paragraph for certain features like redistribution, to specify OSPF area attributes, etc.
- When you summarize IPv6 addresses, take the boundaries you know from IPv4 and forget about them. IPv6 addresses are hex-based, not decimal. You must unlearn. I haven’t found a nice table out there in Internet-land that helps with IPv6 summarization, but I’m either going to find one, or make one myself. There’s got to be one in a book somewhere. Maybe Doyle’s? I don’t even have a process for how to bull my way through the IPv6 summarization using paper and pencil…let alone do it in my head.
- When adding IPv6 loopback interfaces into OSPF, the loopback network will show up in the ipv6 routing table as a /128 route (ergo, a host route), even if the mask assigned to the loopback ipv6 address is not /128. If you require the loopback to show up in the OSPF table with the assigned mask, then you have to assign an OSPF interface type to the loopback, such as “ipv6 ospf network point-to-point“.
- You can tunnel IPv6 in an IPv4 tunnel. I’m assuming you know how to make tunnels already, so what follows are merely high-level steps:
- Create a tunnel interface.
- Assign the tunnel interface an ipv6 address.
- Set your tunnel source to be an IPv4 interface on the router.
- Set your tunnel destination to be an IPv4 interface on the router.
- Set your tunnel mode, remembering that GRE over IPv4 is default (so if that’s what you want, you don’t have to set the mode). Another option is ipv6ip, where ipv6 packets get encapsulated in ipv4, but are not GRE apparently.
- If you have no IPv4 addresses on the router, then you’ll need to assign a RID for IPv6 OSPF to run.
- To disable IPv6 split-horizon for those irritating point-to-multipoint interfaces on hub routers, you need to do a “no split-horizon” in the ipv6 router paragraph of the routing protocol you’re concerned with.