DMVPN provides the ability for large scale VPN’s, in a Hub and Spoke topology, while using a simplified Dynamic deployment model for the spokes. This is due to the reduced configuration required on the Hub device.

DMVPN combines the use of four key technologies; IPSec, Generic Routing Encapsulation (GRE) Tunnels, Next Hop Resolution Protocol (NHRP) and a Dynamic Routing Protocol (OSPF, EIGRP etc.). In DMVPN we need to look to the NHRP protocol to provide us with a method of implementing Per Tunnel QoS; this feature is called NHRP Groups.

We should start to see a pattern emerging here; Tunnel Groups on the ASA; QoS Groups for IOS VPN; and now NHRP Groups for DMVPN! All of which, we use as classifiers for our QoS policies.

NHRP groups are configured on the Spokes GRE tunnel interfaces, and acts to identify each tunnel to the Hub device. The NHRP group is passed to the Hub during the NHRP registration process, which is sent from Spoke to Hub. Static mappings are applied to each spoke so they can identify where to initiaite their registration to. This is the key to the operation of DMVPN as a whole, as its responsible for dynamically updating the Hubs NHRP tables with the registering spokes information. This spoke info allows the establishment of the IPSec SA’s in both directions.

Assuming that the DMVPN configuration is already in place, several requirements/restrictions exist for NHRP groups:

• CEF must be enabled to use NHRP Groups

• You can only use 1 NHRP Group Per DMVPN Tunnel Interface

• If multiple tunnel interfaces exist on the spoke then seperate groups names can be used on each interface.

The slight difference we have over the previous examples for VPN QoS, is although the groups are defined on the spoke router, the policy is defined and applied on the Hub.

The Spoke side configuration is pretty simple, all we need to do is enter tunnel interface config mode and apply the group to the GRE Interface, so for example set an NHRP group of SpokeGrp1 to the interface for Tunnel1:

interface Tunnel 1

ip nhrp group SpokeGrp1

Simple huh! The bulk of the configuration is actually done on the Hub router, so all were doing here is tagging the tunnel with an ID. Now for the Hub.

In comparison to our previous examples the NHRP group is not matched within the Class Map, instead we use an NHRP Map command to associate the group to a defined QoS policy. This leaves us the flexibility to match on specific traffic in our class maps.

For example on the Hub GRE interface map the group to a policy:

Interface Tunnel 1

ip nhrp map group SpokeGrp1 service-policy output SpokeGrp1_QoS

Ok lets move on to an example scenario.

Above we have a simple Hub and two spoke DMVPN setup. The tunnel for R4 Spoke 1 will be tagged with the NHRP Group of WEST, and R5 Spoke 2 will be tagged as EAST.

QoS policies will be defined on the Hub router using the following:

• R4’s WEST group requires to be shaped to 1Mb

• R5’s EAST group requires a nested policy for the following:

• Prioritise critical application traffic marked as DSCP AF43 to 512k

• Shape all traffic to 1mb

Configuration:

So starting with the Spokes we need to assign the NHRP groups:

R4:

Interface Tunnel 1

ip nhrp group WEST

R5:

Interface Tunnel 1

ip nhrp group EAST

Then we move to the Hub router to define the QoS policies and associate them to each group:

R2:

class-map match-all PRIORITY

match ip dscp af43

policy-map PRIORITY_QOS

class PRIORITY

priority 512

policy-map WEST_QOS

class class-default

shape average 1000000

policy-map EAST_QOS

class class-default

shape average 1000000

service-policy PRIORITY_QOS

interface Tunnel1

ip nhrp map group EAST service-policy output EAST_QOS

ip nhrp map group WEST service-policy output WEST_QOS

There you have it, the configuration for the above requirements. Class defaults are used to match on any traffic flow. The small addition here is the inclusion of the hierarchical nested policy. This is made up of two separate policies, a Child policy (PRIORITY_QOS) that is in turn applied to the Parent policy (EAST_QOS). The Parent / Child relationship allows a more granular approach, by providing the ability to assign different actions to both Parent and Child, based on the traffic flows defined with their respective classes.

