Old and new SRX VPN througput

juniper Juniper has recently released a hardware refresh on the SRX branch firewall series and I had the chance to run IPsec throughput tests on them. Fortunately I also have test results for the same setup for the older devices (srx110, srx210) so I can make a comparison between those two platforms.

For various reasons the declared numbers in the marketing materials for all vendors are  way off and have nothing to do with reality but I will still use them as the baseline for comparison for the real results.

For the testing method I used a slightly modified RFC2544 test – specifically the throughput test where the maximal frame size was set to 1400B so no fragmentation would take place.

The devices we only configured with the tunnel and some management connection. No other configuration was present so these numbers must be taken with pinch of salt as normally your SRX would do more than just one VPN tunnel and the more active configuration bits the lower the throughput would be.

The VPN config:

security {
    ike {
        proposal ike_prop {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
            encryption-algorithm aes-256-cbc;
            lifetime-seconds 3600;
        }
        policy ike_pol {
            mode main;
            proposals ike_prop;
            pre-shared-key ascii-text "*"; ## SECRET-DATA
        }
        gateway ike_gw_srx02 {
            ike-policy ike_pol;
            address 10.1.12.2;
            external-interface ge-0/0/2;
        }
    }
    ipsec {
        proposal ipes_prop {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm aes-256-cbc;
            lifetime-seconds 3600;
        }
        policy ipsec_pol {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals ipes_prop;
        }
        vpn ipsec_vpn {
            bind-interface st0.192;
            ike {
                gateway ike_gw_srx02;
                ipsec-policy ipsec_pol;
            }
            establish-tunnels immediately;
        }
    }
    policies {
        from-zone z_internal to-zone z_internal {
            policy permit_all {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone z_internet to-zone z_internal {
            policy deny_all {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    deny;
                }
            }
        }
        from-zone z_internal to-zone z_internet {
            policy permit_out {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone z_internet to-zone z_internet {
            policy permit_all {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone z_internet {
            host-inbound-traffic {
                system-services {
                    ike;
                    ping;
                    ssh;
                }
            }
            interfaces {
                ge-0/0/2.0;
            }
        }
        security-zone z_internal {
            host-inbound-traffic {
                system-services {
                    ssh;
                    ping;
                }
            }
            interfaces {
                ge-0/0/3.0;
                lo0.0;
                st0.192;
            }
        }
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet;
        }
    }
    ge-0/0/2 {
        description p2p-public-iface-srx02;
        unit 0 {
            family inet {
                address 10.1.12.1/30;
            }
        }
    }
    ge-0/0/3 {
        description Test_IPsec-VPN-throughput;
        unit 0 {
            family inet {
                address 192.168.11.1/24;
            }
        }
    }
    fxp0 {
        unit 0 {
            family inet {
                address 10.64.3.135/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 192.168.10.1/24;
            }
        }
    }
    st0 {
        unit 192 {
            family inet {
                mtu 1428;
                address 192.168.1.0/31;
            }
        }
    }
}
routing-options {
    static {
        route 0.0.0.0/0 next-hop 10.64.3.1;
        route 192.168.16.0/20 next-hop st0.192;
    }
}

The table below is my attempt to get as close to the declared numbers:

Device Declared @ L2/1400B Measured @ L2/1400B
SRX110h2 65 Mbps 45 Mbps
SRX210 85 Mbps 33 Mbps
SRX550* 1 Gbps 485 Mbps
SRX 320 250 Mbps  187.9 Mbps
SRX 340 500 Mbps  374.8 Mbps

You can see that in both cases of the old and the new devices the throughput is about 50% of the declared values – the reason is that the for marketing purposes upstream and downstream are counted as separate entities thus can be added together to form a nice big number.

The throughput table above is for the most favourable conditions which almost never happen in the real network so the interesting question is then how does the same tunnel behave with different packet sizes specifically with small ones where the overhead will be much bigger and the nuber of packet will also be much larger. Let’s have a look at the result of the 64B frames:

Device Measured @ L2/64B
SRX110h2 2.6 Mbps
SRX210 1.9 Mbps
SRX550* 32 Mbps
SRX 320 12.5 Mbps
SRX 340 23.8 Mbps

 

In conclusion the new models of SRX have improved the encrypted traffic throughput by about 30% on equivalent models but the overall performance is still quite low compared to the public specification.

*The SRX550 is an old model but there shouldn’t be any performance difference to the new SRX 550.

All tests were performed on the current recommended version for the platform at the time of writing.

The tester used in this testing was EXFO FTB-1 with FTB-860G module (mode details are in the test reports).

The full results in pdf format are available here:

SRX110-RFC_2544

SRX210-RFC_2544

SRX550-RFC_2544

SRX320-RFC_2544

SRX340-RFC_2544

 

Basic IPsec tunnel on Juniper’s SRX

juniperThis article is a first part of a mini-series about the Juniper’s branch router-firewalls – the SRXes. I will start with an simple example of how to build a simple VPN between two branch routers later I will do a cisco-to juniper VPN scenario and the last article will be comparing real vs. the advertised throughput.

The example I am using here is done on vSRX (also known as firefly) and ranze of physical SRX from 110 to SRX550. The configurations are virtually the same as the syntax doesn’t differ between the platforms.

Topology used for this is as follows:

SRX_IPsec_topology

As you can see it is simple topology with two hosts two edge routers and one ISP router that is there just to make sure the tunnels actually traverse some network rather then being directly connected as that makes troubleshooting much easier.

The IP plan for this lab is as follows:

Router Interface IP/network
R1 ge-0/0/0.0 2.0.0.0/31
R1 ge-0/0/3.0 192.168.0.254/24
R1 st0.0 10.0.0.1/30
R2 ge-0/0/0.0 3.0.0.0/31
R2 ge-0/0/3.0 192.168.1.254/24
R2 st0.0 10.0.0.2/30
PC-A ge-0/0/0 192.168.0.1/24
PC-B ge-0/0/0 192.168.1.1/24
ISP ge-0/0/0.0 2.0.0.1/31
ISP ge-0/0/1.0 3.0.0.1/31

 The addressing is using 2.0.0.0/31 and 3.0.0.0/31 as public IP addresses the 10.0.0.0/30 are for the tunnel interfaces and the 192.168.0.0/24 and 192.168.1.0/24 are used for the LAN segments.

Now when all addressing is done we should start writing for phase 1 of IPsec which is the key exchange. The IKE configuration consists of 3 main parts and I will try to explain briefly what the configuration of each means in real terms.

Phase 1

In phase one the Internet Key Exchange protocol is used to securely figure out what is the key that will be used in further communication. As always phase 1 consists of 3 main components – proposal, policy and gateway. These three components could be roughly described as attributes,methods and peer’s details. See below for more details.

a) IKE proposal

The proposal is a list of attributes that IKE will use for the key exchange. It has multiple components but we’ll use the minimal set of three attributes which is enough to get our key exchange running.

  • Authentication method could be either password (pre-shared key) or digital signature RSA/DSA
  • DH group – determines algorithm for the secure key exchange over unsecured network (diffie hellman) and the number of keys it can use (in effect its strength) group 2 is 1024 bits
  • Authentication algorithm is a hashing method the DH will use

security {
    ike {
        proposal ike_prop {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
        }
}

b) IKE policy

The policy takes the attributes from the proposal and binds them with methods of your choosing. In this case the policy has just 2 more parts.

  • mode -aggressive/main – the aggressive mode is 4 packets long exchange and is sometimes considered more secure (less packets – less exposure) but there are known attacks on aggressive mode so using the main mode is generally a good thing – it also helps with the compatibility between vendors.
  • pre-shared-key/certificate – this is the secret that will be used for the Key exchange and must match on both ends of the tunnel.
security {
    ike {
        policy ike_pol {
            mode main;
            proposals ike_prop;
            pre-shared-key ascii-text "$9$jJiPQ/9pBRStu"; ## SECRET-DATA
        }
    }
}

 

c) IKE gateway

The IKE gateway defines identities of local and remote peers. It also refers to the IKE policy and binds the IKE chain/cascade together. There is couple additional identifiers used in this example (remote/local identity, local address) but they are optional – even though I would recommend using them or their alternatives.

  • address – is the remote peer’s public IP
  • external interface – is the local physical public interface
security {
    ike {
        gateway rt02 {
            ike-policy ike_pol;
            address 3.0.0.0;
            local-identity user-at-hostname "tnk@rt01";
            remote-identity user-at-hostname "tnk@rt02";
            external-interface ge-0/0/0;
            local-address 2.0.0.0;
        }
    }
}

Phase 2

Once the key exchange is finished phase 2 can begin. It is the IPSec itself and it also consists of 3 components. They are similar both in name and purpose.

a) IPsec Proposal

Again this is defining the methods the IPsec framework will actually use for encryption.

  • protocol ESP – this is the more secure of the two options (AH/ESP) and should be used all the time some recommendation ask for using AH+ESP but I am not sure that is possible in reasonable way
  • Authentication algorithm – select the algorithm for IPsec authentication
  • Encryption algorithm – select the strength of the cypher used for the packet encryption – be careful here as this setting heavily impacts performance. One should always avoid DES/3DES as they are weak cyphers. But also avoid a high-end AES as the impact might be rather severe. In general AES256 is considered strong enough while being reasonably easy to calculate.

security{
    ipsec {
        proposal ipsec_prop {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm aes-256-cbc;
        }
    }
}

b) IPsec Policy

