Junos and IOS QoS – Part 2 of 4 – Schedulers and policy-maps

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
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.252
 service-policy output OUTBOUND_QOS

There are three classes in the service policy. Class EF has priority 20Mb, class AF31 has bandwidth 50Mb, and class-default has all that’s left. I’ve also set up WRED and it will start to drop packets when the queue level hits 20. One it hits 40 it’ll be dropping 20% of all packets (1/5) and any more packets will cause tail-drop.

Junos

In Junos, we first create our RED profile:

[email protected]> show configuration class-of-service drop-profiles
relaxed {
    fill-level 50 drop-probability 10;
    fill-level 75 drop-probability 15;
    fill-level 95 drop-probability 20;
}

We then create our schedulers, which tells Junos how to treat each queue:

[email protected]> show configuration class-of-service schedulers
EF {
    transmit-rate 20m;
    priority strict-high;
}
AF31 {
    transmit-rate 50m;
}
BE {
    transmit-rate 30m;
    drop-profile-map loss-priority any protocol any drop-profile relaxed;
}

We then create a scheduler-map, which tells Junos what traffic belongs in each queue:

[email protected]> show configuration class-of-service scheduler-maps
OUTBOUND-QOS {
    forwarding-class expedited-forwarding scheduler EF;
    forwarding-class assured-forwarding scheduler AF31;
    forwarding-class best-effort scheduler BE;
}

Finally this is applied to the interface. Note that this happens under the class-of-service stanza and NOT the actual interface stanza:

[email protected]> show configuration class-of-service interfaces
fe-0/0/7 {
    scheduler-map OUTBOUND-QOS;
}

Verification

The best command for checking a service policy applied to an interface is show policy-map interface interface-name:

