IP QoS: Two generations of class-of-service tools
My IP QoS: Two generations of class-of-service tools article published by SearchTelecom gives you a very high-level overview of IntServ and DiffServ approaches to IP QoS as well as brief description of various DiffServ tools.
More to explore:
AAA command authorization gotchas
Once upon a time, AAA command authorization in Cisco IOS queried the TACACS+ server for every single command a user entered. Rules have changed drastically in the meantime (at least for IOS release 12.4):
- Non-privileged show commands are executed without TACACS+ authorization. Privileged show commands (show running or show archive log config) are still authorized.
- Some commands that can be executed in non-privileged (aka disable) mode (enable, disable, help, logout) are authorized only if you configure aaa authorization commands 0 methods regardless of the current privilege level.
- Other commands (for example, ping) are authorized based on the current privilege level.
For example, if you’ve configured AAA command authorization only for privilege level 15, the ping command will be authorized if you’re working in enable mode, but not otherwise.
- Command authorization is not performed on console unless you’ve configured aaa authorization console.
Specify MPLS TE bandwidth as percentage of interface bandwidth
When configuring MPLS Traffic Engineering in your network, you have to specify the amount of bandwidth that the MPLS TE tunnels can request on each MPLS TE-enabled interface with the ip rsvp bandwidth command.
Until recently, this command accepted only fixed bandwidth (in kilobits), which could be pretty inconvenient if you wanted to use common interface templates or deployed MPLS TE on links with varying bandwidth (for example, Multilink PPP bundles). IOS release 12.2SRC introduced a variant of the same command (ip rsvp bandwidth percentage) that allows you to specify reservable bandwidth as percentage of the current interface bandwidth. Unfortunately this feature didn’t make it into 12.4(20)T.
Leak Map Confusion
A short question I've got from Shahid Rox:
Today I read your article about scaling EIGRP using stub routers. I was wondering whether you can use the leak map only for routes learned from other EIGRP neighbors? Is it also usable to filter connected routes?
Leak-map controls what its name implies: the leakage of routes received from EIGRP neighbors to other EIGRP neighbors. To filter connected prefixes redistributed into EIGRP, use the route-map on redistribute connected command. The only way I've figured out to filter announcements of directly connected networks that are part of the EIGRP process is the distribute-list out command.
Internet Access Russian Dolls
When the local Telco installed my blindingly fast 20 Mbps Internet-over-fiber-cable service, I was expecting to use DHCP on the router’s outside interface to connect to the Internet. After all, they’re running switched Ethernet VLANs over the fiber cable, and using DHCP seemed a logical choice. Imagine my surprise when I had to configure PPP-over-Ethernet (PPPoE) – it was as if I would be using a DSL connection, not a fiber-optic cable.
RIP Rocks in Low-End Hub-and-Spoke Networks
Yesterday, I introduced a scenario where RIP would (in my opinion) work much better than OSPF. If you were not persuaded by the “management-level” arguments, let’s focus on the technical details (but make sure you read the scenario first).
Why is RIP still kicking?
Assuming your purchasing department didn’t buy boxes that don’t have enough memory to run OSPF, you could usually choose between RIP and OSPF as the routing protocol … and I would always select RIP in this scenario. Let’s start with the “management-level” arguments: RIP is simpler to design (there is almost nothing to design) and troubleshoot than OSPF. It uses less memory and CPU cycles and I would also expect low-end boxes to have fewer bugs in RIP than in OSPF. More in-depth arguments are coming in the follow-up post.
Enhance the Traceroute Output
After working with MPLS Traffic Engineering lab for a few days and interpreting IP addresses from various traceroute outputs, I finally had enough and wrote a simple Perl script (below) that parses router configurations and produces ip host configuration commands for every interface IP address it encounters. When you paste the ip host commands into the configuration of the edge router from which you do the tests, the meaningless numbers finally make sense.
Multilink bundles have varying bandwidth
I have always intuitively assumed that the interface bandwidth on MLPPP bundles is the sum of interface bandwidths of individual interfaces that are part of the bundle. Recently I’ve tested my assumption and it works as expected.
Do you need LDP with MPLS TE?
An anonymous commenter to my implicit NULL/PHP post made a very valid point:
Most Cisco documentation states that you must enable LDP before doing MPLS-TE, which is a complete fallacy.
If you're using MPLS TE simply to shift IP traffic around your network, he's absolutely right: there is no need to run LDP if you have an IP-only network. If you're running MPLS VPN or BGP on edges/MPLS in the core, the answer becomes “it depends.”