In the policy the IPsec proposal is bound in and the PFS is defined. PFS is a security mechanism that does key-renegotiation after the key life-time expires. This is best practise and shouldn’t have major impact on packet processing.

security{
    ipsec {
        policy ipsec_pol {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals ipsec_prop;
        }
    }
}

c) IPsec VPN

This is the last piece of the tunnel puzzle where the IKE and IPsec are bound together into one “VPN”. It also binds in the secure tunnel interface into this whole lot. The one interesting parameters is the “establish tunnels immediately” which is very helpful for debugging as it will be sending the IKE/IPsec packets to peers even without valid traffic causing them to establish before the first packet destined fort he remote network will arrive.


security{
    ipsec {
        vpn vpn_rt02 {
            bind-interface st0.0;
            ike {
                gateway rt02;
                ipsec-policy ipsec_pol;
            }
            establish-tunnels immediately;
        }
    }
}

And because the SRX is in the flow mode a security zones and accompanying security policy must be defined for the tunnels to form. First I’ll define the zones themselves – for simplicity it will be only 2 zones. In the follow up examples this policy will be changed to reflect the use of the junos-host zone.

Zone name Description
z_trust trusted internal network
z_internet untrusted public network

We’ll allocate the correct interfaces in the right zones (note the st0.0 is in the z_trust) and permit the ike and icmp/ping to be accepted from the untrusted zone for processing by the Routing Engine.


