Setting up a quality of service through a MAN network.
On each geographical site we have:
– A free-to-air INTERNET network
– An encrypted INTRANET network (via IPSEC)
The Paris Site is our main site, it hosts the internet and INTRANET networks.
– Do not be dependent on the PROLAN ISP in terms of routing.
– Ensure minimum throughput for INTERNET and INTRANET networks
– Be flexible for adding new site in terms of:
– Quality of service
Why set up CBWFQ?
– We want quality of service to ensure bandwidth at an IP address range and not in relation to a type of service.
Why GRE tunnels?
– Be independent in terms of routing.
– Have one CBWFQ per site.
Setting up THE GRE Tunnels
– At the host site (PARIS), we will have to set up a GRE tunnel for each customer site.
– On customer sites (NICE and TOURS), we will have to set up a GRE tunnel to the host site.
In terms of routing, we need to distinguish two worlds:
– Before the assembly of the GRE Tunnels (Underlying)
– When the GRE tunnels are mounted (Overlay)
For the Underlying world, we will set up static routing.
The PARIS site wants to set up a GRE Tunnel with NICE. The GRE tunnel will have as IP source the WAN leg of the PARIS site router and as IP destination the WAN leg of the NICE site router. It will therefore be necessary to indicate by which path the router of PARIS will be able to join the WAN leg of the NICE site router. (And vice versa)
For the Overlay world, we will set up OSPF dynamic routing.
All our customer sites will learn their routes by default via the OSPF protocol. The default route will therefore be their GRE tunnels. This protocol will also allow customer sites to announce to the host site the networks present on their geographical sites.
CBWFQ – Class-Based Weighted Fair Queueing
We need to ensure minimum bandwidth for both of our network types in the event of network congestion.
To do this, we will put in place quality of service.
So we're going to set up CBWFQ.
In order to prioritize our flows in case of network congestion, we will:
– Classify our feeds via access-lists to place our packages in queues.
– Assign a percentage per queue
– Apply our CBWFQ policies on our Tunnel interfaces
We will classify via access-lists our feeds:
– PRIORITY (SNMP, SSH, NTP, LOG)
Streams that are not classified will go into the DEFAULT queue.
Priority streams are called LLQ (Low Latency Queueing)
The policy-map command will allow us to create our queues.
To do this, it must be specified:
– A class-map
– A percentage or bandwidth
Specifying a percentage allows you to make as little change as possible in the event of an increase or decrease in throughput to the ISP.
In the case of network congestion, there are two possible types of action:
In case of network congestion, packages will be dropped in order to meet the bandwidth limit set. This will require the transmitter to lower its transmission speed in TCP.
In the event of network congestion, packages will be randomly selected to be placed in queues in order to meet the set bandwidth limit. These packages will be processed when there is bandwidth available.
The configured CBWFQ makes traffic shaping through the command:
shape average percent 100
The CBWFQ Quality of Service will be implemented on each tunnel interface.
To apply cbWFQ, we will use the command
service-policy output XXXXX
To specify when the link is saturated, we will use the command:
bandwidth 30000 (For 30Mbps)