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.

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

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.

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

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 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.

Brand new Cisco router or switch has just console access enabled, so by default you can log go in to the console over rollover cable without any passwords.

Before we start with the authentication and authorization let’s fast recall the background. Cisco IOS CLI has two base following command modes:

• User EXEC mode – Router> (angle bracket sign)
• Privileged EXEC mode (enable mode) – Router# (pound sign)

We will configure AAA fetures on R1 and then telnet from R2 to R1 to test the impact on the authentication and authorization process to Console and VTY and AUX lines. First we have to enable the AAA access control system, new system, btw I haven’t seen old one yet :).
R1 con0 is now available
Press RETURN to get started.
R1#en
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#aaa new-model
R1(config)#

From the Console perspective no change, still no authentication and authorization, just click Enter twice unltil enable secret password is not defined, for VTY and AUX LOCAL authentication is enabled for privilege level 1 (based on the router’s local usernames database). Username and password needs to be defined on the router, enable secret password is needed for level 15, if not defined „% Error in authentication.” message will be displayed.

OK so let’s add below on R1 and look what is going on once we telnet from R2:
R1(config)#username netcontractor privilege 15 secret netcontractor
R1(config)#enable secret netcontractor
R1#debug aaa authentication
R2#telnet 10.0.0.1
Trying 10.0.0.1 ... Open
User Access Verification
Username:
R1#
*Mar 1 02:35:50.723: AAA/BIND(0000002A): Bind i/f
*Mar 1 02:35:50.731: AAA/AUTHEN/LOGIN (0000002A): Pick method list 'Permanent Local'
Router takes 'Permanent Local’ – default method that has been enabled once we enter aaa new-model command.
Username: netcontractor
Password:
R1>en
Password:
Once we click enter we get prompt for enable password, below output from R1 after enter has clicked
R1#
*Mar 1 02:35:59.911: AAA: parse name=tty66 idb type=-1 tty=-1
*Mar 1 02:35:59.915: AAA: name=tty66 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=66 channel=0
*Mar 1 02:35:59.919: AAA/MEMORY: create_user (0x647AD6E0) user='netcontractor' ruser='NULL' ds0=0 port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 initial_task_id='0', vrf= (id=0)
*Mar 1 02:35:59.923: AAA/AUTHEN/START (2046019537): port='tty66' list='' action=LOGIN service=ENABLE
*Mar 1 02:35:59.927: AAA/AUTHEN/START (2046019537): non-console enable - default to enable password
*Mar 1 02:35:59.927: AAA/AUTHEN/START (2046019537): Method=ENABLE
*Mar 1 02:35:59.931: AAA/AUTHEN(2046019537): Status=GETPASS
Router starts authentication process for user netcontractor using default method as enable password (Method=ENABLE). Default is taken because aaa authentication enable command has not been defined. Next router sends a GETPASS request to prompt for the password.
Enable password: netcontractor, click enter.
Password:
R1#
R1#
*Mar 1 02:36:10.855: AAA/AUTHEN/CONT (2046019537): continue_login (user='(undef)')
*Mar 1 02:36:10.859: AAA/AUTHEN(2046019537): Status=GETPASS
*Mar 1 02:36:10.859: AAA/AUTHEN/CONT (2046019537): Method=ENABLE
*Mar 1 02:36:10.955: AAA/AUTHEN(2046019537): Status=PASS
*Mar 1 02:36:10.955: AAA/MEMORY: free_user (0x647AD6E0) user='NULL' ruser='NULL' port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 vrf= (id=0)Router takes entered password for enable method and confirm with PASS response to indicate a successfull login.
Once we add below to the R1:
R1(config)#aaa authentication enable default nonethen after username and password authentication no propmpt for Password is send from the R1
R2#telnet 10.0.0.1
Trying 10.0.0.1 ... Open
User Access Verification
Username: netcontractor
Password:
R1>en
R1#
Router uses defined default list with NONE method – so once user enter enable command will be taken to the privilage level 15.
R1#
*Mar 1 03:05:10.447: AAA/BIND(0000002E): Bind i/f
*Mar 1 03:05:10.459: AAA/AUTHEN/LOGIN (0000002E): Pick method list 'Permanent Local'
R1#
*Mar 1 03:05:20.695: AAA: parse name=tty66 idb type=-1 tty=-1
*Mar 1 03:05:20.695: AAA: name=tty66 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=66 channel=0
*Mar 1 03:05:20.699: AAA/MEMORY: create_user (0x647AD6E0) user='netcontractor' ruser='NULL' ds0=0 port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 initial_task_id='0', vrf= (id=0)
*Mar 1 03:05:20.703: AAA/AUTHEN/START (1933181644): port='tty66' list='' action=LOGIN service=ENABLE
*Mar 1 03:05:20.707: AAA/AUTHEN/START (1933181644): using "default" list
*Mar 1 03:05:20.711: AAA/AUTHEN/START (1933181644): Method=NONE
*Mar 1 03:05:20.711: AAA/AUTHEN(1933181644): Status=PASS
R1#
*Mar 1 03:05:20.711: AAA/MEMORY: free_user (0x647AD6E0) user='netcontractor' ruser='NULL' port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 vrf= (id=0)

