Static inside and outside NAT example

In simplified way Network Address Translation (NAT) allow us to translate source or/and destination address of IP packet. There is few reasons to do it like managment purpose, security or IP address savings. NAT is one of technology that with success delays IPv6 world wide deployment. First of all let’s explain NAT wording that at first sight looks slightly confused. Below simple diagram will help us to understand the concept.

  • Inside local IP is how inside address is seen localy by inside hosts, so from the our LAN perspective it’s real IP of our PC. 
  • Inside global IP is how inside address is seen globaly by outside hosts, so from the outside hosts in Internet it’s translated (NATed) IP of our host. 
  • Outside local IP is how outside address is seen localy by inside hosts, so from the LAB perspective it’s translated (NATed) IP of host that resides out of our network like in Internet. Hosts in LAN will use it as destination IP address.
  • Outside global IP is how outside address is seen globaly by outside hosts, so from the our LAN perspective it’s real IP address of host that resides out of our network.

Inside translation type is frequently used in today’s networks. In case we have 10000 hosts in our LAN and would allow them to connect to the Internet resource then we need provide external public IP address for each internal hosts. So big range of public IP addresses expensive but sometimes even not be available for not service provider company. NAT is a solution in this example. We can simple translate all inside IP addresses to 1 public IP using Port Address Translation (PAT) NAT feature. The first question that comes to the mind is how the router will be able to distinguish the packets once they back from the Internet. PAT simply translate the IPs to one outside IP but additionaly translates the layer 4 source ports. Router initially simple rewrites the TCP or UDP source port changing just a source IP but in case another host intimates session with the same layer 4 source then router will take first free port. Based on this easy mechanism router is able to create around 64511 session for one public IP (we have 65535 ports where first 1024 are reserved). The second example of inside NAT is static one-2-one translation. Inside NAT allows us to hide the server real IP address (frequently used private IP range) and put it under public IP in the Internet as service for public use. Thanks to this we can hide our network infrastructure and additionaly again save our public IP range because all of our public services can be hosted under one IP.
The outside NAT translation changing destination IP address. It’s usful when our company has business connection to third party and they are using IP address that is already used in our network somewhere.

Let’s take a first example and try to configure inside and outside static NAT translation based on the below diagram.

First inside so source IP (from the LAN perspective) translation.
R2(config)#ip nat inside source static ?
A.B.C.D Inside local IP address
esp IPsec-ESP (Tunnel mode) support
network Subnet translation
tcp Transmission Control Protocol
udp User Datagram Protocol
R2(config)#ip nat inside source static 10.0.12.1 ?
A.B.C.D Inside global IP address
interface Specify interface for global address
R2(config)#ip nat inside source static 10.0.12.1 132.0.1.100

Inside done. All traffic from the PC with IP 10.0.12.1 will be NATed to the 132.0.1.100.
Next let’s define the server IP address (192.168.1.7) that will be used by local PC as destination IP.

R2(config)#ip nat outside source static ?
A.B.C.D Outside global IP address
network Subnet translation
tcp Transmission Control Protocol
udp User Datagram Protocol
R2(config)#ip nat outside source static 200.1.2.3 ?
A.B.C.D Outside local IP address
R2(config)#ip nat inside source static 10.0.12.1 132.0.1.100

We have to define the inside and outside interface.
R2(config)#int fa0/1
R2(config-if)#ip nat outside
R2(config-if)#int fa0/0
R2(config-if)#ip nat inside
R2(config-if)#no ip route-cache
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- --- --- 192.168.1.7 200.1.2.3
--- 132.0.1.100 10.0.12.1 --- ---

OK all done. Two static one2one translation have been added to the NAT table. It’s worth to mention here that this type of entry is kinf of reversible translation type – it’s possible to initiate connection from inside or from outside. In case of dynamic NAT it’s impossible to initiate connection from outside unless dynamic NAT with route-map and reversible option at the end is used.

Let’s run the debug IP packet and initiate test traffic doing telnet to outside local IP address – 192.168.1.7 from the PC.

R2#debug ip packet detail
IP packet debugging is on (detailed)
*Mar 1 02:32:44.819: IP: s=10.0.12.1 (FastEthernet0/0), d=192.168.1.7, len 44, unroutable
*Mar 1 02:32:44.823: TCP src=35649, dst=23, seq=391750710, ack=0, win=4128 SYN
*Mar 1 02:32:44.827: IP: tableid=0, s=10.0.12.2 (local), d=10.0.12.1 (FastEthernet0/0), routed via FIB
*Mar 1 02:32:44.831: IP: s=10.0.12.2 (local), d=10.0.12.1 (FastEthernet0/0), len 56, sending
*Mar 1 02:32:44.835: ICMP type=3, code=1

Hmm 192.168.1.7 is unroutable, does it mean that router first take routing decision before translation.
Here you are short list of Cisco IOS order of operation: 

  1. If IPsec, then check input access list
  2. Decryption—for Cisco Encryption Technology (CET) or IPsec
  3. Check input access list
  4. Check input rate limits
  5. Input accounting
  6. Policy routing
  7. Routing
  8. Redirect to Web cache
  9. NAT
  10. Crypto (check map and mark for encryption)
  11. Check output access list
  12. Inspect context-based access control (CBAC)
  13. TCP intercept
  14. Encryption
  15. Queueing

OK let’s add routing to the 192.168.1.7 and see what happens.
R2#*Mar 1 03:23:34.311: IP: tableid=0, s=10.0.12.1 (FastEthernet0/0), d=192.168.1.7 (FastEthernet0/1), routed via FIB ---Routing over Fa0/1
*Mar 1 03:23:34.315: NAT: s=10.0.12.1->132.0.1.100, d=192.168.1.7 [318] --- source NAT
*Mar 1 03:23:34.319: NAT: s=132.0.1.100, d=192.168.1.7->200.1.2.3 [318] --- destination NAT
*Mar 1 03:23:34.323: IP: s=132.0.1.100 (FastEthernet0/0), d=200.1.2.3 (FastEthernet0/1), g=10.0.23.3, len 44, forward
*Mar 1 03:23:34.327: TCP src=31740, dst=23, seq=1913933555, ack=0, win=4128 SYN

R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
--- ---                ---                192.168.1.7        200.1.2.3
tcp 132.0.1.100:31740  10.0.12.1:31740    192.168.1.7:23     200.1.2.3:23
--- 132.0.1.100        10.0.12.1          ---                ---

Connection initiated successfully. First SYN packet is routed and will be push out over Fa0/1 (red), next inside (source) and outside (destination) NAT is taking place. TCP source and destination ports 31740 and 23 respectively have been written in NAT translation table. Enjoy the NAT.

QoS with GRE and IPsec – qos pre-classify feature