A nice plus point to this method is that the QoS is applied on the arrival of the next packet without the need to restart the IPSec SA’s.

Verification:

Now we have the config in place next step is to verify it. Verification should be done on the Hub Router. Show DMVPN Detail is a good place to start. Here we can see the peer information, the group mapping and the applied service policies.

R2_Hub#show dmvpn detail

Legend: Attrb –> S – Static, D – Dynamic, I – Incomplete

N – NATed, L – Local, X – No Socket

# Ent –> Number of NHRP entries with same NBMA peer

NHS Status: E –> Expecting Replies, R –> Responding

UpDn Time –> Up or Down Time for a Tunnel

===================================================================

Intferface Tunnel1 is up/up, Addr. is 10.1.245.2, VRF “”

Tunnel Src./Dest. addr: 192.1.2.2/MGRE, Tunnel VRF “”

Protocol/Transport: “multi-GRE/IP”, Protect “DMP”

Type:Hub, Total NBMA Peers (v4/v6): 2

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network

—– ————— ————— —– ——– —– —————–

1 192.1.2.4 10.1.245.4 UP 01:15:20 D 10.1.245.4/32

NHRP group: WEST

Output QoS service-policy applied: WEST_QOS

1 192.1.2.5 10.1.245.5 UP 01:15:31 D 10.1.245.5/32

NHRP group: EAST

Output QoS service-policy applied: EAST_QOS

Or alternatively, show ip nhrp group-map provides the more specific information:

R2_Hub#show ip nhrp group-map

Interface: Tunnel1

NHRP group: EAST

QoS policy: EAST_QOS

Tunnels using the QoS policy:

Tunnel destination overlay/transport address

10.1.245.5/192.1.2.5

NHRP group: WEST

QoS policy: WEST_QOS

Tunnels using the QoS policy:

Tunnel destination overlay/transport address

10.1.245.4/192.1.2.4

Final piece of verification is to check that the policy is in effect.

Use the show policy-map multipoint to confirm this:

R2_Hub#show policy-map multipoint

Interface Tunnel1 <–> 192.1.2.4

Service-policy output: WEST_QOS

Class-map: class-default (match-any)

4630 packets, 5171238 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Queueing

queue limit 250 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

shape (average) cir 1000000, bc 4000, be 4000

target shape rate 1000000

Interface Tunnel1 <–> 192.1.2.5

Service-policy output: EAST_QOS

Class-map: class-default (match-any)

4979 packets, 1989296 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Queueing

queue limit 250 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

shape (average) cir 1000000, bc 4000, be 4000

target shape rate 1000000

Service-policy : PRIORITY_QOS

queue stats for all priority classes:

queue limit 128 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

Class-map: PRIORITY (match-all)

1000 packets, 124000 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: ip dscp af43 (38)

Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 0

Class-map: class-default (match-any)

255 packets, 22278 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

queue limit 122 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

R2_Hub#

For reference, Ive included the core configs for each router below.

R2_Hub#

!

hostname R2_Hub

!

crypto isakmp policy 10

encr aes

authentication pre-share

group 5

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

!

!

crypto ipsec transform-set TS esp-aes esp-sha-hmac

!

crypto ipsec profile DMP

set transform-set TS

!

class-map match-all PRIORITY

match ip dscp af43

!

policy-map PRIORITY_QOS

class PRIORITY

priority 512

class class-default

policy-map WEST_QOS

class class-default

shape average 1000000

policy-map EAST_QOS

class class-default

shape average 1000000

service-policy PRIORITY_QOS

!

interface Tunnel1

ip address 10.1.245.2 255.255.255.0

no ip redirects

ip mtu 1400

no ip next-hop-self eigrp 1

ip nhrp authentication cisco

ip nhrp map multicast dynamic

ip nhrp map group EAST service-policy output EAST_QOS

ip nhrp map group WEST service-policy output WEST_QOS