In case we would authenticate and authorize access to the console (as I have mentioned console means connection over serial – rollover cable) we have to enable authentication for line 0 explicity not just enter aaa new-model (local authentication after aaa new-model command works for all lines beside console line 0 = CTY). Below commands are enough to place user on the level 15 once enter username and password.
R1(config)#aaa authentication login default local
R1(config)#aaa authorization console

What about VTY lines authorization? We would achieve authorization for user, so once we log on over VTY lines (telnet or ssh) to the router with username and password we will be placed in the privileged EXEC mode level 15 automatically. Solution is simple, we have to configure exec authorization with local method – just one line.
R1(config)#aaa authorization exec default local
R1#debug aaa authorization
AAA Authorization debugging is on
Once we log on and enter username and password router takes default authorization list and with local method, user use placed on to the respective privilage level based on the username netcontractor privilege command.
R1#
*Mar 1 03:22:49.691: AAA/AUTHOR (0x30): Pick method list 'default'
*Mar 1 03:22:49.707: AAA/AUTHOR/EXEC(00000030): processing AV cmd=
*Mar 1 03:22:49.707: AAA/AUTHOR/EXEC(00000030): processing AV priv-lvl=15
*Mar 1 03:22:49.707: AAA/AUTHOR/EXEC(00000030): Authorization successful

Above are basic but very important issues to understand AAA.

Attributes that have to match to successful establish FULL neighbor adjacency

1. Area ID
2. Authentication
3. Subnet/Subnet Mask
4. Hello/Dead Interval
5. Stub area flag

 Note: FULL neighbor adjacency state doesn’t mean that LS exchange will take place. There is one additional condition that needs to be met. You can mix network types until they will match DR/BDR election process. So you can mix broadcast and non-broadcast because both network types require DR/BDR election but once you mix broadcast with p2p adjacency will come up but LS exchange will not take place.

 Multicast IPs

AllSPFRouters – 224.0.0.5 (0100.5e00.0005)

AllDRouters – 224.0.0.6 (0100.5e00.0006)

Router ID Election

1. Router-id command
2. Highest IP address on loopback interface
3. Highest IP address on other interfaces

 DR, BDR Election

1. The highest priority (255 highest, 0 doesn’t take part in election process)
2. If tie, highest Router ID

DRothers – established adjacency only with DR, BDR, between DRothers<>DRothers is 2WAY/DRothers

 Interface State Machine

• Down
• P2P
• Waiting
• DR
• Backup
• DRothers
• Loopback

 Neighbor State Machine

• Down
• Attempt (only on NBMA where neighbors are manually configured)
• Init – Hello has been received but router does not see its own RID in the hello yet
• 2-Way – router has seen its own RID in the neighbor’s field hello packet (bidirectional)
• ExStart – neighbor establish master/slave relationship and determine the initial DBD seq number, router with highest RID is master
• Exchange – router sends DBD packets describing its entire LSDB (LSA Headers), may sends LS Request, requesting more recent LSAs to neighbors
• Loading – router sends LS Request, requesting more recent LSAs that have been discovered in the Exchange state but have not been received
• Full – neighbors are fully adjacent

 Building an Adjacency

• Hello (type 1)
• DBD (type 2)
  • Just description of LSAs (header is sent)
    • receiving router decides whether it has the latest copy of the LSA in its own DB
  • Flag is sent
    • I bit – first DBD packet sent
    • M bit (more bit) – not last DBD packet, will be more
    • MS bit (Master/Slave bit) – set in DBD packet originated by the Master
    • LS Request (type 3)
    • LS Update (type 4)

 Exstart and Exchange process