security-zone z_trust {
    host-inbound-traffic {
        system-services {
            ping;
        }
    }
    interfaces {
        ge-0/0/3.0;
        st0.0;
    }
}
security-zone z_internet {
    interfaces {
        ge-0/0/0.0 {
            host-inbound-traffic {
                system-services {
                    ping;
                    ike;
                }
            }
        }
    }
}

All traffic is allowed inside the trusted zone. This needs to be done if you have any IP traffic between your hosts passing through the SRX – it is not strictly speaking necessary for the example but it is a good thing to have in mind.


from-zone z_trust to-zone z_trust {
    policy implicit_permit {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}

This policy is a clean-up – deny all traffic from public zones to private.


from-zone z_internet to-zone z_trust {
    policy deny_all {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}

So here we have a simple set-up for RT01 from our topology. In coming articles I will modify this config to be more suitable for faster deployments (using groups and objects) and in the end there will be couple hints on how to troubleshoot IPsec on SRXes as that topic is severely under-described.

IPSec general principles overwiev

ietf-logoHi this article is an output of my long – term digging around security stuff (and by that I mean especially a lot of IPSec things). After months I kept returning for some resources I cannot find anymore I decided to write quick but (hopefully) comprehensive overview of this technology and most if the things involved. So yes this is only the IPSec Theory (and at the end I will add few words about troubleshooting and some additional sources and references worth of reading). First things first so just few words about what IPSec is.

IPSec is a framework of symmetric encryption of IPv4 protocol which is good for VPN creation etc. Parts of the IPSec are Internet Key Exchange (binding all the pieces together), Diffie-Hellman algorithm (for secure key exchange) and symmetric pre-shared key or certificate based authentication. This main three components make IPSec very reliable and very difficult to break into (even though some of the algorithms are weak/vulnerable).

IPSec is using IKE in two phases (imaginatively names Phase I and Phase II). IKE itself is incorporating some more interesting techniques like isakmp (for automatic SA negotiation and maintenance) which is now the synonym for IKE on most current routers (even though it is just one of 4). So lets have a look at

IKE Phase I

In Phase I you can meet with terms like HMAC authentication, IKE security association (SA) or Diffie Helman. As all of these are par of the IKE phase I you do not have to worry much about it but still you should know of these  things before proceeding to the part about modes. So just very short explanation of these three terms:

  • HMAC is a way of authentication while using hash functions like MD5 or SHA-1
  • Diffie-Hellman algorithm is a way of encrypting traffic in a case both parties have just their counterpart’s public key
  • isakmp – protocol within IKE for SA negotiation and re-keying
  • IKE SA – is a list of encryption parameters negotiated and maintained by ike/isakmp in a form of a “table” called SA

Now where the necessary is written we can finally proceed to the more important stuff and that is  the modes. This phase can be done in three types of modes :

  • base mode (which is now not-to-be-seen anywhere except for some linux distros / old routers)
  • aggressive mode (which uses just three UDP packets for the whole phase I and is not widely used)
  • main mode (uses 6 packets in phase I and is generally most used and most recommended)

As I wrote in the brackets the main mode is the most used and that is for a reason. It takes 6 packets to complete phase I and thus if it fails on some step not much of CPU power is used whereas the aggressive mode is using only 3 packets so immediately after first received packet complex calculations have to be made. The other thing is that aggressive mode has more limited options of settings so it is not very good for fine tuning etc. As the Main mode is much more common I will continue with it. I will divide the whole process into three steps and describe what is happening:

Step A
host A  ———— IKE SA proposal —————->  host B
host A < ———— IKE SA proposal —————-  host B

Step B
host A  ———— IKE key exchange —————>  host B
host A <———— IKE key exchange —————  host B

Step C
host A  ———— authentication ID —————>  host B
host A  <———— authentication ID —————  host B

In step A both host sends the SA proposals with all the necessary information – if they match exactly the process will enter step B, where the DH takes place and public keys are exchanged. If the exchange is successful the algorithm will create symmetric encryption key for the authentication of peers. Now in this encrypted environment the actual key exchange (similar to eap) will take place (step C).

This is the end of phase one. There are minor differences in what is send in the packets according to the mode/authentication method used. I you would like to see all possibilities look at this pdf (and you could be interested in the whole page) with detailed IKE Phases descritptions.

After the exchange ends there could be an info packet sent to the remote peer.

IKE Phase II.

So now you have authenticated endpoints for you communication and a secure way for exchanging any sensitive information so that is exactly what will be done in phase II Again in the IKE Phase II you have a mode called quick mode. In fact I was unable to find any other modes for phase two and to my knowledge it is used everywhere. But important notice – there is also different modes present they are IPSec modes (tunnel/transport) not IKE modes so do not mix these thing up!

Except for the mode there is one more thing – PFS – which stands for perfect forward secrecy and it is a way of authentication (DH again).  This feature causes that the peer authentication done in Phase I is discarded and new Diffie-Hellman based authentication is executed in the already encrypted environment. This behaviour is rather paranoid but PFS switch (e.g. on firewalls) can cause a lot of troubles so just be aware of this option.

Within Phase II is also done the IPSec negotiation so let’s have a look on the packet flow:

host A  ————  IPSec SA proposal —————->  host B
host A  < ———— IPSecSA proposal —————-  host B
host A  —————–  ID HASH ———————–>  host B

In the SA proposal the authenticated peers exchange the actual information about the type of transformation (encapsulation), integrity algorithm and encryption (in SAs) and this exchange is ended by third packet which contains some parts created by isakmp commonly just proving the peer is there.

That is for he IKE exchange and phases. The next chapter will be just brief overview about the IPSec modes and some side info.

IPSEec Settings

In IPsec you have to know the following things:

  • transformations
  • modes
  • integrity algorithm

The transformations just says how the inbound packet will be handled – you have three options

  • AH – Authenticated Header -Protocol that ensures the authentication of the packet (does not encrypt it !)
  • ESP – Encapsulating Security Payload – this protocol ensures encryption, authentication and integrity of the original packet
  • AH+ESP – combination of both of the above first the ESP is used and later the AH

The combinations of the above (modes and transformations) you can find in detail here with some nice pictures and packet fields descriptions. The two last things you have to set is the integrity check algorithm and encryption. Usually it is MD5 or SHA1 for the first and AES or 3DES for the later.

All these settings are in sent overt to the peer in the IPsec SA and have to match. Sometimes there is a possibility of fall backs etc. But that is not really recommended.

I hope this article will save you some searching over the net (as this is not really easy to find) and will help you in your work. While creating this I also stumbled upon these articles which could be worth of reading.

If there is something you feel needs to be cleared out feel free to comment under this post.

l2tp over IPSec scenario

Huawei LogoSo this is the long promised scenario that can be used with windows XP (even though it is not really user friendly).

If you need a “PC-client – VPN-concentrator” scenario. Huawei does offer only one-way ticket for you and it is l2tp over IPSec. Unless you want to use some MPLS over IPSec which is in theory also a possibility but I guess it is supported only on high-end boxes. One can say why to use such a thing like l2tp when the IPsec provides almost everything by itself. Well there are some obvious reasons and some not-so-obvious ones. Lets go through them one-by-one.

  1. Huawei does not provide a software VPN client for the windows XP box (or any other) so guys with cisco experience can surely forget about the easy config on the client side (that is especially valid for Stefano ;) ) the only solution is using the “dialled connection wizard” from windows and some minor change in windows registry
  2. As for IPSec – this is L3 tunneling protocol so no services relying on broadcast will work without some help of another encapsulated protocol. If you think that this is no issue try to remember there is DHCP (which you definitely want to use if the use is more in larger scale) which is not relayed by client as there is no client. But this is only one that can be easily overcome by static IPs. But in common network is much more than DHCP, the most common service that needs L2 is the Microsoft sharing services (actually only the name-resolving  but that is enough). And many others…
  3. There is also one serious limitation in standard windows XP as for the dialed client is impossible to use tunnel mode for IPSec so only possibility is to use transport mode which is again not so good as the payload is still unencrypted. I am not sure if this had changed somehow in Vista but my guess would be that it remained the same.

This being said the prospect seems to be a bit grim. But hey you can still be sure the tunnel is secure against man-in-the-middle attacks and also that no fiddling with your traffic occurred. If you request encryption of the data itself you really should use some upper layer encrypted protocol like SSH, maybe even use it for tunneling etc. I guess you got the point now.

So that’s for limitations and basics. Now straight to the code.

Important notice this was done on VRP 3.40 but it should work without problem on VRP 5.X as well.

Step one  – creation of IPSec service (the details of this config are in other articles so without explanation this time).

#
ike peer 1
pre-shared-key test
remote-address 10.0.0.1
#
ipsec proposal 1
encapsulation-mode transport
#
ipsec policy-template tunnet-1 10
ike-peer 1
proposal 1
#
ipsec policy p 10 isakmp template tunnel-1
#
interface Ethernet2/0
description to PC 1
ip address 10.0.0.2 255.255.255.0
ipsec policy tunnel-1
#

So that’s the IPsec tunnel prepared. Now follows an optional but recommended step of creating an DHCP ip-pool for the connecting clients. Ideally you can re-use the pool which is already set for your LAN. But you may also want to have your remote connections in different network so it is up to you really. I just re-used the pool I had.

#
domain system
ip pool swimming-pool-1 20.0.0.1 20.0.0.100
#

Now it is time for the second step – preparation of  l2tp

At first it is important to create user with a password and service-type ppp as we will use authentication

#
local-user test
password simple test
service-type ppp

#

So Now when we have a user that can be authenticated let’s create thel2tp  service itself

We have to define a virtual-template interface where is set what kind of ppp authentication, what IP  and what DHCP pool will be used for the remote clients (if any).

#
interface Virtual-Template 0
ppp authentication-mode chap
ip address 20.o.0.1 255.255.255.0
remote address pool swimming-pool-1
#

Now with our virtual-template interface in place we can finally define l2tp. It is done through binding of the virtual-template into a l2tp group.

#
l2tp-group 1
allow l2tp virtual-template 0
#

That’s it if you have done this you will be able to start a ppp session over the tunnel made of IPSec and then get authenticated against local user database.

This is for the router side as for the windows (XP) you need to make some adjustments. First important thing is to change (or checks if you have) a registry key on this location.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRasManParameters

here change or create key named ProhibitIpSec and it should be reg_dword type and value set to 1

This has to be done as windows have the IPSec disabled by default. So if you have done that you definitely have to reboot so the windows system can reload the network settings. After this tweak you just need to create and configure the virtual connection from the station. To do so  go to following location start/run/networking connections/New Connection Wizard.

After you enter the wizard select these options

  1. Connect to the network at my workplace
  2. Virtual Private Network Connection
  3. Company Name
  4. Don’t dial the initial connection
  5. VPN Server Selection(ip address 10.0.0.2)

When you finish this basic setup it is time to adjust it for the settings of our server . In Connect Virtual Private Network Properties change values as seen on pictures below.

connection_tupe_sel

After this change the password in security tab as shown below.

password

And then select the chap for ppp authentication with options set like this

advanced_security_tab

Now just check if the tunnel is going up on the router side with the notorious display ike sa and display ipsec sa commands and if you are getting the right IP address on client side are done.

I realize that this is now very nice solution especially in comparison with cisco but as far as I know this is the only way on low and mid-end boxes.

Some GRE/IPSec and basic QoS scenarios on AR 19-X and VRP 5.20 Part II.

Huawei Logo

So after previous post the whole setup should be working. But there are some things to be done yet. The heading says that the missing part is the QoS. So let’s have a closer look.

Step one is easy – just create some ACLs to match the traffic in our case it is goes like this:

#
acl number 3001 name black
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 26
acl number 3002 name platinum
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 28
acl number 3003 name gold
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 18
acl number 3004 name silver
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq ftp-data
acl number 3005 name default
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 22
#

If we have done this our traffic can by matched according to this rules so we can process it. In this case we were using the destination port as the distinguisher but as this is done by ACLs you can use whatever option the ACL will allow.

Step No.2 is to create create traffic classifiers, name them and bind them with the previously created ACLs. In the display below  we named the classifiers the same as ACLs so it is more obvious what is going on.

#
traffic classifier PLATINUM operator or
if-match acl 3002
traffic classifier DEFAULT operator or
if-match acl 3005
traffic classifier GOLD operator or
if-match acl 3003
traffic classifier SILVER operator or
if-match acl 3004
traffic classifier BLACK operator or
if-match acl 3001
#

Notice the operator “or” in our case it has no meaning as we use only one rule/ACL but if you use more of these itwill enable you to combine multiple ACL’s in different classifiers etc. which could be very useful and makes things very flexible.

Step No. 3 is to create traffic behaviour i.e. the action made if the acl is matched.

#
traffic behavior PLATINUM
remark dscp af32
traffic behavior DEFAULT
remark dscp af23
traffic behavior GOLD
remark dscp af21
traffic behavior SILVER
remark dscp af22
traffic behavior BLACK
remark dscp af31
#

Again we used the same names as for the ACL’s and Classifiers and the action is to remark the dscp value from whatever it was previously to certain value.

Step No.4 binding the proper classifier to proper behavior in a qos policy.
Here we are telling that in this particular policy we want these combinations of classifiers and behaviours.

#
qos policy qos
classifier BLACK behavior BLACK
classifier PLATINUM behavior PLATINUM
classifier GOLD behavior GOLD
classifier SILVER behavior SILVER
classifier DEFAULT behavior DEFAULT
#

With this step we have done almost everything. The last step is to apply the policy somewhere. This somewhere is inbound interface as this whole thing is basically marking only.
So step No.5 is just this piece of code:

#
interface Ethernet0/1
.
.
qos apply policy qos inbound
#

So we are done…nope somebody should shout this is not whole and that somebody would be completely right. The operation done above would result in marked traffic flowing through the router with it’s default scheduling mechanism in place. Sounds good one might say, but unfortunately the default scheduling mechanism is FIFO alias no scheduling at all. This would result in no effect at all. If you were working on different equipment it can work (e.g. the S3900 and S5600 have in their default SP+WRR in VRP ver. 3.40 of course you would need to match the default classes/types as the voice is SP and the rest is WRR). But on AR 19-XX you have to either enable scheduling or as we did just cheat a little.
We skipped scheduling as we instead used weighted traffic shaping based on the same ACL’s which actually works almost the same as scheduling but with much better control over what,when and how is processed. I know that scheduler should be set but in this case (very small routers) it does not really matter.

So the final step is to apply qos gts (general traffic shaping) on the outbound interface.

#
interface Virtual-Ethernet0
.
.
qos gts acl 3001 cir 50 cbs 3125 ebs 0 queue-length 50
qos gts acl 3002 cir 75 cbs 4687 ebs 0 queue-length 50
qos gts acl 3003 cir 100 cbs 6250 ebs 0 queue-length 50
qos gts acl 3004 cir 100 cbs 6250 ebs 0 queue-length 50
qos gts acl 3005 cir 175 cbs 10937 ebs 0 queue-length 50
#

Ok we need to explain what we just did here.
We needed to apply the shaping on the virtual Ethernet as we are using ethernet-style qos and if we would like to do it on the atm it would be much more complicated.
The gts is abbreviation for general traffic shaping then we define how to recognize which traffic to shape. Here we can re-use our old ACLs to recognize that particular traffic. Then the magic starts cir stands for committed information rate and in a way it is the most important number here – it says how much traffic is allowed to pass before queuing/dropping. In effect our config will pass 50kbits/sec matching acl 3001, 75 kbits/sec matching acl 3002 and so on. So the sum of all these cirs should equal you available bandwidth on the egress interface (minus approximately 10% as a reserve for packet bursting and other). The remaining three parameters are good for fine-tuning. CBS is committed burst size which means how much it is allowed one queue to be overloaded. This value is computed automatically and does not have any effect if all other queues are used fully. You can change it of course and if you will not share all bandwidth among the queues you can use it for short term automatic bursting of speed of one queue without actually re-configuring anything (good for voice and video). But in most cases this will have very limited effect. The extended burst size does the same thing but it is taking it to another level. As committed burst size is necessary for the proper function at all times ebs is not. The last variable is queue length. This is kind of fun as this actually can substitute the scheduling but the situation can get really complex when playing with queue length. This option says how many packets will be held during the congestion instead of being dropped so with combination with the previous options your results can be really interesting changing delays, and such stuff.

I hope this is inspirational and again in case of any question write your comment under this article.