A long time ago I had a pretty successful blog located at mellowd.co.uk/ccie - I used this blog at the time to document my journey towards my CCIEs and well as my JNCIE. Unfortunatley, I lost the entire blog in a botched upgrade a few years back. My intention here is to try and republish some of my better posts. I’ll be able to extract this info from the wayback machine. Note that a lot of the posts were relevent years ago and things have since moved on. But some of the fundamentals never change :) I’ll be releasing content over the coming weeks.

I was forced to use a 3750G as a router yesterday for a WAN link that was only 70Mb. The LAN interfaces were all gig. The customer wanted to ensure that 30% of the bandwidth was available for EF marked packets. Everything else was to get 70% A lot of people have trouble with QoS on the 3750. This is mainly due to the tiny buffers, complexity, and the defaults it uses. Let’s use the following network for this post: The laptop on the left is connected on a gig port running iperf on linux. The laptop on the right is connected to a hard-coded 100Mb port.

Brad Fleming from Kanren gave me remote access to a lab MX5 router in order to do the Junos section of this port for when I am very grateful! There are many different needs for H-QoS and may different ways to configure it. I’m going to be going over one particular use case for H-QoS in which I use on a daily basis. More so than any other type of QoS, H-QoS is very hardware specific. Even line-card specific. In this post I’ll be using a Juniper MX5 and a Cisco ME3600X, both which allow me to do H-QoS on their gig ports.

An ethernet physical port can only run at certain speeds. i.e. 10/100/1Gb/etc – Often customer will purchase a sublevel of bandwidth on that bearer speed. For example Customer A wants to buy 30Mb of bandwidth. You can’t run the physicla ports at 30Mb, so the ISP will have the interface run at 100Mb and police inbound at 30Mb. This makes QoS jus a little more complicated. All the ratios we’ve used in the past will ratio themselves at the WAN port’s physical speed. Also the router will not know that if 40Mb of burst comes from the LAN, that the actual bandwidth is only 30Mb.

Going back to the diagram we used in part 1. Let’s say that we want to shape certain traffic to certain bandwidths under congestion. I want EF packets to get 20Mb priority, AF31 packets to get 50Mb and whatever is left to get 30Mb. I want to enable WRED in the BE queue, and also modify the default WRED profile. I’m going to take the assumption that packets have already been marked correctly as shown in my first post. IOS IOS is very simple in it’s configuration: policy-map OUTBOUND_QOS class EF priority 20000 class AF31 bandwidth 50000 class class-default random-detect dscp-based random-detect dscp 0 20 40 5 !

While the concepts of QoS on vendor platforms are similar, the actual configuration is very different. I wanted to do a few posts on the differences between Junos and IOS on the normal QoS things that I do on a day to day basis. For this first post I’m going to use a very simple diagram: On the LAN are hosts with soft-phones. These phones use specific ports but do not mark packets sent with DSCP EF. Our goal here is to ensure voice packets are marked. Any UDP packet with a port number of 5060 I will mark with DSCP EF.

If you’re configuring an IOS router remotely with a chance of losing the device, most engineers might decide to do a reload in 5 before starting. If you happen to lose connection to the box after a change, the router will reload in 5 minutes erasing any unsaved changes. This works, but is less than ideal. It can take a few minutes for a box to reload. What happens if the box is looking after multiple customers as well? There is a better way. Just revert the config. Using this is pretty trivial. You do need to turn on the archive command first though.

A lot of people confuse the above 3 items. I’ll explain exactly what each of the 3 above items do, how you can see them, and how the routers use them to provide a L3VPN service. Let’s take the following topology for this post: Here we have 2 L3VPN customers running over our MPLS core. R5 is advertising 5.5.5.5/32. R8 is also advertising 5.5.5.5/32 Route Distinguisher The route distinguisher’s sole job is to keep a route unique while the PE routers advertise NLRI (Network Layer Reachability Information) to each other. If R5 and R8 both advertise 5.5.5.5/32 to R3, how will R3 advertise both of those routes to R4 while keeping them unique.

I’ve noticed that a lot of people seem to get confused with what exactly dot1q is doing most of the time. It’s actually incredibly simply. Tagging traffic, or Trunking in Cisco-talk, is a very straightforward process. I will not be discussing ISL here as not only do I not use it, but Cisco is phasing it out on their stuff anyway. The dot1q tag is simply inserted into the layer2 header when a packet leaves a switchport over a trunk. If a frame leaves a switchport that is not a trunk, there is no dot1a tag inserted into it, regardless of what vlan the frame came from or is going to.

It can be quite confusing to work out what all these terms are exactly referring to. I’ll try and put a concise answer for all of them here with an example. RIB – Routing Information Base This is the route table. i.e. When you do a show ip route, the RIB is what you see AR1#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 10.