1. Both neighbors claim to me the master
   • sending DD with MS bit set to 1
   • own random strange DB sequence number
2. Router with lower RID will be slave and replay with DD
   • MS bit = 0
   • DD sequence number set to master’s sequence number
   • Its first (I bit) packet with LSA summaries
3. Exstart process completed
4. Exchange process starts
5. If neighbor (router A) receives LSA that
   • Is not in its own database
   • Or remote neighbor has a more recent copy of known LS
   • The router A place the LSA on the Link State Request List
6. Router A sends LS Request packet asking for complete copy of the LSA from the List
7. Remote B router sends LSA Update and adds LSA on Link State Retransmission list
8. Router A sends back LS ACK acknowledged LSA that received
9. Router B removes acknowledged LSA from the Link State Retransmission list
10. Next state
    • If A or B have still entries in Link State Request List > Loading state (Master sends M bit set to zero, Slave ACK with the same sync number and M bit zero)
11. If A or B have no entries in Link State Request List > Full state

Master controls synchronization process and ensure that only one DD packet is outstanding at a time.

When slave receives DD packet, acknowledges the packet by sending a DD packet with the same sequence number.

If master does not receive acknowledgement within Retransmission Interval, then sends new copy.

Sequence Number – all routers must have an identical sequence number

Age

• Starts from 1
• MaxAgeDiff – Maximum Age Difference (15 minutes)
• Router receives multiple copies of the same LSA with identical Sequence Number but with different age
• If difference in the age < MaxAgeDiff – original LSA is retained (no flooding)
• If difference in the age > MaxAgeDiff – new LSA recorded and flooded
• MaxAge – (60 minutes/3600 sec) – after this time LSA is flushed out from LSD
• LSARefreshTime (30 minutes/1800 sec) – flooding all LSA to reset MaxAge

Area notation example

Area 271 = Area 0.0.1.15  = 00000000.00000000.00000001.00001111=100001111=271

LSA Types

LSA 1 – O, Router LSA (contain all Link IDs – network),

• Generated by every router and is local to the area
• Describes all router interfaces + cost
• “Routing bit set on this LSA” means that the route to this destination is in RIB
• show ip ospf database router <router-id>

LSA 2 – O, Network LSA (contain all routers attached to the segment)

• Generated by DR and is local to the area
• Lists all attached routers (router ID) including DR
• show ip ospf database network <IP address of DR>

LSA 3 – O IA, Network Summary LSA (describes network from another Area)

• Generated by ABR and is propagated between areas
• Include cost from ABR to network
• show ip ospf database summary <network_IP>

 LSA 4 – O IA, Summary ASB Link States

• Generated by the ABR and is propagated between areas
• Describes RID of the ASBR
• show ip ospf database asbr-summary

 LSA 5 – O E1, O E2, External Link States

• Generated by ASBR and is propagated between areas
• Describes links that are external to the AS
• show ip ospf database external
• E1 cost consist of:
  • External metric > show ip ospf database external <Link state ID>
  • Metric to ASBR (Advertising Router=RID) > show ip ospf border-routers
• E2 cost = External metric > show ip ospf database external <Link state ID>

LSA 7 – O N1, O N2, NSSA External Link States

• Generated by ASBR into Not-So-Stubby (NSSA) area
• Describes links that are external to the AS in the NSSA area
• ABR swap the LSA type 7 to LSA type 5 when sends from NSSA into Area 0
• show ip ospf database nssa-external
• N1 cost consist of:
  • External metric show ip ospf database nssa-external <Link state ID>
  • Metric to ASBR (Advertising Router=RID) > show ip ospf border-routers
• N2 cost = External metric > show ip ospf database nssa-external <Link state ID>

Route selection proces based on the LSA type

O>O IA>O E1>O E2>O N1>O N2

As I have promised here you are next post from the PKI scope. Following example presents way of communication between user A and B with digital certificates. It will be one way communication example so user A sends data to user B. The same process takes place in opposite direction. It’s not easy and smooth but rather hardcore and kiler theme 😉 so it’s good to have fresh and open mind to read it. Are you read? Please go ahead.

The following process diagram will be very helpfull to understand the clue, step by step description below:

