A working way to force EX VoIP VLAN classification!

In my previous post “How does EX CoS interact with the VoIP VLAN feature?“, I proved in a lab environment that while the Juniper documentation implies that setting the set forwarding-class X parameter in the edit ethernet-switching-options voip interface ge-x/x/x hierarchy forces traffic into a forwarding-class, this is not the case. Instead this actually (assuming you have LLDP-MED on and a BA classifier on the interface) causes the EX to signal the phone via LLDP-MED to use a specific marking on all traffic to cause it to be classified into a certain forwarding class.

This leaves the question of what you would do if you truly wanted to force all traffic arriving on the VoIP VLAN to be forced into a certain forwarding class without making it possible for other traffic to be placed there based on a DSCP marking coming from the user’s computer. One possible way to do this would be with a firewall filter, which I’m going to explore in this post.

It would be worth reading the aforementioned post before going into this one, as in this post I’m skipping over a few valuable things mentioned in the previous post.

I’m going to use the same baseline configuration as I did in the last lab. Here is the configuration of the EX4200 acting as the switch;

[email protected]# show 
## Last changed: 2013-04-08 00:22:06 UTC
version 11.4R7.5;
system { /* OMITTED */ };
interfaces {
    ge-0/0/0 {
        description "Hoff laptop";
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members DATA;
                }
            }
        }
    }
    ge-0/0/1 {
        description "EX4200 acting as Router";
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members [ VOICE DATA ];
                }
            }
        }
    }
    me0 { /* OMITTED */ };
}
routing-options { /* OMITTED */ };
ethernet-switching-options {
    voip {
        interface ge-0/0/0.0 {
            vlan VOICE;
        }
    }
}
vlans {
    DATA {
        vlan-id 55;
    }
    VOICE {
        vlan-id 66;
    }
}

And here’s the configuration of the other EX4200 which has a couple of tagged routed interfaces that I can throw traffic at (to get it egressing an interface on the other EX4200 that we can measure);

[email protected]# show 
## Last changed: 2013-12-21 08:07:44 UTC
version 11.2R2.4;
system { /* OMITTED */ };
interfaces {
    ge-0/0/1 {
        description "EX4200 acting as Switch";
        vlan-tagging;
        unit 55 {
            description "DATA vlan";
            vlan-id 55;
            family inet {
                address 192.168.55.1/24;
            }
        }
        unit 66 {
            description "VOICE vlan";
            vlan-id 66;
            family inet {
                address 192.168.66.1/24;
            }
        }
    }
    me0 { /* OMITTED */ };
}
routing-options { /* OMITTED */ };

Okay, so we’ve already baselined this in the previous configuration to check that traffic does in fact by default go into the BE queue in this configuration, but I’ll quickly re-prove this. Let’s start with 30secs of a 100Mbit iperf from my laptop to 192.168.55.1  on the DATA VLAN;

Phoebe:~ tim$ iperf -c 192.168.55.1 -u -b 100m -t 30

And the result;

[email protected]# run show interfaces queue ge-0/0/1    
Physical interface: ge-0/0/1, Enabled, Physical link is Up
  Interface index: 130, SNMP ifIndex: 504
  Description: EX4200 acting as Router
Forwarding classes: 16 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
  Queued:
  Transmitted:
    Packets              :                245623
    Bytes                :             372363016
    Tail-dropped packets :                     0
<some output omitted for brevity>

Looking good. We’ll now clear the interface stats then confirm the same behaviour for the VOICE VLAN;

[email protected]# run clear interfaces statistics ge-0/0/1
Phoebe:~ tim$ iperf -c 192.168.66.1 -u -b 100m -t 30

And the result for this one;

[email protected]# run show interfaces queue ge-0/0/1    
Physical interface: ge-0/0/1, Enabled, Physical link is Up
  Interface index: 130, SNMP ifIndex: 504
  Description: EX4200 acting as Router
Forwarding classes: 16 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
  Queued:
  Transmitted:
    Packets              :                245811
    Bytes                :             373631264
    Tail-dropped packets :                     0
<some output omitted for brevity>

Okay cool. Now it’s time to implement the a firewall filter that classifies all traffic coming in on the VOICE VLAN into the EF forwarding-class and leaves the rest of the traffic in the default BE forwarding-class (note that when using the action then forwarding-class X in an ethernet-switching firewall filter you are required to set a then loss-priority X action to accompany it);

[edit interfaces ge-0/0/0 unit 0 family ethernet-switching]
+       filter {
+           input MF-VoiceVlan;
+       }
[edit]
+  firewall {
+      family ethernet-switching {
+          filter MF-VoiceVlan {
+              term VoiceVlan {
+                  from {
+                      vlan VOICE;
+                  }
+                  then {
+                      accept;
+                      forwarding-class expedited-forwarding;
+                      loss-priority low;
+                  }
+              }
+              term Catchall {
+                  then accept;
+              }
+          }
+      }
+  }

Let’s now clear the interface stats then check that the DATA VLAN is still doing its thing;

[email protected]# run clear interfaces statistics ge-0/0/1
Phoebe:~ tim$ iperf -c 192.168.55.1 -u -b 100m -t 30

And the results look the same as expected;

[email protected]# run show interfaces queue ge-0/0/1    
Physical interface: ge-0/0/1, Enabled, Physical link is Up
  Interface index: 130, SNMP ifIndex: 504
  Description: EX4200 acting as Router
Forwarding classes: 16 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
  Queued:
  Transmitted:
    Packets              :                245395
    Bytes                :             372017368
    Tail-dropped packets :                     0
<some output omitted for brevity>

Now, for the moment of truth – to re-test the VOICE VLAN iperf and check that traffic is being classified into the EF forwarding-class! Firstly to clear the interface stats and run the iperf;

[email protected]# run clear interfaces statistics ge-0/0/1
Phoebe:~ tim$ iperf -c 192.168.66.1 -u -b 100m -t 30

And now to check the results;

[email protected]# run show interfaces queue ge-0/0/1    
Physical interface: ge-0/0/1, Enabled, Physical link is Up
  Interface index: 130, SNMP ifIndex: 504
  Description: EX4200 acting as Router
Forwarding classes: 16 supported, 4 in use
Egress queues: 8 supported, 4 in use
Queue: 0, Forwarding classes: best-effort
  Queued:
  Transmitted:
    Packets              :                     0
    Bytes                :                     0
    Tail-dropped packets :                     0
<some output omitted for brevity>
Queue: 5, Forwarding classes: expedited-forwarding
  Queued:
  Transmitted:
    Packets              :                245479
    Bytes                :             373126624
    Tail-dropped packets :                     0
<some output omitted for brevity>

It would appear this works exactly as expected!

While this method is not quite as elegant config-wise, it actually works as expected – which is always a good thing :). I expect that in most cases simply using the traditional method of telling the switch to signal a marking to the phone will be sufficient, but if you are ever in a situation where there is a requirement not to trust the phone to do the right thing but instead to absolutely force traffic from the VoIP VLAN into a certain queue this will do the trick nicely.

Hope this helps.

3 thoughts on “A working way to force EX VoIP VLAN classification!

  1. He Tim… very glad you wrote this up. I’ve poured through Juniper documentation recently and you’re quite right their explanation of all this differs depending on what you’re reading. Fast question for you…the firewall rule…can we roll an array of vlans there? Thanks!

    term VoiceVlan
    from
    vlan [ voicenet1 voicenet2 voicenet3 voicenet4 ]

    • Hey Mate,

      Cheers for the feedback. That should be fine to use the syntax you suggest above to match traffic from any one of your vlans listed there.

      Thanks,
      –Tim

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s