Is it a issue to achive proper QoS for IP tunneled traffic over GRE encrypted by IPsec tunnel – for Cisco router is not the case. With use of GRE/IPsec ToS byte is copied from the original IP header to the new GRE and IPsec IP headers. It’s done by default without any specific configuration, this process is called the „ToS Byte Preservation” feature.
For example if router gets IP packet with DSCP value equal to 46 then packet is encapsulated in to GRE header, ToS byte is copied to the GRE IP header ToS field. In case this GRE packet is subject to IPsec encryption the same process occurs and ToS byte from GRE headers is copied into IPsec IP header – all is done by automatically. But what if QoS policy would classify and do action based on original source IP and specific TCP or UDP port. Solution is the QoS pre-classify feature. It allows router to temporarily copy and store the layer 3 and 4 headers from the original IP packet and take action based on these values so classify, queue and schedule on the router’s egress interface accordingly.

To achive above QoS feature have to be enabled both under GRE tunnel and IPsec crypto map as follows:
Router(config)#int tun 0
Router(config-if)#qos pre-classify
Router(config-if)#exit
Router(config)#crypto map MAPA 100 ipsec-isakmp
Router(config-crypto-map)#qos pre-classify

Now you are ready to go with class-map and policy-map. Remember that in this case policy needs to be assigned to physical interface where crypto map is configured already.

CoS and DSCP marking and remarking options on Catalyst switches

By default Cisco Catalyst switch does not take into account any bit from the Layer 2 CoS or Layer 3 ToS field. Does it mean that packets will be transmited in the original for and CoS/ToS fiels will be untouched.
Once we enable quality of service (QoS) for the entire switch using:
SW(config)#mls qosQoS will be enabled with the default parameters on all ports in the system. What it means that switch by default will remark CoS and ToS values to default 0 (zero).
Once we enable trusting under interface then system will analyze CoS and ToS fields. We have two options; trusting CoS or ToS (DSCP). If you would learn more about the QoS language take a look on this post.

Below you can find some examples and clarifications about sepcific options:

Trusting CoS
SW(config-if)#mls qos trust cos

  • Switch gets packet with CoS=5
  • Switch will pass through CoS value untouch, but DSCP will be rewritten based on the map table (by default CoS 5 will set DSCP to 46)
  • Conclustion: DSCP value is set based on the mls qos map cos-dscp

Trusting DSCP
SW(config-if)#mls qos trust dscp

  • Switch gets packet with CoS=4 and DSCP=46
  • Switch will pass through DSCP value untouch but CoS will be rewritten based on the map table (by default DSCP will rewrite CoS to 5 )
  • Conclusion: CoS value is set based on the mls qos map dscp-cos

Assigning CoS to port
SW(config-if)#mls qos cos 5

  • Switch gets packet on CoS untrusted port without QoS field, so it’s kind of untagged frame without 802.1p field(like in case of native VLAN)
  • Switch sets default CoS value that is assigned to the port, in this case CoS 5 (by default is 0). Marked value (CoS 5) later on is used to mark DSCP based on the mls qos map cos-dscp.
  • Conclusion: CoS value is set for all non capable 802.1p tag (layer 2 QoS field) frames

CoS overriding
SW(config-if)#mls qos cos 5
SW(config-if)#mls qos cos override

  • Switch gets tagged frame with CoS value of 4
  • Switch will tag frame with CoS value of 5 then it’s used to mark DSCP base on the mls qos map cos-dscp.
  • Conclusion: switch sets CoS for all frames even if they have CoS value already assigned to (base on the value in mls qos cos x)

Trusting DSCP just from Cisco IP Phone
SW(config-if)#mls qos trust dscp
SW(config-if)#mls qos trust device cisco-phone

  • Switch has Cisco IP Phone connected (phone’s visible over CDP) that sends frames with DSCP=46
  • Switch will pass through DSCP value untouch, CoS will be marked based on the mls qos map dscp-cos
  • Conclusion: trusting DSCP value only when a Cisco Phone is connected and reported via CDP on the respective interface; works in conjunction with the mls qos trust dscp and mls qos trust cos commands

Here you are QoS settings for not connected port (base on the above configuration):
SW#sh mls qos interface gi1/0/1
GigabitEthernet1/0/1
trust state: not trusted
trust mode: trust dscp
trust enabled flag: dis
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based

And here you are QoS settings output once we connected Cisco IP Phone to the port:
SW#sh mls qos interface gi1/0/1
GigabitEthernet1/0/1
trust state: trusted
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based

as you can notice enabled flag field has changed to ena (enabled) and trust state changed to trusted state, so port is ready to trust DSCP.

No DSCP/IPP to CoS rewriting (3550 only)
SW(config-if)#mls qos trust dscp pass-through cos

  • Switch gets packet with DSCP=46 and CoS=0
  • Switch will pass through DSCP and CoS value untouch, so DSCP=46 and CoS=0
  • Conclustion: switch does not remark CoS value

No CoS to DSCP rewrite (2960, 3560, 3750 only)
SW(config)#no mls qos rewrite ip dscp
SW#show mls qos
QoS is enabled
QoS ip packet dscp rewrite is disabled

  • Switch gets packet with DSCP=46
  • Switch will pass through DSCP value untouch
  • Conclustion: CoS will be trusted, DSCP will be preserved, switch does not modify DSCP value, leave it default as it is in the outgoing packet