ip nhrp network-id 245

ip nhrp holdtime 300

ip tcp adjust-mss 1360

no ip split-horizon eigrp 1

tunnel source FastEthernet1/1

tunnel mode gre multipoint

tunnel protection ipsec profile DMP

!

interface FastEthernet1/0

no switchport

ip address 10.1.2.2 255.255.255.0

!

interface FastEthernet1/1

no switchport

ip address 192.1.2.2 255.255.255.0

!

router eigrp 1

network 10.1.2.0 0.0.0.255

network 10.1.245.0 0.0.0.255

no auto-summary

!

R4_Spoke1#

!

crypto isakmp policy 10

encr aes

authentication pre-share

group 5

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

!

crypto ipsec transform-set TS esp-aes esp-sha-hmac

!

crypto ipsec profile DMP

set transform-set TS

!

interface Tunnel1

bandwidth 1000

ip address 10.1.245.4 255.255.255.0

no ip redirects

ip mtu 1400

ip nhrp authentication cisco

ip nhrp group WEST

ip nhrp map multicast 192.1.2.2

ip nhrp map 10.1.245.2 192.1.2.2

ip nhrp network-id 245

ip nhrp holdtime 300

ip nhrp nhs 10.1.245.2

ip tcp adjust-mss 1360

tunnel source FastEthernet0/1

tunnel mode gre multipoint

tunnel protection ipsec profile DMP

!

interface FastEthernet0/0

ip address 10.1.4.4 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.1.2.4 255.255.255.0

duplex auto

speed auto

!

router eigrp 1

network 10.1.4.0 0.0.0.255

network 10.1.245.0 0.0.0.255

no auto-summary

!

R5_spoke2#

!

crypto isakmp policy 10

encr aes

authentication pre-share

group 5

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

!

!

crypto ipsec transform-set TS esp-aes esp-sha-hmac

!

crypto ipsec profile DMP

set transform-set TS

!

interface Tunnel1

bandwidth 1000

ip address 10.1.245.5 255.255.255.0

no ip redirects

ip mtu 1400

ip nhrp authentication cisco

ip nhrp group EAST

ip nhrp map multicast 192.1.2.2

ip nhrp map 10.1.245.2 192.1.2.2

ip nhrp network-id 245

ip nhrp holdtime 300

ip nhrp nhs 10.1.245.2

ip tcp adjust-mss 1360

tunnel source FastEthernet0/1

tunnel mode gre multipoint

tunnel protection ipsec profile DMP

!

interface FastEthernet0/0

ip address 10.1.5.5 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.1.2.5 255.255.255.0

duplex auto

speed auto

!

router eigrp 1

network 10.1.5.0 0.0.0.255

network 10.1.245.0 0.0.0.255

no auto-summary

!

end

Hopefully these three Techtorials have provided some insight into the ways we can incorporate common Quality of Service methods into our VPN deployments, and ultimately bolster the knowledge required for success in your future lab attempts. See ya soon with some more posts :-)

Stu…

Regards,

Stuart Hare

CCIE #25616 (Security), CCSP, Microsoft MCP

Sr. Support Engineer – IPexpert, Inc.

URL: http://www.IPexpert.com

• Daryl P. Smith CCIE #25893 (Voice)
• Brett Saling CCIE #25890 (Voice)

IPexpert is proud to boast the world’s largest list of CCIE success stories, and the industry’s most complete and updated self-study portfolio for the CCIE R&S, Voice, Security and Service Provider Lab exams.  Have you also used IPexpert or Proctor Labs to help you pass the CCIE lab exam?  If so, we want to hear your story! Please email us at success@ipexpert.com

The similarities appear when we look into the methods of configuration, both use Classes, Polices and Service-policies to define and apply the required methods of QoS.

The big difference is that we have far more granularity in terms of the match criteria within the Classes, and the Set / Action criteria we can apply in these Policies. Not only can we control the traffic flow, we can also mark the traffic to a specific DSCP or IP Precedence value, so it can be controlled in another part of the network.

