22
22
OPINION
they ’ ll simply advise you that , they ’ re having an attack , then proceed to black hole the target IP . Still , even if an attacker failed to saturate the transit uplinks , clients will be disrupted , unless inter-PoP links are upgraded to 40Gbps or QoS is implemented .
Let ’ s say your company has lots of money , and you upgraded your inter-PoP links to 40Gbps . Now , when an attacker fails to saturate your transit uplinks , you ’ ll be able to take all 28-32Gbps of traffic down to PoP B .
So what now ? The client under attack most probably has an SLA of 200Mbps on a 1Gbps port , and you will deliver all of the 20 + Gbps attack onto them . Was it worth taking it down to PoP B just to saturate your client ’ s port ? Although , you have solved your initial problem as other clients are unaffected by this attack .
Implement QoS Option 2 :
First of all , we need to create a traffic class per client . It ’ s quite easy if every client and their IP ranges are in the same system that creates access lists and class maps for routers . This means you can simply copy & paste the configuration – it ’ s up to your engineers to create this and something we really recommend doing .
Next , you must agree on the traffic marking . Every frame or packet has its own encapsulation and thus , QoS tag , which consist of three main ones in an IP / MPLS network , which would be COS , DSCP and EXP .
Then , you plan your maps , queues and thresholds to achieve the goal of dropping the least important traffic if it doesn ’ t fit somewhere . Additionally , if you treat your markings uniformly across your entire network , it ’ s easy to both implement and troubleshoot , if an issue should arise . After this is complete , you ’ ll only need to assign each frame / packet a QoS label to finish off .
An example A customer has an SLA of 200Mbps on a 1Gbps port . In other words , you allow them to burst up to 1Gbp , while guaranteeing to deliver the first 200Mpbs . In this case , you will ( aggregately or not ) police ( drop ) everything that is above 1Gbps in PoP A before making 200Mbps a higher priority and 800Mpbs of low priority . When these frames / packets are travelling down your links down to PoP B , in the case of link saturation , you will only drop those 800Mbps of low priority traffic , which is out of SLA anyway .
Here ’ s what your QoS should do :
Drop anything above what you can deliver to the
1 client ( why bother taking 20 + Gbps of traffic down to where you will drop it anyway ?)
Mark the remaining traffic as a high priority for an
2
SLA and low priority above it – in the case of saturation , you won ’ t breach SLA and won ’ t affect other clients .
After implementing this , you will only need to have capacity to direct your SLA traffic to PoP B . This is probably your normal traffic of 5-6Gbps , and anything above it isn ' t in an SLA , so it can ’ t be delivered depending on your decision of whether to deliver or not . Interestingly , as you still have lots of spare capacity here , even client bursts will be satisfied and almost never will a packet be dropped .
The caveat You should always be vigilant and conduct plenty of testing before putting your QoS into practice . For example , you need to allocate buffers to queues , as well as think about de-queuing rates and having your control traffic go into an even higher priority queue . Never put traffic of the same class into different queues , just use thresholds instead , or you ' ll get packet re-ordering . You must also always ensure you filter all control-pane traffic in order to protect switch / router CPUs .
There are also always lots of bugs in the routers / switches and documentation . Even if you configure it as it should be , that doesn ’ t mean it will work that way because of either a bug on the equipment or error in documentation . That ’ s why you should always test every feature on every class of devices before using it to ensure it ’ s working as it should .
In essence As demonstrated , QoS has saved money on not upgrading links from 10Gbps to 40Gbps and , has also made the network scale , which is incredibly important for large networks and those with lots of clients . So , the perfect network comes at a price of heavy engineering and testing , lots and lots of testing . But , as I said , it ’ s definitely worth doing this as it scales well , simplifies troubleshooting and saves you lots of money . n
www . networkseuropemagazine . com