Matching traffic with specific DSCP value in ACL (VLAN-Based) SW(config)#interface FastEthernet 1/1
SW(config-if)#switchport access vlan 100
SW(config-if)#switchport voice vlan 110
SW(config-if)#spanning-tree portfast
SW(config-if)#mls qos vlan-based
SW(config-if)#srr-queue bandwidth shape 10 0 0 0
SW(config-if)#srr-queue bandwidth share 10 30 40 20
SW(config-if)#queue-set 1
SW(config-if)#priority-queue out
SW(config-if)#ip access-list extended RTP
SW(config-ext-nacl)#permit udp any any range 16384 32767 dscp 46
SW(config-ext-nacl)#class-map match-any VOICE
SW(config-cmap)#match access-group name RTP
SW(config-cmap)#policy-map POLICY-VOICE
SW(config-cmap)#class VOICE
SW(config-pmap-c)#set dscp af31
SW(config-pmap-c)#interface vlan 110
SW(config-if)#service-policy input POLICY-VOICE

  • Switch gets packet with DSCP=46 and CoS=0
  • Switch will set DSCP to 26 and CoS value based the mls qos map dscp-cos map table
  • Conclustion: mls qos vlan-based overrides QoS interfaces level trusting seetings, port will not clear the CoS/DSCP field even that we don’t have trusting under policy, CoS/DSCP will be preserve and can be match by class-map
  • If you have more or better example please share with us under comments. Enjoy!

    Testing MTU with ping tool

    Ping tool is very usful to discover or understand some network behaviours related to network protocols or services that are run on Cisco routers or MS Windows. Before we start with ping test, first of all we have to know how this tool has been deployed in both systems.

    Datagram/Packet size (IP Total Length field) = IP Header + Payload
    As name imply it’s datagram/packet size so IP Header + Payload.

    With Cisco IOS the case is simple. In below example packet size is equal to 1000 bytes, it means that ICMP Echo ping message will be generated with standard 20 bytes for IP Header + 980 for ICMP Payload (ICMP type field: 1B, code: 1B, checksum: 2B, identifier: 2B, sequence number: 2B, data: 972B).

    R1#ping 10.0.23.3 repeat 1 size 1000
    Type escape sequence to abort.
    Sending 1, 1000-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
    !
    Success rate is 100 percent (1/1), round-trip min/avg/max = 80/80/80 ms

    In case of Windows OS it’s more complicated. We can define specific data size (don’t mix up it with payload) so in this example 1000B means exactly ICMP data in payload + fields in ICMP + IP Header. In this case IP packet size will have 20 bytes for IP Header + 1008 bytes for ICMP Payload (ICMP type field: 1B, code: 1B, checksum: 2B, identifier: 2B, sequence number: 2B, data: 1000B). So in case of Ethernet network frame will have 1042B (14B Ethernet II Header included). 

    C:\>ping 10.0.10.1 -l 1000 -n 1

    Here you can find sniff of ICMP echo request based on the Windows ping tool.

    To recap:
    Cisco ping size = total IP packet length
    Windows ping size = just ICMP data without ICMP 8B fields like type, code, checksum, identifier and sequence.

    Fragmentation and Maximum Transmission Unit (MTU)

    For IP protocol MTU defines size of IP packet (so IP Total Length field) can can be send thru network device interface. As packets are encapsulated into frame in data link layer they have to be small enough to be transmited by the physical transmission technology.  In case packet is larger then maximum size of underlying network technology there is need to divide an IP packet in to smaller IP chunks. This process is called as IP fragmentation, puttin chunks all together back on the second end of the transmission is called as reassemble, the reassemble of IP packets is done on the IP destination end.

    Fragmentation issues

    Fragmentation couse more overhead for the receiver then to sender. Device responsible for fragmentation needs to create new header and devide orignal pacekts into fragments. From the other side receivermust allocate memeory to properly serve all fragments and consolidate them all togther. It is not a issue for final destinatio like a host but could couse a problem for routers.

    Several issues related to IP fragmentation that couse that is should be avoided:

    • Requires the support of slow path processing on the routers and additionaly use CPU of the receiver part  to reassemble the fragments (forwarding functions is done by software so process switched). 
    • In case router gets fragmented needs to do IP reassembling it reserve the largest buffer available with which to work because it has no idea what size of the original IP packet will be get.
    • If one fragment of an IP packet is dropped, then the entire IP packet must be resend and fragmented again.

     Fragmentation with GRE and IPsec tunnel

    The biggest issue with IP fragmentation is related to GRE tunnel. Let’s take a look on the following example. Router A gets 1476B packet then adds GRE header into and sends to tunnel destination. Assume there is a router in the MPLS cloud with link MTU 1400B. This router will fragment GRE packet (GRE IP header, inner origanl IP and TCP headers will be only in the first fragment), in this case GRE tunnel destination router must reassemble the fragmented packets.

    To avoid IP fragmentation the best way is to increase the MTU on whole packet way (so on each router on the path), in case of MPLS provider is not the issue because more and more vendors already increased this value up to 1600B to support IPsec or GRE without any problems. In case provider does not support higher MTU or transmit network is Internet we have three options: decrease IP MTU on tunnel interface, adjust MSS value or use PMTUD.  Let’s move from fragmentation theory and take a look how to take advantage of ping to discover the fragmentation issue related to MTU on the packet way and how it can be avoided.

    Example – pure network

    Suppose that we have pure network enviroment, two CE routers one in branch A and second one in remote branch B, we would confirm that MTU on the path especially minimum MTU in the provider MPLS cloud is equal to 1500B.

    To test the MTU on the path the best option is to send the packets each time incrementing overall size. Extended ping feature with sweep option is perfect in this case. In the below example we do send ICMP echo request eith overall size equal to 1490B, we set sweep max size to 1510B where weep interval so we are going to increment each packet by 1B. Important option in this example is setting of Don’t Fragment bit.
    R1#p
    Protocol [ip]:
    Target IP address: 10.0.23.3
    Repeat count [5]:
    Datagram size [100]:
    Timeout in seconds [2]:
    Extended commands [n]: y
    Source address or interface:
    Type of service [0]:
    Set DF bit in IP header? [no]: y
    Validate reply data? [no]:
    Data pattern [0xABCD]:
    Loose, Strict, Record, Timestamp, Verbose[none]:
    Sweep range of sizes [n]: y
    Sweep min size [36]: 1490
    Sweep max size [18024]: 1510
    Sweep interval [1]:
    Type escape sequence to abort.
    Sending 105, [1490..1510]-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
    Packet sent with the DF bit set
    !!!!!!!!!!!..........!!!!!!!!!!!..........!!!!!!!!!!!..........!!!!!!!
    !!!!..........!!!!!!.
    Success rate is 54 percent (50/91), round-trip min/avg/max = 40/99/224 ms

    We have sent out 10 ICMP echo request starting from 1490B and we have got 10 responses, but next 10 pacets has not been answered at all, it’s means that packets was not be able to reach a final destination due to MTU, in fact pacekts longer then 1500B even has not been routed and leave router. Tested router has MTU equal 1500B configured on the interfaces so in the debug you can show that packets longer then 1500B has been routed just by FIB not by RIB like others.
    *Mar 1 00:16:42.179: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
    *Mar 1 00:16:42.183: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1499, sending
    *Mar 1 00:16:42.183: ICMP type=8, code=0
    *Mar 1 00:16:42.219: IP: tableid=0, s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), routed via RIB
    *Mar 1 00:16:42.223: IP: s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), len 1499, rcvd 3
    *Mar 1 00:16:42.227: ICMP type=0, code=0
    *Mar 1 00:16:42.231: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
    *Mar 1 00:16:42.231: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1500, sending
    *Mar 1 00:16:42.231: ICMP type=8, code=0
    *Mar 1 00:16:42.283: IP: tableid=0, s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), routed via RIB
    *Mar 1 00:16:42.287: IP: s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), len 1500, rcvd 3
    *Mar 1 00:16:42.291: ICMP type=0, code=0
    *Mar 1 00:16:42.299: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
    *Mar 1 00:16:42.299: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1501, sending
    *Mar 1 00:16:42.303: ICMP type=8, code=0
    *Mar 1 00:16:44.295: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
    *Mar 1 00:16.:44.299: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1502, sending

    Router sends 20 packets (starting from 1490 up to 1510, later on starting process again this is why we see exclamation mark and dots and exclamation again). We have sent 10 packets to starting from 1490 + 10 it means that last one was 1500B long and the router has 1500B MTU configured and droped the packets because was not able to fragment it due to DF bit set. The propose of this example was just to show way of test.

    Example 2 – GRE over IPsec

    Fragmentation can be a issue in case of use GRE over IPsec where end point that terminates the IPsec tunnel has to add GRE Header and next encrypts it all together. GRs header adds 24B to the packet, IPsec with ESP 56B so we have 80B overhead. As we have mentioned the best option to use in this case is PMTUD but what if routers on the path blocks the ICMP messages then the best option is to use optimum MTU size under tunnel GRE interface. GRE source router then will responsible for IP fragmentation befrore adding GRE and IPsec headers. To calulate the the MTU for tunnel the best option is to use sweep ping as above.

    Let’s assume that we have GRE/IPsec between R1 and R3. We have experience issues related to the slow response time of application and high CPU on the R3 router. We expect that IP fragmentation is a culprit. We would to figure out what minimal MTU is on the path to adjust tunnel MTU to avoid IP fragmentation.
    We are not able to ping with DF bit set to simulate traffic with GRE/IPsec because router will not copy DF bit in to IPsec header ( GRE tunnel cleares DF bit unless we use tunnel path-mtu discovery under tunnel GRE), istead of this we have to ping pure IP so for example remote head end of IPsec tunnel and be sure that this traffic will not be encrypted.

    Test – test of minimal MTU on the path

    R1#ping
    Protocol [ip]:
    Target IP address: 10.0.23.3
    Repeat count [5]:
    Datagram size [100]:
    Timeout in seconds [2]:
    Extended commands [n]: y
    Source address or interface:
    Type of service [0]:
    Set DF bit in IP header? [no]: y
    Validate reply data? [no]:
    Data pattern [0xABCD]:
    Loose, Strict, Record, Timestamp, Verbose[none]:
    Sweep range of sizes [n]: y
    Sweep min size [36]: 1300
    Sweep max size [18024]: 1500
    Sweep interval [1]:
    Type escape sequence to abort.
    Sending 1005, [1300..1500]-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
    Packet sent with the DF bit set
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M
    .M.M.M.
    Success rate is 68 percent (101/147), round-trip min/avg/max = 4/19/60 ms

    After 101 successful request so we get response for ICMP with 1300B lenght until 1400B so the minimal MTU on the path is 1400B. M means could not fragment. Then recomended is to lower IP MTU under GRE to minimal MTU on the path – 80B (24B for GRE and 56B for ESP tunnel IPsec).

    To read more about IP Fragmentation, MTU, MSS and PMTUD issues with GRE and IPsec I recomend to read this very good and interesting Cisco Technology White Paper.

    GET VPN with pre-share keys – configuration example

    As I have promised I would present the basic configuration process of GET VPN.

    In the production enviroment GET VPN technology will be deployed over MPLS WAN. In case MPLS network, CE routers exchange routing with PE routers so pure IP communications is achived between LAN to LAN (branch to branch). Additionaly each CE is aware that to route the traffic to specific CE (to CE’s MPLS interface IP) it has to push the traffic towards MPLS cloud.

    We can imagine that my example presents part of MPLS WAN with Group Members (GM) as R2, R3 and Key Server (KS) as R4 that is located somewhere in Company HQ DC. To simplify the lab enviroment all GM routers are placed in one 10.0.0.0/24 subnet, GM example will be configured on R2 (R1 and R3 will be configured similar, just different keys used). The main propose of GET VPN is to establish secure, efficient on demand any to any connectivity across private WAN. In the following example we achived encryption for branch to branch traffic (assumed that 10.0.x.x/16 IP addressing is used for branches).

    Below IP addressing and LAB diagram:

    • R1 (GM) – 10.0.0.1
    • R2 (GM) – 10.0.0.2
    • R3 (GM) – 10.0.0.3
    • R4 (KS) – 10.0.14.4

    Here you can find basic configuration steps to properly setup GET VPN architecture:

    Group Member configuration

    1. Internet Key Exchange (IKE) Phase 1

    The same like in pure IPsec VPN we have to define ISAKMP policy on each GM and KS, so specify the encryption and hash algorithm, authentication method, Diffie-Hellman group and lifetime. As always all IKE Phase 1 parameters must match both sides to successfully established Phase 1.

    I’m going to use 3DES as encryption algorithm and pre-share keys as authentication method, remaining will be default.
    R2(config)#crypto isakmp policy 100
    R2(config-isakmp)# encr 3des
    R2(config-isakmp)# authentication pre-share
    R2#show crypto isakmp policy
    Global IKE policy
    Protection suite of priority 100
    encryption algorithm: Three key triple DES
    hash algorithm: Secure Hash Standard
    authentication method: Pre-Shared Key
    Diffie-Hellman group: #1 (768 bit)
    lifetime: 86400 seconds, no volume limit
    Default protection suite
    encryption algorithm: DES - Data Encryption Standard (56 bit keys).
    hash algorithm: Secure Hash Standard
    authentication method: Rivest-Shamir-Adleman Signature
    Diffie-Hellman group: #1 (768 bit)
    lifetime: 86400 seconds, no volume limit

    It is possible to use the same pre-share key in whole GET VPN enviroment then each GM and KS needs just one kind of default pre-share key definition that looks like this one:
    crypto isakmp key KEY address 0.0.0.0 0.0.0.0
    Of course it is less secure solution then different key for each GM, but the best way of course is PKI architecture. For the LAB propose I use the different KEY for each GM. On R2 we have to defined KEY with peer address as KS so it will 10.0.14.4 IP address.
    R2(config)#crypto isakmp key 0 R2-KEY address 10.0.14.4
    The same key has to be configured on the KS with R2 as GM peer IP address 10.0.0.2.

    2. Group Domain of Interpretation (GDOI) definition

    After ISAKMP policy configuration we have to define GDOI on GM. Just two parameters are needed to properly define GDOI group on GM:

    • GDOI group identity number
    • KS IP address for that specific GDOI

    R2(config)#crypto gdoi group GDOI-GROUP
    R2(config-gdoi-group)#identity number 777
    R2(config-gdoi-group)#server address ipv4 10.0.14.4

    The GDOI-GROUP has been defined with identity number 777 that uniquely assign GMs to specific GDOI group on the KS and allows push the proper IPsec policy to them. Additionaly KS IP address has been configured, then GMs are aware to which KS they have to register.

    3. GDOI crypto map configuration on GM
    GDOI crypto map needs to be defined and GDOI-GROUP configured in point 2 is connected here.

    R2(config)#crypto map GETVPN-MAP 100 gdoi
    % NOTE: This new crypto map will remain disabled until a valid
    group has been configured.
    R2(config-crypto-map)#set group GDOI-GROUP

    4. Apply GDOI crypto map to interface
    The last step for GM is similar to the standard IPsec configuration, apply the crypto map to the external interface.
    R2(config)#int fa0/0
    R2(config-if)#crypto map GETVPN-MAP

    As we see configuration of GET VPN and all IPsec parameters for GM is minimalized and thanks to this we have simply, fast and straight GET VPN deployment for CE routers. All IPsec policy is configured centrally on Key Server. Let’s take a look on the configuration of management router – Key Server.

    Key Server configuration

    1. Internet Key Exchange (IKE) Phase 1

    As you are aware all IKE Phase 1 parameters must match both sides to successfully established Phase 1, so like on GM we have to define the same IKE policy here on KS:
    R4(config)#crypto isakmp policy 100
    R5(config-isakmp)# encr 3des
    R4(config-isakmp)# authentication pre-share

    As we have used the pre-share key authentication on GMs here we have to defined keys for each GM.
    R4(config)#crypto isakmp key R1-KEY address 10.0.0.1
    R4(config)#crypto isakmp key R2-KEY address 10.0.0.2
    R4(config)#crypto isakmp key R3-KEY address 10.0.0.3

    2. IPsec Phase 2 parameters – IPsec SA (transform-set and ipsec profile)
    IPsec transofrm set defines the true IPsec encryption and authentication algorithms. 3DES and SHA with ESP have been used here. This IPsec policy will be part of GET VPN policy for specific GDOI group.
    R4(config)#crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
    IPsec transform set is defined under ipsec profile named GETVPN-PROFILE.
    R4(config)#crypto ipsec profile GETVPN-PROFILE
    R4(ipsec-profile)# set transform-set TRANSFORM-SET

    3. Group Domain of Interpretation (GDOI) definition

    RSA keys generation
    First of all we have to generate the RSA keys. RSA key is generated only on the KS and is used to authenticate and sign rekey messages. The public key is sent to GMs at the registration. KS signs the rekeys with the private key and GMs verify the rekey messages using the public key. Additonaly public key of first KS has to be used by other KSs in case we would use redundant solution and ensure fault recovery architecture with more then one KS, this option is called as cooperative (COOP) KS. In case RSA keys need to be generated in exportable form and then imported to the redundant KSs.
    R4(config)#crypto key generate rsa general-keys label GETVPN-R4-KS modulus 1024 exportable
    The name for the keys will be: GETVPN-R4-KS
    % The key modulus size is 1024 bits
    % Generating 1024 bit RSA keys, keys will be exportable...[OK]
    R4(config)#

    GDOI group identity – config-gdoi-group mode
    Once we have generated KS’s RSA keys we are able to start true GDOI group configuration, all configuration will be done under config-gdoi-group mode. First we have to confiugre the same identity number that we have deifned on GM, it’s 777:
    R4(config)#crypto gdoi group GDOI-GROUP
    R4(config-gdoi-group)#identity number 777

    Local Key Server identification – gdoi-local-server mode
    To designate a device as GDOI KS and enter GDOI local server configuration mode we have to enter server local command, then we will be able to configure all GDOI parameters that are related to the IPsec and rekey policy:
    R4(config-gdoi-group)#server local
    R4(gdoi-local-server)#

    GDOI Rekey configuration
    First step in GDOI policy is rekey parameters configuration, rekey authentication key pair (PKI or localy stored) and Key Server source address for rekey messages are required values to configure, additionaly we can define rekey retransmit timers.
    R4(gdoi-local-server)#rekey authentication mypubkey rsa GETVPN-R4-KS
    R4(gdoi-local-server)#address ipv4 10.0.14.4
    R4(gdoi-local-server)#rekey retransmit 10 number 3

    10.0.14.4 IP has been defined as source IP for rekey messages, localy generated RSA keys in point 3 will be used to authenticate rekey messages, additionaly rekey mechanism will be send with three retransmits at 10 second intervals.

    IPsec policy configuration for the GDOI group
    The IPsec policy defined under GDOI group at KS will be downloaded to all GMs. This global policy will exactly provides the IPsec parameters for phase 2. Policy defines IPsec encryption, authentication algorithms and define the crypto ACL that says interesting traffic for encryption, so it’s exactly what have been missed on GMs. So all what have been configured on each peer in case of pure IPsec site to site VPN now is confiugred only on the KS. We are able to manage and provision configuration from just one point of network to all GMs.

    To configure the IPsec policy we have to first define the crypto ACL, we have to exclude the GDOI protocol and OSPF from the interesting traffic for IPsec encryption:

    R4(config)#ip access-list extended CRYPTO-ACL
    R4(config-ext-nacl)#deny udp any eq 848 any eq 848
    R4(config-ext-nacl)#deny tcp any host 224.0.0.5
    R4(config-ext-nacl)#deny tcp any host 224.0.0.6
    R4(config-ext-nacl)#permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

    Having ACL in place we can define the IPsec policy for GDOI group, we bind ipsec profile GETVPN-PROFILE that defines the transofrm set and crypto acl together under IPsec Security Association:

    R4(config-ext-nacl)#crypto gdoi group GDOI-GROUP
    R4(config-gdoi-group)#server local
    R4(gdoi-local-server)# sa ipsec 1
    R4(gdoi-sa-ipsec)#profile GETVPN-PROFILE
    R4(gdoi-sa-ipsec)#match address ipv4 CRYPTO-ACL

    That’s all GET VPN configured, up and running. Let’s see completed R4 configuration that is related to the GET VPN:
    ip domain name netcontractor.pl
    !
    crypto isakmp policy 100
    encr 3des
    authentication pre-share
    crypto isakmp key R1-KEY address 10.0.0.1
    crypto isakmp key R2-KEY address 10.0.0.2
    crypto isakmp key R3-KEY address 10.0.0.3
    !
    crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
    !
    crypto ipsec profile GETVPN-PROFILE
    set transform-set TRANSFORM-SET
    !
    crypto gdoi group GDOI-GROUP
    identity number 777
    server local
    rekey retransmit 10 number 3
    rekey authentication mypubkey rsa GETVPN-R4-KS
    rekey transport unicast
    sa ipsec 1
    profile GETVPN-PROFILE
    match address ipv4 CRYPTO-ACL
    replay counter window-size 64
    address ipv4 10.0.14.4
    !
    ip access-list extended CRYPTO-ACL
    deny udp any eq 848 any eq 848
    deny tcp any host 224.0.0.5
    deny tcp any host 224.0.0.6
    permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

    To see the configuration of the GDOI group:
    R4#show crypto gdoi group GDOI-GROUP
    Group Name : GDOI-GROUP (Unicast)
    Group Identity : 777
    Group Members : 2
    IPSec SA Direction : Both
    Active Group Server : Local
    Group Rekey Lifetime : 86400 secs
    Group Rekey
    Remaining Lifetime : 84481 secs
    Rekey Retransmit Period : 10 secs
    Rekey Retransmit Attempts: 3
    Group Retransmit
    Remaining Lifetime : 0 secs
    IPSec SA Number : 1
    IPSec SA Rekey Lifetime: 3600 secs
    Profile Name : GETVPN-PROFILE
    Replay method : Count Based
    Replay Window Size : 64
    SA Rekey
    Remaining Lifetime : 1682 secs
    ACL Configured : access-list CRYPTO-ACL
    Group Server list : Local

    To see reigsitered GMs:
    R4#show crypto gdoi ks members
    Group Member Information :
    Number of rekeys sent for group GDOI-GROUP : 1
    Group Member ID : 10.0.0.2
    Group ID : 777
    Group Name : GDOI-GROUP
    Key Server ID : 10.0.14.4
    Rekeys sent : 1
    Rekeys retries : 3
    Rekey Acks Rcvd : 0
    Rekey Acks missed : 0
    Sent seq num : 1 2 3 4
    Rcvd seq num : 0 0 0 0
    Group Member ID : 10.0.0.3
    Group ID : 777
    Group Name : GDOI-GROUP
    Key Server ID : 10.0.14.4
    Rekeys sent : 0
    Rekeys retries : 0
    Rekey Acks Rcvd : 0
    Rekey Acks missed : 0
    Sent seq num : 0 0 0 0
    Rcvd seq num : 0 0 0 0

    I hope this post will be helpfull to understand the base configuration steps for the GET VPN with pre-share keys.

    Shaped Round Robin notes – Egress Queuing on Cisco 3560-E & 3750-E

    Below you can find SRR fast notes regarding Egress Queuing on Cisco 3560-E & 3750-E.

    • Shaped Round Robin (SRR)
    • SRR – shape mode (srr-queue bandwidth shape)  > BW restriction = policing
    • SRR – share mode (srr-queue bandwidth share) > guaranteed BW based on weight
    • shape overrides share
    • 4 egress queues
    • priority-queue out on an interface, it turns Queue 1 (always Q1) into priority queue
    • WTD – Weighted Tail Drop – queue length
    • queue set 1 is assigned to all ports by default
    • 0 (zero) means that queue works in the shared mode
    • queue can be configured per port basic

    To show default queue configuration use below command:
    Switch> show mls qos queue-set
    Queueset: 1
    Queue   :        1       2       3       4
    ----------------------------------------------
    buffers   :      25      25      25      25
    threshold1:      100     200     100     100
    threshold2:      100     200     100     100
    reserved  :      50      50      50      50
    maximum   :      400     400     400     400
    Queueset: 2
    Queue   :        1       2       3       4
    ----------------------------------------------
    buffers   :      25      25      25      25
    threshold1:      100     200     100     100
    threshold2:      100     200     100     100
    reserved  :      50      50      50      50
    maximum   :      400     400     400     400

    Queue map
    To map specific cos or dscp values to Queue 1,2,3 or 4 and to threshold 1 or 2 use below command, example shows that DSCP 16 17 18 19 will be assigned to queue 1 and threshold 1:
    mls qos srr-queue output dscp-map queue 1 threshold 1 16 17 18 19
    Queue configuration (queue-set) – buffer and threshold
    Detail explanation of the Buffer, Memory and Thresholds allocation you can find in this post.
    To configure the queue-set buffer percentage use below command:mls qos queue-set output QS-ID buffers Q1% Q2% Q3% Q4%
    To configure the queue-set threshold values use below command:mls cos queue-set output QS-ID threshold Q1 DT1 DT2 RT MT

    Egress Queue Buffer, Memory and Threshold Allocation on Cisco 3560-E & 3750-E

    In the following post you can find details about egress Queue Buffer, Memory and Threshold Allocation on Cisco 3560-E & 3750-E. Hope this clarifies you the strange Cisco concept.

    Buffer allocation is interface bandwidth allocation control how much data can be buffered and sent. Bandwidth is allocated as percentage of interface bandwidth (ratio weight of the frequency in which the SRR scheduler sends packets from each queue).

    The buffer space (whole blue outline on the diagram) is divided between the Common Pool (yellow field) and the Reserved Pool (green, blue, orange, red areas are reserved pools for each queue). Cisco defined Common Pool as 400% of interface resources, so each queue is defined as 100% of interface resources. Each queue has reserved pool of interface resources, unreserved space is allocated to the Common Pool and can be used by remaining queues.

    In case traffic in target queue has to consumed whole queue’s interface resources (100%) and even more over 100% then switch can allocate buffer space from the Common Pool (if it is not empty, what it means is that remaining queues don’t use all queues’ resources). If there are no free buffers in the Common Pool the switch drops the frames.

    Let’s take a look on the following diawing example.

    In this case Reserved Pool (Reserved Treshold) for queue 1 has been defined at the level of 80%, additionaly remaining unreserved pools from Q1, Q2, Q3 and Q4 tottaly 200% is is going to the Common Pool.

    In case WTD Drop Threshold 2 that is on the level of 180% is exceeded the packets are dropped. Maximum Treshold for the Q1 is set on the level of 220% so up to this level traffic can be used from the Common Pool, but in this case it not a make sense because frames will be droped sooner due to WTD Drop Threshold 2.

    OSPF Area Types and LSA Propagation

    The idea of this post is to show the LSA propagation manner depending on area type.

    OSPF routing protocol has hierarchical network topology that use concept of area. OSPF area reduces the protocol’s impact on CPU and memory. Resources can be saved by blocking the propagation of some type of LSA to specific areas. Lets recall the LSA types to see how they are propagated between areas.

    LSA Types

    • LSA 1 – O, Router LSA contains all Link IDs – network, generated by every router and is local to the area
    • LSA 2 – O, Network LSA contains all routers attached to the segment, generated by DR and is local to the area
    • LSA 3 – O IA, Network Summary LSA describes network from another area, generated by ABR and is propagated between areas
    • LSA 4 – O IA, Summary ABR Link States, describes the presence of an ASBR, generated by the ABR and is propagated between areas
    • LSA 5 – O E1, O E2, External Link States, generated by ASBR and is propagated between areas
    • LSA 7 – O N1, O N2, NSSA External Link States, generated by ASBR into NSSA area and is propagated into area 0 as E1 or E2

    Knowing the LSA types we have to state one important OSPF protocol rule that allows devides entire OSPF domain to smaler areas. A OSPF router must share an identical link-state database only with the other routers in its area, not with the entire OSPF domain. Does it mean for example that internal router in area 2 does not need to know about LSA generated by the internal router in area 1 or by ASBR in area 3 that redistributes routes from another routing domain.

    Basically OSPF area types can be devided into three types: Normal/Standard Area, Stub Area and Not-So-Stubby. The difference is that Standard gets all LSA types but Stub and Not-So-Stubby Areas have some LSA limitation. It’s worth to mention that OSPF have few variations of Stub and Not-So-Stubby. Below you can find OSPF domain diagram that shows which LSA type is or is not propagated into specific area type and explanation of each area type.

    Here you are the basic keyword and rule that help you understand the concept:

    Words “Totally Stubby” = “no-summary” keyword in the area type command definition = no LSA Type 3,4 and 5 propagation into area instead ABR produce default route as Intra Area LSA (O*IA 0.0.0.0/0) into Totally Stubby Area.

     

     

    Stub Area – area <area> stub

    Allows propagation of LSA type 1,2 and 3  additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

    Blocks propagation of LSA type 4 and 5

    • Stub area can not be a transit area for Virtual link, but a GRE tunnel can be used instead
    • Stub area can not have an ASBR
    • The Backbone area can not be configured as a Stub area
    • No LSA type 4 and 5 (E1 or E2) is allowed in a Stub area, but the routers in the Stub Area can connect to the External routes via the default route that is injected into the area by the ABR
    • Every router and the ABR of that area should have „area <area> stub” command
    • By default, the cost of the default route is 1
    • The cost of the default route can be changed by “area <area> default-cost <cost>”

    Totally Stubby – area <area> stub no-summary  

    Allows propagation of LSA type 1 and 2 additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

    Blocks propagation of LSA type 3,4 and 5

    • This area has the same features as standard Stub Area
    • Only ABR has to be configured with the “no-summary” keyword in area definition
    • Intra area routers in the Totally Stubby area should have „area <area> stub” command only

    Not-So-Stubby – area <area> nssa

    Allows propagation of LSA 1, 2, 3 and 7

    Blocks propagation of LSA type 3,4 and 5, no default route

    • All Intra Area routers in the Not-So-Stubby area should have „area <area> nssa” configured
    • Not-So-Stubby area can not be a transit area for Virtual link, but a GRE tunnel can be used instead
    • No LSA type 3,4 and 5 (E1 or E2) is allowed in a Not-So-Stubby area, but external routes can be injected into area and appear as LSA type 7, then translated on the ABR to LSA type 5
    • Not-So-Stubby area can have an ASBR
    • The backbone area can not be configured as a Not-So-Stubby area

    Totally Stubby Not-So-Stubby – area <area> nssa no-summary

    Allows propagation of LSA 1 and 2 additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

    Blocks propagation of LSA type 3,4 and 5

    • This area has the same features as standard Not-So-Stubby the only one difference is that default route as Intra Area LSA format (O*IA 0.0.0.0/0) is produced

    Not-So-Stubby – area <area> nssa default-information-originate

    Allows propagation of LSA type 1, 2, 3 and 7 additionally with default route as LSA type 7 Eternal 2  LSA format (O*N2 0.0.0.0/0)

    Blocks propagation of LSA type 4 and 5

    • This area has the same features as standard Not-So-Stubby the only one difference is that default route as LSA type 7 Eternal 2  LSA format (O*N2 0.0.0.0/0) is produced

    Totally Stubby Not-So-Stubby – area <area> nssa no-summary no-redistribution

    Allows propagation of LSA 1 and 2 additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

    Blocks propagation of LSA type 3,4 and 5

    • This area has the same features as standard Not-So-Stubby the only one difference is that prefixes that have been redistributed on the ABR will not be propagated into area

    QoS template – bandwidth dependency calculation

    Cisco QoS features like LLQ and CBWFQ let us to prioritize and guarantee delay and bandwidth for defined class of traffic.
    CBWFQ configuration allows to configure the BW requirements for specific class of service. First we have to defined the class and match the specific type of traffic, then assign BW limit in the policy that will be reserverd during interface congestion. Standard bandwidth command with BW in Kbps under class can be used for above. The drawback of this type of configuration is need to adjust the BW speed definition each time once we have changed the access speed.

    IOS allows to tune the QoS configuration to define kind of QoS template that will use BW class ratio accross function similar devices without need for reconfiguration of BW parameters each time when access speed change. LLQ defines the priority queue for the delay sensetive traffic. Additionaly for business critical traffic CBWFQ needs to be configured. We have two options to confgure the QoS template: bandwidth percent and bandwidth remaining percent per class options.

    I have defined 4 classes that will be used to presents configuration options.
    class-map match-all TELNET
     match protocol telnet
    class-map match-all HTTP
     match protocol http
    class-map match-all SMTP
     match protocol smtp
    class-map match-all VoIP
     match protocol rtp

    Option 1 – bandwidth percent
    First option to define BW template is to use bandwidth percent command instead of just bandwidth under class in policy map configuration. BW will be calculated based on the interface’s BW, so in case Fast Ethernet it will be 100Mbps. Priority percent 10 for PQ or bandwidth percent 10 in CBWFQ it’s 10% of 100Mbps.

    By default, available interface BW is defined based on the physical port speed unless you configure the bandwidth command under interface to set access speed to something less (SLA access). Additionaly Cisco IOS has Default Class (class-default) with reserved the 25% of interface BW that match all undefined traffic (you can change it with max-reserved-bandwidth command under interface mode).

    Let’s configure the first policy based on option 1:
    R1(config)#policy-map LLQ
    R1(config-pmap)#class VoIP
    R1(config-pmap-c)#priority percent 10
    R1(config-pmap-c)#class HTTP
    R1(config-pmap-c)#bandwidth percent 10
    R1(config-pmap-c)#class SMTP
    R1(config-pmap-c)#bandwidth percent 50
    R1(config-pmap-c)#class TELNET
    R1(config-pmap-c)#bandwidth percent 30

    The first way choice is to configure the bandwidth percent to fil 100% of interface speed, but due to class-default the available BW to share is 75%. In the above example we have defined 4 classed and assigned 100% of interface BW, here let’s try to assign the LLQ policy to the inerface:
    R1#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    R1(config)#int fa0/0
    R1(config-if)#service-policy output LLQ
    I/f FastEthernet0/0 class TELNET requested bandwidth 30%, available only 5%
    R1(config-if)#

    We can observe the error message that is saying that we have just 5% of available BW, this is due to 25% reserved for default class. OK so let change reserved BW for TELNET to 5%, assign policy to the interface and see the policy.
    R1#show policy-map interface fastEthernet 0/0
     FastEthernet0/0
      Service-policy output: LLQ
        Class-map: VoIP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol rtp
          Queueing
            Strict Priority
            Output Queue: Conversation 264
            Bandwidth 10 (%)
            Bandwidth 10000 (kbps) Burst 250000 (Bytes)
            (pkts matched/bytes matched) 0/0
            (total drops/bytes drops) 0/0
        Class-map: HTTP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol http
          Queueing
            Output Queue: Conversation 265
            Bandwidth 10 (%)
            Bandwidth 10000 (kbps)Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
            (depth/total drops/no-buffer drops) 0/0/0
        Class-map: SMTP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol smtp
          Queueing
            Output Queue: Conversation 266
            Bandwidth 50 (%)
            Bandwidth 50000 (kbps)Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
            (depth/total drops/no-buffer drops) 0/0/0
        Class-map: TELNET (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol telnet
          Queueing
            Output Queue: Conversation 267
            Bandwidth 5 (%)
            Bandwidth 5000 (kbps)Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
            (depth/total drops/no-buffer drops) 0/0/0
        Class-map: class-default (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any

    Policy has been defined for Fast Ethernet so LLQ and CBWFQ have 75Mbps traffic reserved, below BW calculation details:

    VoIP = 100Mbps * 0,1 = 10Mbps
    HTTP = 100Mbps * 0,1 = 10Mbps
    SMTP = 100Mbps * 0,5 = 50Mbps
    TELNET = 100Mbps * 0,05 = 5Mbps

    Option 2 – bandwidth remaining percent
    Second option to define BW is to use bandwidth remaining percent command. The idea of this type of configuration is to first reserve the BW for the PQ thru priority percent command and next divides the available remaining BW between defined classes.
    Let’s configure below:
    R1(config)#policy-map LLQ
    R1(config-pmap)#class VoIP
    R1(config-pmap-c)#priority percent 10
    R1(config-pmap-c)#class HTTP
    R1(config-pmap-c)#bandwidth remaining percent 10
    R1(config-pmap-c)#class SMTP
    R1(config-pmap-c)#bandwidth remaining percent 50
    R1(config-pmap-c)#class TELNET
    R1(config-pmap-c)#bandwidth remaining percent 40
    R1(config-pmap-c)#int fa0/0
    R1(config-if)#service-policy output LLQ

    For class VoIP priority percent 10 will be equal 100Mbps*0,1=10Mbps, BW Remaining is = (100-10)Mbps * 0,75= 67,5Mbps. So BW Remaining will be used as reference for all classes.
    For class HTTP bandwidth remaining percent 10 will be equal BW Remaining*0,1 = 67,5Mbps*0,1= 6,75 Mbps.
    For class SMTP bandwidth remaining percent 50 will be equal BW Remaining*0,5 = 33,75 Mbps.
    For class TELNET bandwidth remaining percent 40 will be equal BW Remaining*0,4 = 27 Mbps.
    By default Burst for Strict Priority queue is equal 20% of the PQ’s BW so 20% of 10Mbps, (10000000bitów/8)*0,2=250000B

    R1#show policy-map interface fa0/0
     FastEthernet0/0
      Service-policy output: LLQ
        Class-map: VoIP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol rtp
          Queueing
            Strict Priority
            Output Queue: Conversation 264
            Bandwidth 10 (%)
            Bandwidth 10000 (kbps) Burst 250000 (Bytes)
            (pkts matched/bytes matched) 0/0
            (total drops/bytes drops) 0/0
        Class-map: HTTP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol http
          Queueing
            Output Queue: Conversation 265
            Bandwidth remaining 10 (%)Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
            (depth/total drops/no-buffer drops) 0/0/0
        Class-map: SMTP (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol smtp
          Queueing
            Output Queue: Conversation 266
            Bandwidth remaining 50 (%)Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
            (depth/total drops/no-buffer drops) 0/0/0
       Class-map: TELNET (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol telnet
          Queueing
            Output Queue: Conversation 267
            Bandwidth remaining 40 (%)Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
            (depth/total drops/no-buffer drops) 0/0/0
       Class-map: class-default (match-any)
          30 packets, 2851 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any

    Above examples are Cisco recommended ways to deploye CE QoS configuration for different access speed port.

    Group Encrypted Transport (GET) VPN technology overview

    Group Encrypted Transport (GET) VPN is called as next-generation tunnel-less VPN technology but is not replacement for old good known DMVPN. GET and DMVPN are complementary technologies and can be deployed together. 

    Due to slow come up of the DMVPN spoke-to-spoke tunnels where IPSec tunnels are built dynamically based on the NHRP and multipoint GRE tunnels, tunnel negotiation time have direct impact for delay sensitive data like voice and video. In this case GET VPN is a good replacement solution where voice and video needs to be transmited between branches and faster static IPSec keys configuration and policy is in place before data go thru.

    The distibuted nature of today’s network applications like voice, video and multicast traffic, constant growth of network threats and risks, local, federal and industry regulations, highly confidential traffic in financial enviroment are a key factors for efficient and secure WAN branch to branch interconnectivity.

    WAN architecture demands has changed over years from the point-to-point and point-to-multipoint to full mesh connectivity. In today WAN network infrastructure where MPLS technology provides full mesh network connectivity between all branches most companies are still using centralized point-to-multipoint model with not efficient and slow dynamic tunnel negotiation process.

    GET VPN is recomended solution when time sensitive data has to be encrypted in addition to multicast appliction and dynamic routing is needed over MPLS WAN architecture with full mesh connectivity.

    Following are key fetures of GET VPN that have advantage over traditional IPSec VPN:

    • WAN transport full mesh encryption services on demand
    • Tunnel-Less Any-to-Any IPSec VPNs
    • Native routing
    • IP header preservation
    • Centralized key and policy management
    • Advanced QoS
    • Multicast connectivity
    • Reliability and redundancy of architecture

    The key components of GET VPN are GDOI protocol, Key Server and Group Member.

    Group Domain of Interpretation (GDOI) (RFC 3547)

    • Uses UDP 848
    • Cryptographic protocol for group policy/key management and distribution
    • Works based on ISAKMP
    • Establishes security associations between authorized group member routers
    • Uses two different encryption keys: Key Encryption Key (KEK) – key used to secure the control plane, Traffic Encryption Key (TEK) – key used to encrypt data traffic

    Key Server (KS)

    • Authenticates Group Member (GM)
    • Distributes IPSec keys and policies to all registered and authenticated GMs
    • Perform rekey process

    Group Member (GM)

    • Registers with KS to download IPSec VPN policy
    • Encrypts/decrypts traffic between among GMs in the same Group

    GET VPN process can be divided on the following 5 steps.

    • Registration of GMs in the KS
    • Authentication and authorization of GMs by the KS
    • IPSec SA policy propagation from KS to GMs
    • GM encrypt/decrypt traffic based on group policy
    • Rekey process – IPSec SA keys replacement propagation 

    In next post I’m going to provide you more process details and configuration example with GET VPN.