There are too many methods to list here so check out the following QoS documentation for a detailed list of supported match and action criteria:

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_mqc.html#wp1043620

When it comes to QoS and IPSec in IOS we have a nice feature called qos-groups.

Qos-groups allow us to tag IPSec flows with a group id or number, which we can use as match criteria in a class map, to differentiate between multiple tunnels (similar to the match tunnel-group on the ASA).

To use qos-groups we also need to utilize another VPN feature, the ISAKMP profile.

The ISAKMP Profile provides us with the ability, to uniquely identify, different flows of VPN traffic, using its own version of match statements. Match statements here typically match on identities using peer IP addresses, hostnames, or even groups as used in EZVPN.

They can be used to set IKE Phase 1.5 (XAUTH) parameters, such as client configs, authentication and authorization lists, and also CA Trustpoint’s and VRF’s etc.

Note that qos groups cannot be used currently without the ISAKMP profile.

Ok so lets see how we combine these two features for our QoS configuration.

First off we need to create an ISAKMP profile, and define the match type. Then from within the profile we set the qos group tag or id.

Valid values for the qos-group number are 1 – 1023.

crypto isakmp profile <profile name>

match identity address <ip address>

qos-group <number>

What we are actually doing here is very much like QoS marking, if this is matched then mark with this. So effectively if the VPNs peer IP address is X, then set the qos group for this VPN to Y. Now we have the basic ISAKMP profile defined and the qos-group set, we then need to look at how we manipulate this.

Thinking back to part 1, what we needed to do next was to identify our interesting traffic using Class Maps. And this is where we will look to use our qos group as part of the match criteria.

class-map match-all <class_name>

match qos-group <number>

Then we are back in the land of policies and service polices, where we call our classes and apply our required QoS methods.

Lets look at a scenario to tie this all together.

Here we have a basic Head Office, Branch Office environment with support for Remote Access VPN. R1 is our Hub device and is terminating both a Site to Site VPN for the Branch to R2, and Remote Access VPN for remote users using EZVPN.

As we used both Policing and LLQ/Priority Queueing for the ASA example in Part 1, we will look at utilizing two different methods here. Traffic Shaping will be used for the Branch Office, while the RAS VPN will be dedicated a percentage of the available interface bandwidth.

Assuming the VPN’s have an existing setup, and that we are applying our QoS to R1, lets first look at the config for the Branch office. Recapping, we need to first create our ISAKMP profile, define the match for the peer IP address of R2, and set the qos-group, which we will assign the value of 1. One extra step is that we will also use a Crypto keyring for the pre shared key.

crypto keyring Branch

pre-shared-key address 192.1.2.2 key cisco

crypto isakmp profile Branch

keyring Branch

match identity address 192.1.2.2 255.255.255.255

qos-group 1

crypto map CM 10 ipsec-isakmp

set isakmp-profile Branch

If we now reestablish the VPN to R2 we should see that IPSec SA now has the qos-group assigned to it:

R1#show crypto ipsec sa

interface: FastEthernet0/1

Crypto map tag: CM, local addr 192.1.2.1

protected vrf: (none)

local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.1.1.0/255.255.255.0/0/0)

current_peer 192.1.2.2 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 134, #pkts encrypt: 134, #pkts digest: 134

#pkts decaps: 134, #pkts decrypt: 134, #pkts verify: 134

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 1, #recv errors 0

qos group is set to 1

Next step is to define our QoS policy and assign it. Remembering our three main steps, we need to use the class map to classify our interesting traffic, create a policy map to assign our QoS method and the Service Policy to apply the policy to an interface.

class-map match-all Branch_QoS

match qos-group 1

policy-map VPN_QoS

class Branch_QoS

shape average 8000

interface FastEthernet0/1

ip address 192.1.2.1 255.255.255.0

crypto map CM

service-policy output VPN_QoS

So in a nutshell the above configuration is taking any VPN traffic marked with qos group 1, and applying traffic shaping to an average rate of 8kbps.

