I was not into this lab at all today. It wasn’t the lab itself…I just couldn’t get motivated. I completed the whole thing – it was pretty short. In fact, it was one of the easier labs in the NetMasterClass.com DOiT set, not too much to configure, not too much in the way of mind-bending screwball configuration challenges. I just wasn’t up for it today. I spent just a tad over 7 hours on it, and that included a LOT of dubbing around, experimenting with different techniques (especially in BGP), just to see what would happen, that kind of stuff. After I was done, I went out into the cold (about 18 degrees out there this afternoon, with the wind blowing), and worked on a long-term yard clean-up project. I had a bunch of large-ish pines taken down about a year ago by a friend of mine. He knocked ’em down and bucked ’em up. I’ve been working on hauling the pieces out of the woods and splitting them. I’m a regular Grizzly Adams. :) Today, I didn’t split anything – I just hauled big stumps and stacked them. I don’t want all that wood to lie fallow for another season – it’ll rot, and then it’s no good to anyone. I’ve been pulling as much out of the woods as I can before the snow decides it’s going to stick around for the season. After the scenario, I just needed a little manual labor to clear my head, so I went out and worked.
I finally have a hold on the concept of multicast reverse path forwarding (RPF) checks. When a router receives a multicast stream, he needs to decide if it’s okay to forward copies of that stream out his multicast-enabled interfaces, the concern being loop avoidance. You don’t want multicast packets going round and round the network – that’s just not good. So how does a multicast router decide what multicast streams to forward, and what not to forward? By doing an RPF check. To do an RPF check, the router notes the source IP of the multicast stream, and then checks the unicast routing table for that source IP. Did the multicast stream with that particular source IP arrive via the interface that the unicast routing table points back to for that source IP? Then the multicast stream is good – the router will forward copies out all multicast-enabled interfaces that should get a copy of the stream. Which interfaces those are will depend on whether the routers are running sparse or dense mode, and whether a host downstream from a particular interface has joined the multicast group. Did the RPF check indicate that the multicast stream arrived on an interface other than the one you’d expect based on the unicast routing table? Then don’t forward that stream.
So what other technical joys did this scenario bring?
- I must admit to being lazy about doing my “show frame-relay pvc” and “show frame-relay map” after I get the frame-relay configured. Today, I decided that I needed to make that a part of my sanity checking. I was hugely surprised to discover a router that, despite being configured correctly with “no frame-relay inverse-arp“, had a couple of dynamic maps across DLCIs I didn’t assign. A reload took care of the problem. That would have been a bonehead-easy thing to overlook on the actual lab. I would have died to have a “78” on my actual lab with 3 points taken off for a problem with frame-relay inverse-arp, of all things. So okay, new sanity check added to my permanent repertoire.
- I have modified my lab strategy to do IPv6 addressing at the same time I’m doing my IPv4 addressing. My logic is this: I have to craft a lengthy text document with all of the router interfaces and switch VLAN assignments. If I just add the IPv6 link-local and site-local addressing to those interface paragraphs I’m already staring at in my text document, I’m saving time.
- RIP “default-information originate” has a route-map option to conditionally advertise the default route. In other words, RIP won’t advertise the default route unless the conditions of the route-map are satisfied. In this example, the RIP router will not originate a default route unless 22.214.171.124/25 is in the routing table.
access-list 10 permit 126.96.36.199 0.0.0.127
route-map QUADZEROIF permit 10
match ip address 10
set interface FastEthernet0/0
default-information originate route-map QUADZEROIF
- I still haven’t wrapped my brain around it fully yet, but it appears that you need to disable EIGRP split-horizon on interfaces where you have a secondary IP address, if you want that secondary IP prefix to be advertised out that interface. I haven’t sorted out why that is yet, or even if I’m understanding the issue properly. Anyone else been there that can comment?
- Totally Obscure IOS Feature Of The Day – you can set a router to send metrics to a mysterious Cisco device called a Distributed Director. This would be done with the “ip drp server” command. I didn’t get into reading about this too much, as it appears to a be a highly specialized IOS command group supporting a unique Cisco platform. More information about the Cisco Distributed Director is buried in the Network Management section of the IOS documentation.
- I was asked to configure a Cat3550 to “offload HTTP requests from the web server”. Logically, this is a web caching function, as that’s what web caches do – they take some of the load off of the web server. I was a little thrown, thinking this function might be a function unique to the 3550’s, but all they were looking for was a basic WCCP configuration which would work on any IOS box. Read more about WCCP here. (1) Enable WCCP globally with “ip wccp web-cache”. (2) Configure an interface to redirect HTTP requests to a web cache, “ip wccp web-cache redirect in”.
CAT2(config)#ip wccp web-cache
CAT2#show ip wccp web-cache
Global WCCP information:
Router Identifier: -not yet determined-
Protocol Version: 2.0
Service Identifier: web-cache
Number of Service Group Clients: 0
Number of Service Group Routers: 0
Total Packets s/w Redirected: 0
Redirect access-list: -none-
Total Packets Denied Redirect: 0
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0
Total Bypassed Packets Received: 0
CAT2#show run interf vl20
Current configuration : 94 bytes
ip address 188.8.131.52 255.255.255.0
ip wccp web-cache redirect in
More in the next post, probably tomorrow. I’m think I’m knocking off for tonight. I have more I want to blog about the BGP scenario, reserving bandwidth with RSVP, and some really interesting layer 2 filtering on the 3550.