481 Words. Plan about 3 minute(s) to read this.
It’s hodge-podge day. I’m posting little paragraphs about issues I ran into with this scenario. This won’t be a stream of consciousness post, as I’m writing the paragraphs as I run into the issues.
- I was scratching my head about an EIGRP split-horizon issue. I knew that a particular router wasn’t receiving any routes because his neighbor wasn’t sending them due to split-horizon. But when I did a “no ip split-horizon” on the appropriate interface of the offending router, it didn’t fix the problem. Long story short, I needed to do a “no ip split-horizon eigrp 1“, where “1” was the EIGRP AS number.
- I also had a strangely worded task, where I was instructed to create a point-to-point interface over the top of a particular VLAN. As I looked at the topology, the point-to-point interface was to be formed across directly connected ethernet links. My assumption was that the scenario was therefore looking for PPPoE. Nope. They were actually looking for a tunnel in this case. Yes, the scenario used the term “point-to-point”, but that didn’t mean PPP. A tunnel did fulfill the requirements just fine, but my brain didn’t even allow for a tunnel be a possible solution because I was hung up on the terminology of “point to point”. I must unlearn, unlearn…
- Also – note that generic traffic shaping (GTS) is supported on GRE tunnel interfaces, but not ip-in-ip. I mentioned this in an earlier post, but wanted to be sure I was clear. There’s an exception on the 7500 router where GTS on GRE is not supported, but the rest of the platforms are fine. 7500s aren’t a test platform, so I think this is a non-issue. I only bring it up because I somehow got it in my head that GTS was not supported on GRE. I went the long way around to configure traffic shaping on an tunnel interface with a class-based shaper when I could have slapped on a traffic-shape statement in 2 seconds and been done. Oh, well – a good little run-through for class-based shaping anyway. There’s always a silver-lining! :-)
- To prove a remote interface is reachable, you have to actually ping it. Seeing that the expected route showed up in the routing table is not enough. This is especially true with BGP, when you may need to set “next-hop-self” for certain neighbors to avoid forwarding a packet to a non-BGP router that will have no idea where a BGP-only prefixes lives.
- The following command makes a Cat3550 act as a TFTP server, serving up the file flash:c3550-ipservicesk9-mz.122-37.SE1.bin as catos.bin instead, and restricing access to users in ACL number 10.
“tftp-server flash:c3550-ipservicesk9-mz.122-37.SE1.bin alias catos.bin 10“
- A Cisco router can participate in TCP explicit congestion notification with the “ip tcp ecn” command. Read more about TCP ECN.
More hodge-podge in the next post…