Note that when we apply the service policy to an interface to enable the QoS features, we need to ensure that it is assigned to the same interface that your crypto map is assigned to. Also note that QoS groups can only be applied to outbound service policies.

Moving on to the Remote Access clients, we pretty much follow the same procedure as we did for the branch office VPN. Main difference here is the match criteria for the ISAKMP profile. As the peer addresses of the clients can change regularly, we cant match on the peers IP address. But as we are using EZVPN we can match on its group name. For the RAS VPN we are using qos group 4.

crypto isakmp profile RAS

match identity group RASGrp

qos-group 4

crypto dynamic-map RASDM 20

set isakmp-profile RAS

class-map match-all RAS

match qos-group 4

policy-map VPN_QoS

class RAS

bandwidth percent 1

For the RAS VPNs the ISAKMP profile is applied to the existing dynamic crypto map, and the QoS method applies a set percentage of interface bandwidth (1%) for the VPN traffic.

The amount of actual bandwidth that gets assigned, will vary based on the interface and the hardware used. Once we have a RAS VPN established we can check the IPSec SA’s once more, to verify they are up and that the qos group has been set correctly:

R1#show crypto ipsec sa

interface: FastEthernet0/1

Crypto map tag: CM, local addr 192.1.2.1

protected vrf: (none)

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (10.4.4.7/255.255.255.255/0/0)

current_peer 192.1.2.100 port 1326

PERMIT, flags={}

#pkts encaps: 327095, #pkts encrypt: 327095, #pkts digest: 327095

#pkts decaps: 196642, #pkts decrypt: 196642, #pkts verify: 196642

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

qos group is set to 4

The final step we need to take is to generate some traffic to verify that our traffic is being classified correctly, matched on and ultimately have our QoS features applied to the traffic flows. Firing some large ICMP traffic between HostA and HostB, and, HostA and RAS Client will suffice for this test.

R1#show policy-map interface f0/1

FastEthernet0/1

Service-policy output: VPN_QoS

Class-map: Branch_QoS (match-all)

304 packets, 242280 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: qos-group 1

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

8000/8000 2000 8000 8000 1000 1000

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 1 239 229090 202 215964 yes

Class-map: RAS (match-all)

314399 packets, 257760858 bytes

5 minute offered rate 2551000 bps, drop rate 0 bps

Match: qos-group 4

Queueing

Output Queue: Conversation 265

Bandwidth 1 (%)

Bandwidth 1000 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 4/3352

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)

1624 packets, 181439 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

R1#

From the policy-map output above, starting with the Branch Class, we see that 304 packets have been successfully matched for qos group 1, the traffic is being actively shaped to 8k, with packets being queued as the token bucket fills.

With the RAS class output, we needed to generate quite a bit more traffic as you can see. Again the successful matches are occurring based on qos group 4. And similar to shaping we see that by using the bandwidth method, we are also assigned a queue. The bandwidth queue comes into play as the bandwidth percentage is exceeded. Packets are placed into the queue, and are transmitted as and when it becomes available. This queue also has a threshold limit, and if this is exceeded then further packets will be dropped.

Looking at the pkts matched/bytes matched counter we see that 4 pkts and 3352 bytes were placed in to the queue, with no packets being dropped. Happy days :)

Just for completeness see R1’s configuration below.

Hopefully this post has provided some insight into how the simple use of QoS groups can be integrated to assist us in applying different QoS features to IOS VPN’s.

R1#sh run

Building configuration…

Current configuration : 2414 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R1

!

boot-start-marker

warm-reboot

boot-end-marker

!

aaa new-model

!

aaa authentication login XAUTH local

aaa authorization network XAUTH local

!

aaa session-id common

memory-size iomem 15

!

dot11 syslog

!

ip cef

!

multilink bundle-name authenticated

!

voice-card 0

no dspfarm

!

vtp domain ipexpert

vtp mode transparent

username vpnuser password 0 cisco