1. User has own keys pair (public/private keys). Public key A (related to private key A) has been signed and authorized by the CA before (certificate enrolment process that is has been described Public Key Infrastructure – certificate enrolment post).
2. User A uses public key B and encrypts Message that will be sent to the user B. Public key B has been taken from B’s certificate.
3. Additionally, user A takes the same clear Message as input and does SHA (or MD5) hash function – Message# is output of this algorithm.
4. Message# is then encrypted by the Private key A. Digital Signature of the user A Message is output of this process.
5. The Digital Signature is added to the encrypted message.
6. Above decrypted message and User A Certificate is send to the User B. User B gets a encrypted message and start decryption and authentication process. First user needs to be sure that Public key A that will be used for user’s A message authentication is true Public key of user A.
7. To verify it, User B takes the Public key CA from the CA Certificate (that has signed User A’s Data, CA has issued the User A Certificate during certificate enrolment process) and decrypt the Digital Signature CA that is embedded into User A Certificate, Data# A is output of this process. Additionally user B downloads most up to date Certificate Revocation List (CRL) from CA to verify if User A Certificate has not been canceled and is still valid.  
8. User B takes User A Certificate a does the same hash function (like CA has done for User A Data), Data# A is output of this process. User B takes this output and compares with Data# A (that has been produced in point 7) to confirm User A identity. If the hash outputs are the same it means that User A Certificates is real so Public key A is confirmed and can be use for communication.
9. User B takes Public key A and decrypts Encrypted Message that has received. Clear, unencrypted message is output.
10. To confirm that Message is real and has not been changed on way, User B does the same hash function (encryption and authentication functions have been negotiated at the beginning of the communications process, for example in case of IPsec it takes place in Phase 2 of IKE negotiation), so unencrypted Message is a input and Message# is output of this process.
11. Then User B takes own Private key B and decrypts Digital Signature of the Message that has been added by the User A. Message# is output of this process.
12. Message# from point 10 and Message# from point 11 is compare and if are the same then User B is sure that Message has not been changed and is exactly the same like User A has sent.

Some time ago when I was learning about PKI (Public Key Infrastructure) I searched for any process diagram that shows and visualyze step by step ceriticate enrolment process by CA or other encryption or authentication steps in the PKI enviroment in simple and detail manner. Because I have not found any have decided to draw it and explain the process, hope will help to understand the issue.

Before we will discuss the ceriticate enrolment process we have to explain the background shortly. OK so let’s start.

The base of the PKI is the concept of Asynchronous Keys. Asynchronous Keys is the encryption algorithm that can be use to secure transport data over unsecure connectivity, additonaly due to the nature of algorithm authenticate identity.
The idea of algorithm is based on two differtent keys (public and private key) that are mathematical related to each other, where private key derived from the public key. Message encrypted by recipient’s public key can only be decrypted by the corresponding private key (we can encrypt the message only by related key), and vice-versa, message encrypted by the owner’s private key can be only decrypted by the owner’s public key that is commonly available. Based on first case we achive data intergrity and confidential because only owener of private key will be able to decrypt the message and properly read the data, based on second one, reciver of the message can authenticate the sender because once decrypt the message and properly read a data, he knows that data have been sent by proper source (owner of private key). Above algorithm has revolutionized the encryption and authentication way. The only one problem was a public key distribution, this what the PKI is about.

Once we generate public/private key pair, we have to make the private key public available and the get global authority confirmation that the private key belong to as (at least it’s good to have confirmation from globally trusted source). Here Certificate Authority (CA) comes in to play. We have a lot of nice institution like VeriSign or GlobalSign and others that we can trust. The primary task of them is to confirm that generated public key belongs to us so can be used to exchange message in secure way.

Ceriticate enrolment process
I will explain the process based on the following example with user A (instead of user we can have any device: router or server, simple end point that will physically encrypt data).

1. User A generates pair of keys: public key A and private key A.
2. User A sends to the CA, own public key A with additional details that will identify user A like name, surname, departament city, country, e-mail address etc.
3. CA verifies user A data, next takes user A data and public key A as input and do SHA (or MD5) hash function – Data# A is output of this alghorith.
4. CA then uses own Private key CA and encrypts Data# A, Digital signature of the CA is output of this process.
5. User A Data, Public key of A, Digital signature of the CA, and specific details assigned by the CA like certificate serial number, issued and valid date, point of CRL distribution (and many more) creates User A Certificates.
6. Users A can get certificate and start use it to encrypt and authenticate data.

I hope this post will helpfull and clarify certificate enrolment process. If you have any comments please let me know. In next post I will discuss the encryption and authentication based on the digital certificate.