R1#sh policy-map interface fa0/0
 FastEthernet0/0

  Service-policy output: OUTBOUND_QOS

    queue stats for all priority classes:
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0

    Class-map: EF (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match:  dscp ef (46)
      Priority: 20000 kbps, burst bytes 500000, b/w exceed drops: 0


    Class-map: AF31 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match:  dscp af31 (26)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      bandwidth 50000 kbps

    Class-map: class-default (match-any)
      800 packets, 48000 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any

      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 800/48000
        Exp-weight-constant: 9 (1/512)
        Mean queue depth: 0 packets
        dscp       Transmitted         Random drop      Tail drop          Minimum        Maximum     Mark
                pkts/bytes            pkts/bytes       pkts/bytes          thresh         thresh     prob

        default      554/33240           0/0              0/0                 20            40  1/5

This shows each of the queues as well as our RED profile attached to the class-default queue.

On Junos its a bit more cryptic. To see the bandwidth attached to each queue:

[email protected]> show interfaces fe-0/0/7 extensive | find "CoS information"
  CoS information:
    Direction : Output
    CoS transmit queue               Bandwidth               Buffer Priority   Limit
                              %            bps     %           usec
    0 best-effort            30       30000000     r              0      low    none
    1 expedited-forwarding   20       20000000     r              0 strict-high    none
    2 assured-forwarding     50       50000000     r              0      low    none
  Interface transmit statistics: Disabled

  Logical interface fe-0/0/7.0 (Index 75) (SNMP ifIndex 520) (Generation 140)
    Flags: Device-Down SNMP-Traps 0x0 Encapsulation: ENET2
    Traffic statistics:
     Input  bytes  :           2426330700
     Output bytes  :             90196588
     Input  packets:              1770438
     Output packets:               872568

etc etc etc

To see the bits in each queue:

[email protected]> show interfaces queue fe-0/0/7
Physical interface: fe-0/0/7, Enabled, Physical link is Down
  Interface index: 141, SNMP ifIndex: 519
Forwarding classes: 8 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
  Queued:
    Packets              :                863884                     0 pps
    Bytes                :             106578924                     0 bps
  Transmitted:
    Packets              :                863884                      0 pps
    Bytes                :             106578924                     0 bps
    Tail-dropped packets :                     0                     0 pps
    RED-dropped packets  :                     0                     0 pps
     Low                 :                     0                     0 pps
     Medium-low          :                     0                     0 pps
     Medium-high         :                     0                     0 pps
     High                :                     0                     0 pps
    RED-dropped bytes    :                     0                     0 bps
     Low                 :                     0                     0 bps
     Medium-low          :                     0                     0 bps
     Medium-high         :                     0                     0 bps
     High                :                     0                     0 bps
Queue: 1, Forwarding classes: expedited-forwarding
  Queued:
    Packets              :                     0                     0 pps
    Bytes                :                     0                     0 bps
  Transmitted:
    Packets              :                     0                      0 pps
    Bytes                :                     0                     0 bps
    Tail-dropped packets :                     0                     0 pps
    RED-dropped packets  :                     0                     0 pps
     Low                 :                     0                     0 pps
     Medium-low          :                     0                     0 pps
     Medium-high         :                     0                     0 pps
     High                :                     0                     0 pps
    RED-dropped bytes    :                     0                     0 bps
     Low                 :                     0                     0 bps
     Medium-low          :                     0                     0 bps
     Medium-high         :                     0                     0 bps
     High                :                     0                     0 bps
Queue: 2, Forwarding classes: assured-forwarding
  Queued:
    Packets              :                     0                     0 pps
    Bytes                :                     0                     0 bps
  Transmitted:
    Packets              :                     0                      0 pps
    Bytes                :                     0                     0 bps
    Tail-dropped packets :                     0                     0 pps
    RED-dropped packets  :                     0                     0 pps
     Low                 :                     0                     0 pps
     Medium-low          :                     0                     0 pps
     Medium-high         :                     0                     0 pps
     High                :                     0                     0 pps
    RED-dropped bytes    :                     0                     0 bps
     Low                 :                     0                     0 bps
     Medium-low          :                     0                     0 bps
     Medium-high         :                     0                     0 bps
     High                :                     0                     0 bps
Queue: 3, Forwarding classes: network-control
  Queued:
    Packets              :                  8684                     0 pps
    Bytes                :                451568                     0 bps
  Transmitted:
    Packets              :                  8684                      0 pps
    Bytes                :                451568                     0 bps
    Tail-dropped packets :                     0                     0 pps
    RED-dropped packets  :                     0                     0 pps
     Low                 :                     0                     0 pps
     Medium-low          :                     0                     0 pps
     Medium-high         :                     0                     0 pps
     High                :                     0                     0 pps
    RED-dropped bytes    :                     0                     0 bps
     Low                 :                     0                     0 bps
     Medium-low          :                     0                     0 bps
     Medium-high         :                     0                     0 bps
     High                :                     0                     0 bps

I must admit, I much prefer the Cisco implementation of show policy-map interfaces

Junos and IOS QoS – Part 1 of 4 – Marking traffic

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.

IOS

IOS is very simple indeed. You match the kind of traffic you want in an ACL, create a service-policy using that ACL, mark the packets in that policy:

access-list 100 permit udp any eq 5060 any eq 5060
!
class-map match-all VOICE
 match access-group 100
!
policy-map MARK-TRAFFIC
 class VOICE
  set dscp ef
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 service-policy input MARK-TRAFFIC

Junos

Junos is more complicated. Juniper call marking via matching on parts of a packet a multifield classification. Multifield classification works by matching terms in a firewall filter. The DSCP value is not directly set in the firewall filter. Rather the filter places a packet in a specific queue. It’s the queue outbound that sets the actual dscp value in the packet.

First let’s create the classification I need:

[email protected]> show configuration class-of-service
classifiers {
    dscp MARK-TRAFFIC {
        forwarding-class expedited-forwarding {
            loss-priority low code-points ef;
        }
    }
}

There is a built-in queue called expedited-forwarding. You cna rename these if you wish and add more queues. In the configuration above it states that any packet in this queue will be marked with DSCP EF.

[email protected]> show configuration firewall
family inet {
    filter VOICE {
        term VOICE {
            from {
                protocol udp;
                source-port 5060;
                destination-port 5060;
            }
            then {
                forwarding-class expedited-forwarding;
                accept;
            }
        }
        term CATCH-ALL {
            then accept;
        }
    }
}

In the firewall statement, any packet that matches UDP with source and destination port equal to 5060 will be placed in the expedited-forwarding queue. As this is a firewall filter, I need to still allow the packets through. I also need a catch-all at the end otherwise any packet not matching the first statement is dropped.

Finally the filter will be applied inbound on the LAN interface:

[email protected]> show configuration interfaces fe-0/0/7.0
family inet {
    filter {
        input VOICE;
    }
    address 10.2.2.1/24;
}

Both terms above will mark the needed packets as DSCP EF. All others will not be changed.

Certain Juniper platforms do support the setting of the DSCP value inbound, but it seems to be very hardware specific

UPDATE (03/09/2013)
As a few have pointed out, I’m not actually marking anything here, I’m only classifying. My bad. In order to actually mark a packet you need to use rewrite rules. Junos has a few built-in, but you can make your own as well:

[email protected]> show class-of-service rewrite-rule
Rewrite rule: dscp-default, Code point type: dscp, Index: 31
  Forwarding class                    Loss priority       Code point
  best-effort                         low                 000000
  best-effort                         high                000000
  expedited-forwarding                low                 101110
  expedited-forwarding                high                101110
  assured-forwarding                  low                 001010
  assured-forwarding                  high                001100
  network-control                     low                 110000
  network-control                     high                111000
etc etc etc

The default will ensure that EF traffic is marked 101110 which is DSCP value 46. We apply this rewrite to an interface like so:

[email protected]> show configuration class-of-service
interfaces {
    ge-0/0/0 {
        unit 50 {
            rewrite-rules {
                dscp default;
            }
        }
    }
}

Of course you can create your own rewrite rules, but I’m just going for the easy way out above.

ME3600X Bridge Group into a Brocade VPLS for H-QoS

The Cisco ME3600X and ME3800X series support both VPLS and H-VPLS. MPLS features require an expensive license. If you are currenlty joining a few leased lines together into a VPLS you don’t always need the more expensive MPLS license.

Any carrier circuit terminating on the Cisco ME can be placed into a bridge-group based on the dot1q tag. This can then be passed along or re-written to a new vlan tag into a Brocade XMR port which stick that frame into a VPLS. Why not just terminate the carrier circuit directly onto the XMR? I’ve recently had to do this because the XMR line cards we have do not support H-QoS. More and more carriers are aggregating many B end circuits into single high-bandwidth A end gig links. I need to be able to shape traffic outbound on a per-vlan basis, and within that queue give priority to certain queues. The ME3600X can do H-QoS and its exactly the reason I’m using it.

Let’s show a quick diagram so we know what we are talking about. Click the image for the full image:

On the right I have two SRX210s and an 1841 sending tagged traffic into the carrier network. That carrier network is multiplexing all three circuits into a single link on the A end. That goes into the ME3600X. From the ME3600X it goes off to a Brocade XMR. That Brocade is connected to another Brocade over the MPLS core and finally to another 1841 on the other side.

On the ME3600X I could easily span each vlan over to the XMR and have the XMR VPLS them back. The issue with that is that if hosts behind SRX is sending a ton of traffic to a host at SRX2, why waste bandwidth hairpinning traffic over to the XMR when it could be done at the ME3600X?

In other words, instead of doing this:

We do something like this:

Now you may be asking, why not just get this carrier to stick them in the VPLS? That could work if all these links were coming from the same carrier, but often they aren’t.

ME3600X EVC config

ethernet evc TESTLAB
!
interface GigabitEthernet0/1
 description Link to Carrier
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 1 ethernet TESTLAB
  description SRX1
  encapsulation dot1q 2000
  rewrite ingress tag pop 1 symmetric
  bridge-domain 150
 !
 service instance 2 ethernet TESTLAB
  description SRX2
  encapsulation dot1q 2001
  rewrite ingress tag pop 1 symmetric
  bridge-domain 150
 !
 service instance 3 ethernet TESTLAB
  description 1841
  encapsulation dot1q 2002 second-dot1q 100
  rewrite ingress tag pop 2 symmetric
  bridge-domain 150
 !
interface GigabitEthernet0/24
 description Link to XMR
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 150 ethernet
  description VPLS Core
  encapsulation dot1q 150
  rewrite ingress tag pop 1 symmetric
  bridge-domain 150
 !
end

I have three service instances configured on gi0/1 – each matching the vlan id that the carrier is using for transport. Notice that I can match on both an outer and inner tag that I’m originating from the 1841. Gi0/24 is the port connected to the XMR and that’s in the same bridge-group with a vlan tag of 150.

On the XMR side I’m simply matching on vlan 150 and placing those frames in the VPLS.

Brocade Config

vpls DARREN-TESTING 3200
  vpls-peer 172.10.10.1
  vlan 150
   tagged ethe 2/20

Connectivity verification

All my CPEs are running OSPF on their WAN links. I’ve also hard-coded their MAC addresses so it’ll be easy to see in this post.

[email protected]> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.0.0.4         ge-0/0/1.2000          Full      4.4.4.4            1    39
10.0.0.3         ge-0/0/1.2000          2Way      3.3.3.3            1    34
10.0.0.2         ge-0/0/1.2000          Full      2.2.2.2          128    32

SRX1 has three neighbours. Fully adjacent with the DR and BDR. This means I get get to the remote VPLS 1841. Let’s take a look at the mac address table for the VPLS on the PE connected to the ME3600x:

[email protected]#sh mac vpls 3200

Total MAC entries for VPLS 3200: 5 (Local: 3, Remote: 2)

VPLS       MAC Address    L/R Port  Vlan(In-Tag)/Peer ISID      Age
====       ===========    === ====  ================= ====      ===
3200       0000.1111.0000 L   2/20  150               NA        0
3200       0000.2222.0000 L   2/20  150               NA        0
3200       0000.3333.0000 L   2/20  150               NA        0
3200       0000.4444.0000 R   1/10  172.10.10.1       NA        0

The MAC’s for SRX1, SRX2, and the first 1841 are all via tag 150 out interface 2/20. The remote 1841’s MAC is learned via the remote PE router.

We should see all four MACs on thee ME3600X out their respective tagged ports:

ME3600X#show mac address-table bridge-domain 150 | begin DYNAMIC
 150    0000.1111.0000    DYNAMIC     Gi0/1+Efp1
 150    0000.2222.0000    DYNAMIC     Gi0/1+Efp2
 150    0000.3333.0000    DYNAMIC     Gi0/1+Efp3
 150    0000.4444.0000    DYNAMIC     Gi0/24+Efp150

The ME3600X is also telling us which service instance under the physical port it’s learning the MAC address from.

QoS Config

Let’s assume the the circuit tagged with vlan 2000 has only got 5Mb, lan 2001 has 10Mb, and vlan 2001 has 15Mb. I want to shape each EVC to their respective speed, and then give priority to DSCP EF packets. I also want to police that queue to 50% to ensure that priority queue cannot hog the link.

class-map match-all EF
 match dscp ef
!
policy-map QoS
 class EF
  priority
  police cir percent 50
   conform-action transmit
   exceed-action drop
 class class-default
  queue-limit percent 100
!
policy-map VLAN2000
 class class-default
  shape average 5000000
   service-policy QoS
policy-map VLAN2001
 class class-default
  shape average 10000000
   service-policy QoS
policy-map VLAN2002
 class class-default
  shape average 15000000
   service-policy QoS

Each policy is then attached to the service instance itself. I’ll use service instance 1 as an example here:

interface GigabitEthernet0/1
 service instance 1 ethernet TESTLAB
  description SRX1
  encapsulation dot1q 2000
  rewrite ingress tag pop 1 symmetric
  service-policy output VLAN2000
  bridge-domain 150

Each service instance can have an individual policy. So we have broken up the physical port into many virtual circuits. Each VC has their own shaper and priority queue.

QoS Verification

If you apply the policy as above, you can’t use show policy-map interface anymore. Instead you need to use show ethernet service instance policy-map

ME3600X#show ethernet service instance policy-map
  GigabitEthernet0/1: EFP 1

  Service-policy output: VLAN2000

    Class-map: class-default (match-any)
      8 packets, 644 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
  Traffic Shaping
    Average Rate Traffic Shaping
    Shape 5000 (kbps)
      Output Queue:
        Default Queue-limit 49152 bytes
        Tail Packets Drop: 0
        Tail Bytes Drop: 0

      Service-policy : QoS

        Class-map: EF (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match:  dscp ef (46)
          Strict Priority
          police:
            cir percent 50 % bc 250 ms
            cir 2500000 bps, bc 78000 bytes
            conform-action transmit
            exceed-action drop
          conform: 0 (packets) 0 (bytes)
          exceed: 0 (packets) 0 (bytes)
          conform: 0 bps, exceed: 0 bps
          Queue-limit current-queue-depth 0 bytes
              Output Queue:
                Default Queue-limit 49152 bytes
                Tail Packets Drop: 0
                Tail Bytes Drop: 0

        Class-map: class-default (match-any)
          8 packets, 644 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: any
          Queue-limit 100 percent
          Queue-limit current-queue-depth 0 bytes
              Output Queue:
                Default Queue-limit 49152 bytes
                Tail Packets Drop: 0
                Tail Bytes Drop: 0

OSPF packets are going through and that’s being matched by class-default. We can force some EF traffic by pinging with a TOS value:

[email protected]> ping 10.0.0.1 rapid tos 184
PING 10.0.0.1 (10.0.0.1): 56 data bytes
!!!!!
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.766/4.635/7.131/1.269 ms
ME3600X#show ethernet service instance policy-map
  GigabitEthernet0/1: EFP 1

  Service-policy output: VLAN2000

    Class-map: class-default (match-any)
      328 packets, 26028 bytes
      5 minute offered rate 2000 bps, drop rate 0000 bps
      Match: any
  Traffic Shaping
    Average Rate Traffic Shaping
    Shape 5000 (kbps)
      Output Queue:
        Default Queue-limit 49152 bytes
        Tail Packets Drop: 0
        Tail Bytes Drop: 0

      Service-policy : QoS

        Class-map: EF (match-all)
          5 packets, 530 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match:  dscp ef (46)
          Strict Priority
          police:
            cir percent 50 % bc 250 ms
            cir 2500000 bps, bc 78000 bytes
            conform-action transmit
            exceed-action drop
          conform: 5 (packets) 510 (bytes)
          exceed: 0 (packets) 0 (bytes)
          conform: 0 bps, exceed: 0 bps
          Queue-limit current-queue-depth 0 bytes
              Output Queue:
                Default Queue-limit 49152 bytes
                Tail Packets Drop: 0
                Tail Bytes Drop: 0

        Class-map: class-default (match-any)
          323 packets, 25498 bytes
          5 minute offered rate 2000 bps, drop rate 0000 bps
          Match: any
          Queue-limit 100 percent
          Queue-limit current-queue-depth 0 bytes
              Output Queue:
                Default Queue-limit 49152 bytes
                Tail Packets Drop: 0
                Tail Bytes Drop: 0

There we see the five EF packets.

So there you have it. Not too difficult at all to get the basics working.

What next?

Ever since I got my CCIE in January of this year I’ve been struggling to center in on exactly what I wanted to study next. I’ve been a bit all over the place.

I would like to get my JNCIE-SP, CCIE-SP, and CCDE. Without focusing on a single one at a time I’ve been all over the place. I’ve currently got my CCIE-SP written done, but wanted my JNCIE-SP first, then wanted my CCDE.

So. I’ve taken a step back and going to do one at a time. This list could change, but this is the plan. I want to complete my JNCIE-SP exam before the end of this year. I’ve booked a data for the 12th of December in Amsterdam for the JNCIE-SP lab. If and when I pass that lab date I’ll be doing my CCDE.

CCIE-SP is a bit on the back-burner for now. Even though I currently work at an ISP, I don’t often work with IOS-XR. Perhaps by the time I get back into the CCIE-SP Cisco will have released VIRL for IOS-XR. I can only hope.

With a bit of direction I should be able to get back on track!