!

crypto keyring Branch

pre-shared-key address 192.1.2.2 key cisco

!

crypto isakmp policy 10

encr aes

authentication pre-share

group 5

!

crypto isakmp policy 20

encr aes

authentication pre-share

group 2

crypto isakmp key cisco address 192.1.2.2

!

crypto isakmp client configuration group RASGrp

key cisco

pool RASPOOL

acl 100

save-password

netmask 255.255.255.0

!

crypto isakmp profile Branch

keyring Branch

match identity address 192.1.2.2 255.255.255.255

qos-group 1

!

crypto isakmp profile RAS

match identity group RASGrp

client authentication list XAUTH

isakmp authorization list XAUTH

client configuration address respond

qos-group 4

!

crypto ipsec transform-set TS esp-aes esp-sha-hmac

!

crypto dynamic-map RASDM 20

set transform-set TS

set isakmp-profile RAS

reverse-route

!

crypto map CM 10 ipsec-isakmp

set peer 192.1.2.2

set transform-set TS

set isakmp-profile Branch

match address VPN

crypto map CM 20 ipsec-isakmp dynamic RASDM

!

archive

log config

hidekeys

!

class-map match-all Branch_QoS

match qos-group 1

!

class-map match-all RAS

match qos-group 4

!

policy-map VPN_QoS

class Branch_QoS

shape average 8000

class RAS

bandwidth percent 1

!

interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.1.2.1 255.255.255.0

duplex auto

speed auto

crypto map CM

service-policy output VPN_QoS

!

ip local pool RASPOOL 10.4.4.0 10.4.4.10

ip forward-protocol nd

ip route 192.1.1.0 255.255.255.0 192.1.2.2

!

no ip http server

no ip http secure-server

!

ip access-list extended VPN

permit ip 10.1.1.0 0.0.0.255 192.1.1.0 0.0.0.255

!

access-list 100 permit ip 10.1.1.0 0.0.0.255 any

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

!

scheduler allocate 20000 1000

!

end

R1#

Stuart Hare

CCIE #25616 (Security), CCSP, Microsoft MCP

Sr. Support Engineer – IPexpert, Inc.

URL: http://www.IPexpert.com

In this blog I am going to post a basic configuration to start off with to understand how you configure SIP endpoints with CUCME.

Step 1

Set up TFTP server on router for phones to pick SIP firmware

!

tftp-server flash:PHONE/7940-7960/P0S3-08-9-00.loads alias P0S3-08-6-00.loads

tftp-server flash:PHONE/7940-7960/P0S3-08-9-00.sb2 alias P0S3-08-6-00.sb2

tftp-server flash:PHONE/7940-7960/P003-08-9-00.bin alias P003-08-6-00.bin

tftp-server flash:PHONE/7940-7960/P003-08-9-00.sbn alias P003-08-6-00.sbn

!

Step 2

SIP configuration and setup of registrar server

!

voice service voip

allow-connections sip to sip

sip

bind all source-interface Vlan100

registrar server expires max 600 min 60

!

voice register global

mode cme

source-address 11.11.101.1 port 5060

max-dn 2

max-pool 2

load 7960-7940 P0S3-08-6-00

authenticate register

tftp-path flash:

create profile

!

Step 3

Create the voice register dn’s (phone lines)

!

voice register dn 1

number 2001

!

voice register dn 2

number 2002

!

Step 4

Create the voice register pools (phone configuration)

!

voice register pool 1

description 79XX PHONE 2001

id mac 003F.A3F4.AA54

type 7960

number 1 dn 1

dtmf-relay sip-notify

username 2001 password cisco

description 2222-2001

!

voice register pool 2

description 79XX PHONE 2002

id mac 002D.456E.345A

type 7960

number 1 dn 2

dtmf-relay sip-notify

username 2002 password cisco

description 2222-2002

–

Regards,

Iwan Hoogendoorn

CCIE #13084 (R&S / Security / SP)

Sr. Support Engineer – IPexpert, Inc.

URL: http://www.IPexpert.com

These Walk-Through Video Tutorials for the CCIE R&S Lab Preparation Workbook (Volume 1) will take the strategy and methodologies for working through lab exams to a deeper level. The videos will illustrate the mindset of an expert CCIE R&S Instructor during the configuration, verification and troubleshooting steps of each lab in IPexpert’s CCIE R&S Lab Preparation Workbook (Volume 1). Watch and learn as the Instructor demonstrates each and every step of all 34 labs in the Volume 1, CCIE R&S 4.0 protocol-focused Workbook.

Note: Due to this being an entirely new product (just announced and introduced), this is *NOT* part of the current Blended Learning Solution (this will actually vary depending on the date in which you purchased). The former Blended Learning Solution (prior to December 2009) did not have this component, however – massive discounts are available for existing clients (who may have purchased prior to December 2009). For more details, please contact your Training Advisor at sales@ipexpert.com or directly at +1.810.326.1444 (or via live chat at www.ipexpert.com/chat).

Regards – Wayne

• Steven Clarkin CCIE #25821 (R&S)
• Erick Pineda CCIE #25871 (Voice)
• Ricardo Lezcano CCIE #25855 (Voice)
• Jeffrey Bassoff CCIE #25887 (Security)
  

Steven stated:

I have good news….I passed the CCIE R&S lab on my first attempt. I took the lab on the 27th November 2009 in Brussels and was initially told that I had failed. I was pretty sure I was very close to a pass so I knuckled down and started studying for my next attempt confident that I would nail it the next time. To my surprise early January Cisco e-mailed me to inform me that my lab had been re-marked due to a review and adjustment of the grading guidelines! The changed my score to a PASS. I didn’t believe it at first but once I’d received my number (#25821) I knew it was true!! Even so I must have checked the verification tool a hundred times just to make sure!!

I based my study preparation around your CCIE R&S Blended Learning Solution. I particularly liked the fact that it came all on a portable drive. I could therefore take the all the study materials with me wherever I went. This really helped me maximize my study time.

Preparation for my lab started back in February 2009 soon after I passed the written. From this date I started doing the Volume 1 Workbook labs. From August 2009 I stepped up my studies and was able to put in a minimum 7 hours solid every weekday, and at least 10 hours a day at weekends. I slowly worked my way through the Volume 1 labs and I did these each a couple of times. While doing these I worked my way through the VoD to really help solidify the concepts I was learning. Each week I did at least 2 of the Volume 2 Workbook labs, this helped me put those concepts into practice and train my brain to be able to cope with 6-8hr lab scenarios. Anytime that I wasn’t working or labbing I had my head buried in the IOS config guides. Hard work but very worth it.

The 4 weeks immediately before my lab I was able to take time off work and focus entirely on my studies. During this period I redid a number of the Volume 1 labs to go over topics that I was weak on. Then I redid all the Volume 2 labs. Re-doing the Volume 2 labs really helped me with speed and gave me confidence in my ability at times when I doubted it. During this 4 week period I also did all of the Volume 3 Workbook labs that had been updated to the new V4 blueprint. They are really good recreations of the actual lab exam. I particularly liked the new troubleshooting section in this workbook as it helped me work out a strategy for this section in the actual lab. This strategy was to spend no more than 10 minutes on each ticket…..This ensures you have time within the 2 hour window to go back to tickets you couldn’t complete….It worked for me.

As for the lab itself…..It was much easier than I expected. The OEQ’s were straight forward (as long as you’ve covered the blueprint in your studies). The troubleshooting and configuration sections were challenging and I found it comparable to your Volume 3 labs with a difficultly of 7-8. I would like to tell you more of my lab experience but it’s all a blur at the moment!!!

Thank you IPexpert!

Steven Clarkin
CCIE #25821 (R&S)

Erick said:

IPexpert, it’s a great company, the team really understands their clients’ needs, they help step by step in this long long journey!!!! I used the Blended Learning Solution, Proctor Labs vRack sessions and assisted to the One Week Lab Experience Bootcamp V2 & V3.  Vik is the man regarding CCIE Voice, I learned a lot of him, he tought me good, as many of my peers said before. IPexpert teaches you the technology for the real world and it’s a critic differentiator when you take the LAB.  I started this journey since version 2, unfortunately I couldn’t make it in that version, but as many of you know it is not an easy task……. Finally, I made it and got my precious number

Many thanks to IPexpert for helping me to become an Expert.

Erick Pineda
CCIE #25871 (Voice)

Ricardo commented:

I finally passed the CCIE VOICE, after lots of hard work.  I participated in the One Week Lab experience on December 2009 with Vik, and I improved my speed through remote labs with workbooks provided by IPexpert and my owns 7965 phones.

I think the remote labs of ipexpert using your owns IP Phones is the best way to practice and the IPexpert bootcamps are a good way to learn the exam topics.

Regards,

Ricardo Lezcano Herrera
CCIE #25855 (Voice)

IPexpert is proud to boast the world’s largest list of CCIE success stories, and the industry’s most complete and updated self-study portfolio for the CCIE R&S, Voice, Security and Service Provider Lab exams.  Have you also used IPexpert or Proctor Labs to help you pass the CCIE lab exam?  If so, we want to hear your story! Please email us at success@ipexpert.com

Our Volumes 1 and 2 are now completed.  These workbooks have been entirely rewritten for the 3.0 Lab Blueprint – you won’t be disappointed with the quality and amount of content and detail! They will be added to your Member’s Area today. Everyone who’s expecting a hard copy – you’ll see it soon – they will begin shipping today!

Regards – Wayne

Today’s topic is going to be the desktop phone control from Cisco Personal Communicator Client, CUPC, via CTI and its configuration both in CUPS and CUCM.

As many of you are aware of, the CUCP’s CTI phone control is performed directly from the presence client itself via CTI/QBE interface, in other words the CUCP talks to the CUCM CTI Service to control the designated desktop phone, there’s no intervention of the CUPS in the process.

First of all, perform the basic integration between CUCM and CUPS (this configuration assumes no DNS servers are in the network):

• Add the CUPS as an application server in CUCM ->System ->Application Server menu
• Assign Presence capabilities to the end user (Enable CUP and CUPC use) in CUCM ->System ->Licensing -> Capabilities Assignment
• Run the CUPS post installation setup, you can use the CUCM Admin user as the AXL user required for this setup
• Change the presence server name to IP Address in the CUPS System-> Topology menu
• Configure the Cisco UP SIP Proxy service parameter and set the domain name, go to CUPS System-> Service Parameter
• Start all the CUPS services from the Cisco Unified Serviceability-> Tools-> Service Activation Menu
• Reboot the presence server for the name change to take effect

Now, let’s configure the CTI control config specifics:

• In CUCM end user-> assign device configuration, associate the corresponding device to the user, and very important but sometimes forgotten, assign the end user to the Standard CTI Enable user group
• Also in the CUCM end user configuration, assign the end user primary extension in the Directory Number Associations section
• Make sure “Allow Control of Device from CTI” is checked in the regarding phone device and line configuration
• In CUPS-> Application-> Cisco Unified Personal Communicator-> User Settings Menu, assign the TCP CTI Gateway Profile (automatically created during the CUPS synchronization with CUCM) for the user
• Finally, log into the CUPC and control your phone desktop, you should see a window similar to this:

Sometimes a restart of CUCM CTIManager service and CUPS Services are needed in order to get CTI control working properly from CUPC

Well, remember to be very specific in your configurations, you might be asking why I didn’t mention SIP trunk configuration, device line end user association, etc. My purpose here was only to configure CTI phone control via CUPC and not to enable presence features. This approach might help you to understand every piece of CUPS, save very valuable time in your lab exam and configure exactly what you are asked for.

Try this at home!!!

Otto Sanchez
CCIE #25592 (Voice)
Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com