So the first question we can address is this:

When I’m taking the lab exam how do I know when to use an ISAKMP profile?

First off, consider this;  Does this router have more than one IPsec connection that will need me to have different phase 1 parameters negotiated.  If the answer is “yes,” then you’ll probably be using an ISAKMP profile for the task.

For Example: If you have a L2L and an EasyVPN connection to the same router you might want to use an ISAKMP profile.

Once you determine that you want to use an ISAKMP profile you next need to have some familiarity with how they work and are matched.  We’ll examine how they match on connections that we initiate.

An ISAKMP profile can be matched in two differnt ways.

1. For intiating connections
2. For terminating connections

When using and ISAKMP profile for initiating connections, the match
statement has no affect.  This is because the match statement is only used for incoming connections. But, you’ll notice when you configure an ISAKMP profile that it is deemed “incomplete” until you have a match statement.

Router(config)#crypto isakmp profile MYPROFILE

% A profile is deemed incomplete until it has match identity statements

Router(conf-isa-prof)#

So what do you do?  The simple solution is that you add a match statement for the profile to be functional.  In fact, your match statement could be anything for example::

match identity address 0.0.0.0 0.0.0.0

Another thing you’ll notice is that until you have a match command you can type additional commands but some of them will be ignored.  Note the following configuration.

Router(conf-isa-prof)#local-address Loopback0

Router(conf-isa-prof)#

*Mar 11 23:12:23.386: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up

Router(conf-isa-prof)#client auth

Router(conf-isa-prof)#client authentication ?

list  AAA authentication list to use

Router(conf-isa-prof)#client authentication list AAA

Router(conf-isa-prof)#

Router#sh run | sec isakmp
crypto isakmp profile MYPROFILE
Router#

Router#sh cry isa profile 

ISAKMP PROFILE MYPROFILE 

Ref Count = 1
   Identities matched are:
   Certificate maps matched are:
   keyring(s): <none>
   trustpoint(s): <all>
   Interface binding: Loopback0 (0.0.0.0:global)
Router#

Router#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)#crypto isakmp profile MYPROFILE

% A profile is deemed incomplete until it has match identity statements

Router(conf-isa-prof)#match identity address 0.0.0.0

Router(conf-isa-prof)#end

Router#

Next we show the profile:

Router#sh run | sec isakmp

crypto isakmp profile MYPROFILE

   match identity address 0.0.0.0 

   client authentication list AAA

   local-address Loopback0

Router#

Router#sh cry isa profile

ISAKMP PROFILE MYPROFILE 

Ref Count = 1
   Identities matched are:
    ip-address 0.0.0.0
   Certificate maps matched are:
   keyring(s): <none>
   trustpoint(s): <all>
   Interface binding: Loopback0 (0.0.0.0:global)

So now the configuration takes effect. Certainly it’s minute details like this that can make all the difference in your time management on lab day.

Here is a list of useful links related to ISAKMP profiles. I recommend spending the time to become familiar with the behavior of ISAKMP profiles.  Once you get familiar you’ll probably really enjoy using them.

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/prod_white_paper0900aecd8034bd59.html

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801eafcb.shtml

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008032cd24.shtml

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cert_isakmp_map_ps6441_TSD_Products_Configuration_Guide_Chapter.html

-Regards

Brandon Carroll – CCIE #23837

Senior Technical Instructor – IPExpert

Mailto: bcarroll@ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130

First of all, in order to qualify, students need to undergo the authorized 360 “workshop” (be sure to recognize that it’s 2 weeks of training and quite a bit more expensive than some of the other options out there) and, as usual, waiver requests need to be approved by the instructor from the workshop. The waiver is then submitted to Cisco for approval and approved or disapproved without clear indication of success of that request. The program is temporary and begins on April 1^st 2010… just as another waiver program (that seems to have failed) is about to end.

The IPexpert team is determined to provide our students with the best possible training material available on the market. For that reason, we pledge right here and right now, that we will have the best preparation material on the market for the Core Knowledge section of the lab exams… by the time this program goes live. Yes, by April 1^st of this year. All IPexpert clients will have access to an OEQ / Core Knowledge eBook (we will be delivering eBooks for the R&S, Voice, Security and Service Provider labs).

Combine that with our current products and offerings:

• World-class Video on Demand (with supplemental Student Slide & Topology Books)
• World-class Audio on Demand (lecture different than VOD)
• World-class ILT Training (Week 1)
• World-class OWLE Training (Week 2)
• World-class Workbooks (and accompanying Detailed Solution Guides)
• World-class Workbook Video Walkthroughs (Hundreds of hours of video solutions)
• World-class Rack Rental at ProctorLabs (Latest & greatest hardware, online, with an unmatched GUI)
• World-class Online Community at OnlineStudyList.com (free online mentoring avenues)
• World-class Technical Support for all issues
• The largest alumni of successful CCIE students overall

In addition to all of the above (current offerings and upcoming FREE Core Knowledge eBook), we are shortly going to introduce two additions to our family of products in all tracks. We call them “vLectures” and “Ask the Expert Sessions”.

vLectures will be 2-4 hour long, live online lectures, delivered by one or more of our instructors on a given subject through our online classroom. These sessions will also be recorded and posted to our student accounts.

Ask the Expert sessions will be 2-4 long online sessions with one or more of our instructors and will focus on either a specific technology or a given lab from our Workbooks. Students attending the sessions will interact with the instructors, ask the questions and gain invaluable expertise. These will, also, be recorded and posted to student accounts.

Oh and one more thing…

These three new products … are going to be FREE for all our current BLS customers in all tracks. No need to qualify or pay premium.

Do our students need OEQ waivers? We think not. Here at IPexpert, we deliver on our promise to make you experts – with no shortcuts. We don’t think you need to “purchase” the ability to pass or “waive” the OEQ portion of your lab (by paying upwards of x2 or x3 as much for less training, less support and less proven success).

Good idea by the 360 team, or an act of desperation to salvage a failing program? You make the call…

Regards,

- Wayne A. Lawson II (CCIE #5244) – Founder & President, IPexpert, Inc.

However, there are certain aspects of storm control that are not widely known and some that, for this or other reason, are completely wrongly understood in CCIE community. I will mention the less understood bit first and then get to the business of dispelling with one myth.

Storm control in its functionality is very similar to traffic policing. However, unlike traffic policing that can police traffic based on several criteria, like IP address, MAC address, source or destination ports, etc., storm control can act only based on traffic type. This, we all know.

What is less widely known is that storm control, unlike traffic policing, has a fixed interval during which it performs its limiting function. This interval is exactly one second. When configured not to completely disable the port, storm control will measure and completely block the inbound traffic on these fixed intervals, if it exceeds the specified threshold. For further reading, take a look at the Catalyst 3560 configuration guide, section titled Understanding Storm Control.

The Myth

The widely accepted truth is that, when it comes to storm control “broadcast traffic is a subset of multicast traffic”… or was it the other way round? It doesn’t really matter, the reason here lies in the format of the MAC addresses. We all know that broadcast MAC address is “all ones”, or FFFF.FFFF.FFFF in hex. We also know that all multicast MAC addresses begin with 0100.5E. And here’s the catch. See that “1″ – that one comes from so-called I/G bit in the address, which is used to signify number of recipients. If it’s 0, then it’s one host. If it’s one, then it’s “a group”. Now, if we look at the broadcast address above – it also has “1″ in this field – of course it does, it has 1 in every bit. The myth then goes on to tell us that because of this fact, switches are “unable to differentiate between broadcast and multicast” traffic.

Dispelling the Myth

Let’s configure a simple testbed consisting of one router and one switch. I will use R1 and Cat2 in one of the ProctorLabs racks. Let’s create a very basic configuration on R1 and Cat2.

R1(config)#interface FastEthernet0/1
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#no cdp enable
R1(config-if)#no shutdown

Cat2(config)#interface FastEthernet0/1
Cat2(config-if)#switchport access vlan 1
Cat2(config-if)#switchport mode access
Cat2(config-if)#switchport nonegotiate
Cat2(config-if)#spanning-tree portfast
Cat2(config-if)#spanning-tree bpdufilter enable
Cat2(config-if)#no cdp enable

The reason for disabling CDP is that I don’t want any multicast traffic on the port whatsoever. Now, let’s see if storm control is configured.

Cat2#show storm-control FastEthernet0/1 unicast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Cat2#show storm-control FastEthernet0/1 multicast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Cat2#show storm-control FastEthernet0/1 broadcast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------

Of course it isn’t. Next, let’s configure very low-threshold storm control for broadcast traffic and generate some of it from R1 and see what happens.

Cat2(config)#interface FastEthernet0/1
Cat2(config-if)#storm-control action trap
Cat2(config-if)#storm-control broadcast level 0.01

R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0
Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

Cat2#show storm-control FastEthernet0/1 broadcast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/1      Blocking          0.01%        0.01%       17.84%

We can clearly see that storm control is blocking our broadcasts. That’s what we expected. But, what happens if we generate a lot of multicast traffic? Let’s try, but before we do that, we need to configure few more things on R1.

R1(config)#ip multicast-routing
R1(config)#interface FastEthernet0/1
R1(config-if)#ip pim dense-mode

Cat2(config)#interface FastEthernet0/1
Cat2(config-if)#storm-control multicast level 0.01

Now, let’s verify that storm control is configured, but not actually blocking anything.

Cat2#show storm-control broadcast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/1      Forwarding        0.01%        0.01%        0.00%
Cat2#show storm-control multicast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/1      Forwarding        0.01%        0.01%        0.00%

Very good. Now, let’s generate some multicast traffic and see what happens to our storm control!

R1#ping 239.0.0.255 size 15000 repeat 2500 timeout 0

Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 239.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

Cat2#show storm-control multicast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/1      Blocking          0.01%        0.01%       11.08%
Cat2#show storm-control broadcast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/1      Forwarding        0.01%        0.01%        0.00%

Clearly, multicast is being blocked, but not the broadcast! What happens now if we generate a lot of broadcast?

R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0 

Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

Cat2#show storm-control broadcast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/1      Blocking          0.01%        0.01%       16.98%
Cat2#show storm-control multicast
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Fa0/1      Forwarding        0.01%        0.01%        0.00%

Are We Testing Properly?

What we know at this point is that switch tells us that it’s not blocking multicast when we send broadcast storm and vice versa. What we don’t know is if the traffic is actually reaching anywhere… and how much of it. Luckily, we have more routers to help us here. Let’s introduce R2 to our topology and use the interface on the same switch. Brief config to get things rolling.

Cat2(config)#interface FastEthernet0/2
Cat2(config-if)#switchport access vlan 1
Cat2(config-if)#switchport mode access
Cat2(config-if)#switchport nonegotiate
Cat2(config-if)#spanning-tree bpdufilter enable
Cat2(config-if)#spanning-tree portfast
Cat2(config-if)#no cdp enable
Cat2(config-if)#no keepalive

R2(config)#interface GigabitEthernet0/1
R2(config-if)#ip address 10.0.0.2 255.255.255.0
R2(config-if)#load-interval 30
R2(config-if)#no cdp enable
R2(config-if)#no keepalive
R2(config-if)#no shutdown
R2(config-if)#^C
R2#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
R2#clear counters

Note that I used “no keepalive” command. This is because I don’t want interface counters to show any traffic except the one we are going to generate. We will also have interface counters show 30 second statistics. We have connectivity with R1, so let’s test. First, we ping broadcast and see what happens. Note, we need to ensure that ping lasts for than one second! 2500 packets should be enough.

R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0
Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
  Internet address is 10.0.0.2/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 100Mb/s, media type is RJ45
  output flow-control is XON, input flow-control is XON
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:11, output 00:00:11, output hang never
  Last clearing of "show interface" counters 00:00:21
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 212000 bits/sec, 16 packets/sec
  30 second output rate 212000 bits/sec, 16 packets/sec
     754 packets input, 1141556 bytes, 0 no buffer
     Received 754 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 2 multicast, 0 pause input
     0 input packets with dribble condition detected
     754 packets output, 1141556 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out
R2#clear counters

We can obviously see that the traffic was blocked. What we don’t know is which storm control statement did it. Multicast or broadcast. Let’s remove multicast one and try again.

Cat2(config)#interface FastEthernet0/1
Cat2(config-if)#no storm-control multicast level 0.01

R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0
Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
  Internet address is 10.0.0.2/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 100Mb/s, media type is RJ45
  output flow-control is XON, input flow-control is XON
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:09, output 00:00:09, output hang never
  Last clearing of "show interface" counters 00:02:11
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 231000 bits/sec, 19 packets/sec
  30 second output rate 231000 bits/sec, 19 packets/sec
     687 packets input, 1040118 bytes, 0 no buffer
     Received 687 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 6 multicast, 0 pause input
     0 input packets with dribble condition detected
     687 packets output, 1040118 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out
R2#clear counters

Very similar result. Another test, let’s return multicast storm control, remove broadcast one and re-test broadcast ping.

Cat2(config)#interface FastEthernet0/1
Cat2(config-if)#no storm-control broadcast level 0.01
Cat2(config-if)#storm-control multicast level 0.01

R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0
Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
  Internet address is 10.0.0.2/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 100Mb/s, media type is RJ45
  output flow-control is XON, input flow-control is XON
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:15, output 00:00:15, output hang never
  Last clearing of "show interface" counters 00:01:55
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 657000 bits/sec, 54 packets/sec
  30 second output rate 657000 bits/sec, 54 packets/sec
     2500 packets input, 3785000 bytes, 0 no buffer
     Received 2500 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 5 multicast, 0 pause input
     0 input packets with dribble condition detected
     2500 packets output, 3785000 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out
R2#clear counters

OK, how about multicast ping? Let’s try right away and see what happens. Remember, now we have multicast storm control configured. Before we do that, we need to ensure that multicast traffic is flooded by our switch.

Cat2(config)#no ip igmp snooping

R1#ping 239.0.0.255 size 15000 repeat 2500 timeout 0
Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
  Internet address is 10.0.0.2/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 100Mb/s, media type is RJ45
  output flow-control is XON, input flow-control is XON
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:12:45, output 00:10:12, output hang never
  Last clearing of "show interface" counters 00:00:16
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 406 multicast, 0 pause input
     0 input packets with dribble condition detected
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out
R2#clear counters

We can see that storm control works, as expected. Let’s apply broadcast storm control and remove multicast one, before we end this test.

Cat2(config)#interface FastEthernet0/1
Cat2(config-if)#no storm-control multicast level 0.01
Cat2(config-if)#storm-control broadcast level 0.0

R1#ping 239.0.0.255 size 15000 repeat 2500 timeout 0
Type escape sequence to abort.
Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds:
......................................................................
[... a lot of pings ...]

R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
  Internet address is 10.0.0.2/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 100Mb/s, media type is RJ45
  output flow-control is XON, input flow-control is XON
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:15:41, output 00:01:54, output hang never
  Last clearing of "show interface" counters 00:00:19
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 2502 multicast, 0 pause input
     0 input packets with dribble condition detected
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Counter-Arguments

The test above doesn’t test one specific scenario in which we have the mix of broadcast and multicast traffic coming into the port with the storm-control configured. According to some documentation (Catalyst 6500 configuration guide), this particular scenario can have issues if both multicast and broadcast storm control are configured. However, the same warning is not present in the documentation for Catalyst 3560 switches, leading me to believe that these switches do not suffer from the effect described in that document.

Conclusion

While this would require more thorough testing, from this initial test, all I can say is that myth has been dealt a heavy blow. I don’t see that broadcasts are blocked with multicasts, or the other way round. What do you think – is this myth busted? :-)

I would like to thank my fellow IPexpert instructors, Tyson Scott and Brandon Carroll, who contributed greatly to this research.

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

If you’re waiting on your CCIE Security AoD and SlideBook – you should now have it added to your Member’s Area. If you don’t – please contact support@ipexpert.com.

Thanks – Wayne

Please Note: In these example, we are using ProctorLabs Pod #111. Please, use Pod assigned to your session to try things out.

Using The Terminal Server

Picture 1 below shows the portion of your ProctorLabs user interface from which you can initiate connections to various devices.

On the top of the selection is the link called “Terminal Server”. Clicking on this link should open the the link using your operating systems’ Telnet URL handler and connect to ProctorLabs terminal server, allocated for your session. Take note here that Windows 7 doesn’t have Telnet installed by default. Quick search online should help you enable both Telnet client and Telnet URL handlers in Internet Explorer. The remainder of this text assumes that both work.

When you click on the Terminal Server link, you should see the connection open to the Terminal Server. Log in with your ProctorLabs username and password.

Connected to pod111ts1.proctorlabs.com.
Escape character is '^]'.

         ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
      WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

    WARNING:  This system is for the use of authorized clients only.
          Unauthorized access is a violation of federal, state,
                        civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username: username
Password: password

PL-POD-111-TS-RS#

You are now connected to Terminal Server. You can see devices connected to it by typing “show hosts”

PL-POD-111-TS-RS#show hosts
Default domain is not set
Name/address lookup uses static mappings

Host                      Port  Flags      Age Type   Address(es)
BB3                       2013  (perm, OK) **   IP    10.1.1.1
BB2                       2012  (perm, OK) **   IP    10.1.1.1
R9                        2009  (perm, OK) **   IP    10.1.1.1
R8                        2008  (perm, OK) **   IP    10.1.1.1
R7                        2007  (perm, OK) **   IP    10.1.1.1
R6                        2006  (perm, OK) **   IP    10.1.1.1
R5                        2005  (perm, OK) **   IP    10.1.1.1
R2                        2002  (perm, OK) **   IP    10.1.1.1
Cat4                      2016  (perm, OK) **   IP    10.1.1.1
Cat3                      2015  (perm, OK) **   IP    10.1.1.1
Cat2                      2014  (perm, OK) **   IP    10.1.1.1
Cat1                      2010  (perm, OK) **   IP    10.1.1.1
BB1                       2011  (perm, OK) **   IP    10.1.1.1
R4                        2004  (perm, OK) **   IP    10.1.1.1
R1                        2001  (perm, OK) **   IP    10.1.1.1

If we take the example of R1 above, we can see that you can connect to it by telnetting to port 2001. You can do so from the server, by just typing “R1″.

PL-POD-111-TS-RS#r1
Translating "r1"
Trying R1 (10.1.1.1, 2001)... Open

         ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
      WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

    WARNING:  This system is for the use of authorized clients only.
          Unauthorized access is a violation of federal, state,
                        civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username: username
Password: password

            You are on line number: 1

Router>

We are now connected to R1. We can configure it or do whatever we like. We can go back to the Terminal Server, by typing escape sequence <ctrl><shift> 6 followed by x. We are now back to terminal server, BUT – we are not yet disconnected from R1. Let’s connect to R2.

Router><ctrl><shift>6 x
PL-POD-111-TS-RS#r2
Translating "r2"
Trying R2 (10.1.1.1, 2002)... Open

         ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
      WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

    WARNING:  This system is for the use of authorized clients only.
          Unauthorized access is a violation of federal, state,
                        civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username: username
Password: password

            You are on line number: 2

Router#

Let’s go back to R1. Press the escape sequence to go back to terminal server. There, type “show sessions”.

Router#<ctrl><shift>6 x
PL-POD-111-TS-RS#show sessions
Conn Host                Address             Byte  Idle Conn Name
   1 r1                  10.1.1.1               0     0 r1
*  2 r2                  10.1.1.1               0     0 r2

We can see two active sessions. One is connected to R1 and the other one to R2. We can also see small “*” next to R2. If we just press <enter>, we will return to the active session – marked by a star! Note the session numbers just before host name. We can use that to resume some other session. If we want to resume our session to R1, we can type “resume 1″, or simply “1″. Give it a try.

If you wish to destroy the session, type “disconnect <num>” on the terminal server, to disconnect the session <num>. Let’s disconnect our session 1.

PL-POD-111-TS-RS#disconnect 1
Closing connection to r1 [confirm]
PL-POD-111-TS-RS#show sessions
Conn Host                Address             Byte  Idle Conn Name
*  2 r2                  10.1.1.1               0     0 r2

Session 1 is gone. It will come back when we connect to, say, R4:

PL-POD-111-TS-RS#r4
Translating "r4"
Trying R4 (10.1.1.1, 2004)... Open

         ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
      WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

    WARNING:  This system is for the use of authorized clients only.
          Unauthorized access is a violation of federal, state,
                        civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username:<ctrl><shift>6 x
PL-POD-111-TS-RS#show sessions
Conn Host                Address             Byte  Idle Conn Name
*  1 r4                  10.1.1.1               0     0 r4
   2 r2                  10.1.1.1               0     0 r2

Beware of this session number reuse, especially when time-pressed. You may want to open your devices in logical order and use them that way. If you decide to do so, it may be a wise idea to configure “exec-timeout” appropriately on destination hosts, otherwise your sessions may time out.

Once you get the hang of the idea, using Terminal Server is really quick and powerful way to access all your Proctor Labs devices.

However, some of use think there are more efficient ways. Read on for few suggestions.

Direct Sessions to Devices

Remember when we looked at Terminal Server and we connected to port 2001 for R1? You don’t have to connect to terminal server to open that session. You can telnet directly to port 2001 from your own computer, using any telnet client, or by clicking on the appropriate device from your ProctorLabs Web GUI! Let’s connect to R1 by clicking on it.

Connected to pod111ts1.proctorlabs.com.
Escape character is '^]'.

         ****PROCTOR LABS, INC. SECURE ONLINE RACK SYSTEM****
      WELCOME to Proctor Labs, Inc. CCIE preparation vRack.

    WARNING:  This system is for the use of authorized clients only.
          Unauthorized access is a violation of federal, state,
                        civil and criminal laws.

http://www.ProctorLabs.com

User Access Verification

Username: username
Password: password

            You are on line number: 1

Router>

We are now directly connected to R1! If you click on some other router or other device, you will be connected directly to it!

You should note that you cannot have more than one connection to the same device. In a case you are getting “Connection Refused” message, you need to telnet to Terminal Server and clear the existing session to the device you wish to connect to.

Using direct sessions to devices is an efficient method. Using built-in telnet client in Windows (and some other operating systems) on the other hand is not. Many of them lack features like increased scroll buffer, resizable windows, etc. For that reason, there are other clients that can be used instead. Here are some of the more popular ones.

SecureCRT (Windows)

SecureCRT is the terminal application available you in the CCIE lab. Newer versions of it support some options not available during the exam (for example, tabs), but those advanced features may prove to be useful during studies, when you are not trying to replicate the exact environment in the lab.

The most efficient way to use SecureCRT is to utilize its built-in bookmarks, called Connections. This system can be accessed by choosing File->Connect menu, or <alt>-c keyboard shortcut. Screenshot below is an example of bookmarks created for ProctorLabs Routing and Switching Pod 111.

Double-clicking on any of the bookmarked devices will open a new tab (or window) with the connection to the appropriate device. What’s nice with this approach is that the title bar of the window will be automatically set to the name of the device.

Of course, the most difficult and time consuming bit is actually building bookmarks. Well, I have special treat for you here. We’ve already done it for you – for all our pods in all our tracks, you can get them here: ProctorLabs-SecureCRT.

Installing IPexpert’s Bookmarks to SecureCRT

Now that you have the bookmarks, it’s time to install them. Please, follow this step-by-step procedure for an easy install.

1. Download the ProctorLabs-SecureCRT.zip above and save it to temporary folder
2. Open SecureCRT and find Options -> Global Options menu
3. Open the above menu and select General from the tree on the left. Copy “Configuration folder” path to clipboard. See picture below:



4. Close SecureCRT, find and open that folder in Windows Explorer. Go to subfolder called Sessions. If one does not exists, please create it.
5. Extract the contents of the ProctorLabs-SecureCRT.zip file into this folder. You should now have subfolder called ProctorLabs.
6. Start SecureCRT and select File->Connect.

You should have all of our bookmarks in your SecureCRT now!

Putty and Putty Connection Manager (Windows)

Putty is a free terminal application for Windows, which is proving to be very popular. By itself, it provides cumbersome bookmarks management, however, there is 3rd party add-on, called Putty Connection Manager. If you happen to be Putty user, look for this one online – you will be pleasantly surprised. To see it in action, just watch our Routing and Switching Video on Demand or a screenshot below.

Just as with SecureCRT, most of the work is to create bookmarks for your Pod. If you take a look at the screenshot above, you will notice that it shows many pods. Yes, you guessed it right! You can get database file here: ProctorLabs-PuttyCM.

Installing IPexpert’s Bookmarks to Putty Connection Manager

This operation is a little bit different than the one with SecureCRT. Especially so because there are two ways in which it can be done (CCIEs love alternative solutions, don’t we?). After you have downloaded the ProctorLabs-PuttyCM.zip file above, extract the contents to a temporary folder.

If you don’t already have any bookmarks in your Putty Connection Manager, you can copy the file to more permanent location and change extension from XML to DAT. Next, from File menu, select Open and navigate to your ProctorLabs-PuttyCM.dat file. When you open the database, make sure that Connection Manager option in View menu is enabled. You should now have nice ProctorLabs bookmarks tree on the right.

If you already use Putty Connection Manager, using another database may or may not be the thing you want. Another approach is to import the entries from XML. You can use the same file, but in order to import bookmarks, you need to have an open database. To initiate import process, go to Database menu, select Import and Export menu. Chose option to import and in the next step navigate to ProctorLabs-PuttyCM.xml file. When you have finished, your existing bookmarks should be updated with new ProctorLabs ones!

Whatever step you used, you can make the database as the default one to open every time you open Putty Connection Manager and you are all set.

But… what if you are using some other operating system, say, Mac or Linux? Stay tuned, that’s coming soon!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert

Mailto: markom@ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130

Ethernet is an example of broadcast multi-access network where devices can communicate with one another at Layer 2 within the same broadcast domain. If a rouge device is introduced into a VLAN, security issues may arise because all devices start sharing the same Layer 2 network. An example may be a web hosting company that provides space on a server it owns or leases for use by its clients. If all servers reside in the same VLAN and attacker gets access to one of them, other machines may also be compromised because typically there are no L2 firewalls placed between the devices. The traditional, but not scalable solution to this problem, was to assign a separate VLAN to each customer. Using Private VLANs feature addresses the scalability problem and provides IP address management benefits for service providers and Layer 2 security for customer.

Private VLAN feature is composed of two VLAN types :

A primary VLAN is the unique and common VLAN identifier of the whole private VLAN domain and of all its VLAN ID pairs. This is the VLAN we will “divide” into sub-VLANs. The promiscuous port belongs to the primary VLAN and this port can talk to isolated ports as well as community ports and vice versa (and also to other promiscuous ports if they exist).

There are two types of secondary VLANs:

• Isolated VLANs – Ports within an isolated VLAN (isolated ports) cannot communicate with each other at the Layer 2 level. Note that it is enough to have only one Isolated VLAN for each Primary VLAN.

• Community VLANs – Ports within a community VLAN (community ports) can communicate with each other but cannot communicate with ports in other communities at the Layer 2 level.

Private VLANs, contrary to Protected Ports, can span multiple switches. A feature of private VLANs across multiple switches is that traffic from an isolated port in one switch does not reach an isolated port on another switch.

In our example primary VLAN is set to 100. Secondary VLANs are 201 (isolated) and 202 (community). Here is the topology :

IP addressing scheme and configuration :

R1– 10.1.1.1

R2– 10.1.1.2

R6 – 10.1.1.6

R7 – 10.1.1.7

Cat1 :

Because VTP (version 1 and 2 ) does not support private VLANs, you must manually configure private VLANs on all switches in the Layer 2 network using VTP mode Transparent.

vtp mode transparent

vlan 201

private-vlan isolated

vlan 202

private-vlan community

vlan 100

private-vlan primary

private-vlan association 201-202

interface FastEthernet0/1

switchport private-vlan mapping 100 201-202

switchport mode private-vlan promiscuous

interface FastEthernet0/2

switchport private-vlan host-association 100 202

switchport mode private-vlan host

Cat2 :

vtp mode transparent

vlan 201

private-vlan isolated

vlan 202

private-vlan community

vlan 100

private-vlan primary

private-vlan association 201-202

interface FastEthernet0/6

switchport private-vlan host-association 100 201

switchport mode private-vlan host

interface FastEthernet0/7

switchport private-vlan host-association 100 202

switchport mode private-vlan host

Now let’s make sure VLANs were created appropriately :

Cat1#sh vlan private-vlan type

Vlan Type

---- -----------------

100  primary

201  isolated

202  community

Cat1#sh vlan private-vlan

Primary Secondary Type              Ports

------- --------- ----------------- ------------------------------------------

100     201       isolated          Fa0/1

100     202       community         Fa0/1, Fa0/2

CAT2:

Cat2(config)#do sh vlan private-vlan

Primary Secondary Type              Ports

------- --------- ----------------- ------------------------------------------

100     201       isolated          Fa0/6

100     202       community         Fa0/7

Cat2(config)#do sh int f0/6 status

Port      Name               Status       Vlan       Duplex  Speed Type

Fa0/6                        connected    100,201    a-full  a-100 10/100BaseTX

Promiscuous port device (R1) have connectivity to all devices within a primary VLAN :

R1#ping 10.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

R1#ping 10.1.1.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

R1#ping 10.1.1.6

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.6, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R1#ping 10.1.1.7

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.7, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

R1#sh arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  10.1.1.1                -   000a.b81a.5030  ARPA   FastEthernet0/0

Internet  10.1.1.2               38   0011.93fc.1ca2  ARPA   FastEthernet0/0

Internet  10.1.1.6               39   000a.b819.bd30  ARPA   FastEthernet0/0

Internet  10.1.1.7               39   000a.b81a.5448  ARPA   FastEthernet0/0

Moving on to R7 – because R2 is in the same community VLAN as R7, those routers can communicate with each other. R6, however can only reach to R1 which is connected to the promiscuous port :

R7#ping 10.1.1.6

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.6, timeout is 2 seconds:

...

Success rate is 0 percent (0/3)

R7#ping 10.1.1.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R7#sh arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  10.1.1.1               43   000a.b81a.5030  ARPA   FastEthernet0/0

Internet  10.1.1.2               42   0011.93fc.1ca2  ARPA   FastEthernet0/0

Internet  10.1.1.6                0   Incomplete      ARPA

Internet  10.1.1.7                -   000a.b81a.5448  ARPA   FastEthernet0/0

R6:

R6#ping 10.1.1.7

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.7, timeout is 2 seconds:

..

Success rate is 0 percent (0/2)

R6#ping 10.1.1.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:

..

Success rate is 0 percent (0/2)

R6#sh arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  10.1.1.1               45   000a.b81a.5030  ARPA   FastEthernet0/0

Internet  10.1.1.2                0   Incomplete      ARPA

Internet  10.1.1.6                -   000a.b819.bd30  ARPA   FastEthernet0/0

Internet  10.1.1.7                0   Incomplete      ARPA

Now try to remove VLAN 202 (community) from the trunk on Cat1 and see what happens. Remember that trunk ports carry traffic from regular VLANs and also from primary, isolated, and community VLANs, unless pruned. Features like Spanning-Tree and DHCP Snooping apply only to the primary VLAN but are automatically propagated to secondary VLANs.

Cat1(config)#int range f0/23 – 24

Cat1(config-if-range)#sw trunk allowed vlan remove 202

Cat1(config-if-range)#do sh int trunk

Port        Mode             Encapsulation  Status        Native vlan

Fa0/23      on               802.1q         trunking      1

Fa0/24      on               802.1q         trunking      1

Port        Vlans allowed on trunk

Fa0/23      1-201,203-4094

Fa0/24      1-201,203-4094

Port        Vlans allowed and active in management domain

Fa0/23      1,100,201

Fa0/24      1,100,201

Port        Vlans in spanning tree forwarding state and not pruned

Fa0/23      1,100,201

Fa0/24      1,100,201

R2:

R2#ping 10.1.1.7

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.7, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Cat2#sh span vlan 100 root

Root    Hello Max Fwd

Vlan                   Root ID          Cost    Time  Age Dly  Root Port

---------------- -------------------- --------- ----- --- ---  ------------

VLAN0100         32868 0019.060c.4f80        19    2   20  15  Fa0/23

Cat2#sh span vlan 201 root

Root    Hello Max Fwd

Vlan                   Root ID          Cost    Time  Age Dly  Root Port

---------------- -------------------- --------- ----- --- ---  ------------

VLAN0201         32969 0019.060c.4f80        19    2   20  15  Fa0/23

Piotr Kaluzny

CCIE #25665 (Security), CCSP, CCNP

Sr. Support Engineer IPexpert, Inc.

URL: http://www.IPexpert.com

R6(config)# cry isa keepalive 10 2 on-demand

R6#ping 10.8.8.8 so l0

R6#sh cry isa sa de

Codes: C - IKE configuration mode, D - Dead Peer Detection

K - Keepalives, N - NAT-traversal

T - cTCP encapsulation, X - IKE Extended Authentication

psk - Preshared key, rsig - RSA signature

renc - RSA encryption

IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

1001  6.6.6.6         8.8.8.8                  ACTIVE des  sha  psk  1  23:57:24 D

Engine-id:Conn-id =  SW:1

R6#sh cry isa peers de

Peer: 8.8.8.8 Port: 500 Local: 6.6.6.6

Phase1 id: 8.8.8.8

flags:

NAS Port: 0 (Normal) DPD information, struct 0x49725E70:

Last_received: 145, dpd threshold (elapsed) 0

my_last_seq_num: 0x15E8C362, peers_last_seq_num: 0x0

sent_and_waiting: FALSE

IKE SAs: 1 IPSec SA bundles: 1

last_locker: 0x43F69448, last_last_locker: 0x0

last_unlocker: 0x0, last_last_unlocker: 0x0

R6 :

Feb  2 20:35:02.087: ISAKMP: DPD received KMI message.

Feb  2 20:35:02.087: ISAKMP: set new node 861956653 to QM_IDLE

Feb  2 20:35:02.087: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE protocol 1

spi 1218169912, message ID = 861956653

Feb  2 20:35:02.087: ISAKMP:(1001): seq. no 0x15E8C367

Feb  2 20:35:02.087: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE

Feb  2 20:35:02.087: ISAKMP:(1001):Sending an IKE IPv4 Packet.

Feb  2 20:35:02.087: ISAKMP:(1001):purging node 861956653

Feb  2 20:35:02.099: ISAKMP (1001): received packet from 8.8.8.8 dport 500 sport 500 Global (I) QM_IDLE

R6#

Feb  2 20:35:02.099: ISAKMP: set new node -1309733009 to QM_IDLE

Feb  2 20:35:02.099: ISAKMP:(1001): processing HASH payload. message ID = -1309733009

Feb  2 20:35:02.099: ISAKMP:(1001): processing NOTIFY DPD/R_U_THERE_ACK protocol 1

spi 0, message ID = -1309733009, sa = 498273E8

Feb  2 20:35:02.099: ISAKMP:(1001): DPD/R_U_THERE_ACK received from peer 8.8.8.8, sequence 0x15E8C367

Feb  2 20:35:02.099: ISAKMP:(1001):deleting node -1309733009 error FALSE reason "Informational (in) state 1"

Feb  2 20:35:02.099: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY

Feb  2 20:35:02.099: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Feb  2 20:35:03.971: ISAKMP (1001): received packet from 6.6.6.6 dport 500 sport 500 Global (R) QM_IDLE

Feb  2 20:35:03.975: ISAKMP: set new node 861956653 to QM_IDLE

Feb  2 20:35:03.975: ISAKMP:(1001): processing HASH payload. message ID = 861956653

Feb  2 20:35:03.975: ISAKMP:(1001): processing NOTIFY DPD/R_U_THERE protocol 1

spi 0, message ID = 861956653, sa = 484997D4

Feb  2 20:35:03.975: ISAKMP:(1001):deleting node 861956653 error FALSE reason "Informational (in) state 1"

Feb  2 20:35:03.975: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY

Feb  2 20:35:03.975: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Feb  2 20:35:03.975: ISAKMP:(1001):DPD/R_U_THERE received from peer 6.6.6.6, sequence 0x15E8C367

Feb  2 20:35:03.975: ISAKMP: set new node -1309733009 to QM_IDLE

Feb  2 20:35:03.975: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1

spi 1224937472, message ID = -1309733009

Feb  2 20:35:03.975: ISAKMP

Feb  2 20:35:03.975: ISAKMP:(1001): sending packet to 6.6.6.6 my_port 500 peer_port 500 (R) QM_IDLE

Feb  2 20:35:03.975: ISAKMP:(1001):Sending an IKE IPv4 Packet.

Feb  2 20:35:03.979: ISAKMP:(1001):purging node -1309733009

Feb  2 20:35:03.979: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_MESG_KEEP_ALIVE

Feb  2 20:35:03.979: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

ip access-list ext OUTSIDE_IN

deny udp any any eq 500

permit ip any any

int f0/0

ip access-gr OUTSIDE_IN in

R6#ping 10.8.8.8 so l0 rep 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:

Packet sent with a source address of 10.6.6.6

!

Success rate is 100 percent (1/1), round-trip min/avg/max = 12/12/12 ms

R6#

Feb  2 20:41:42.243: ISAKMP: DPD received KMI message.

Feb  2 20:41:42.243: ISAKMP: set new node -426028058 to QM_IDLE

Feb  2 20:41:42.243: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE protocol 1

spi 1218169912, message ID = -426028058

Feb  2 20:41:42.243: ISAKMP:(1001): seq. no 0x15E8C368

Feb  2 20:41:42.243: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE

Feb  2 20:41:42.243: ISAKMP:(1001):Sending an IKE IPv4 Packet.

Feb  2 20:41:42.243: ISAKMP:(1001):purging node -426028058

R6#

Feb  2 20:41:44.243: ISAKMP:(1001):DPD incrementing error counter (1/5)

Feb  2 20:41:44.243: ISAKMP: set new node -537001878 to QM_IDLE

Feb  2 20:41:44.243: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE protocol 1

spi 1228750056, message ID = -537001878

Feb  2 20:41:44.243: ISAKMP:(1001): seq. no 0x15E8C369

Feb  2 20:41:44.243: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE

Feb  2 20:41:44.243: ISAKMP:(1001):Sending an IKE IPv4 Packet.

Feb  2 20:41:44.243: ISAKMP:(1001):purging node -537001878

Feb  2 20:41:44.243: ISAKMP:(1001):Input = IKE_MESG_FROM_TIMER, IKE_TIMER_PEERS_ALIVE

R6#

Feb  2 20:41:44.243: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Feb  2 20:41:50.243: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

...

R6#

Feb  2 20:41:52.243: ISAKMP:(1001):DPD incrementing error counter (5/5)

Feb  2 20:41:52.243: ISAKMP:(1001):peer 8.8.8.8 not responding!

Feb  2 20:41:52.243: ISAKMP:(1001):Input = IKE_MESG_FROM_TIMER, IKE_TIMER_PEERS_ALIVE

Feb  2 20:41:52.243: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Feb  2 20:41:52.247: ISAKMP (1001): No more ipsec tunnels for this SA.

Feb  2 20:41:52.247: ISAKMP: set new node -498348067 to QM_IDLE

Feb  2 20:41:52.251: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE

Feb  2 20:41:52.251: ISAKMP:(1001):Sending an IKE IPv4 Packet.

Feb  2 20:41:52.251: ISAKMP:(1001):purging node -498348067

Feb  2 20:41:52.251: ISAKMP:(1001):Input = IKE_MESG_FROM_IPSEC, IKE_PHASE2_DEL

Feb  2 20:41:52.251: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Feb  2 20:41:52.251: ISAKMP: set new node -321941634 to QM_IDLE

Feb  2 20:41:52.251: ISAKMP:(1001): sending packet to 8

R6#.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE

Feb  2 20:41:52.251: ISAKMP:(1001):Sending an IKE IPv4 Packet.

Feb  2 20:41:52.255: ISAKMP:(1001):purging node -321941634

Feb  2 20:41:52.255: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

Feb  2 20:41:52.255: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_DEST_SA

Feb  2 20:41:52.255: ISAKMP:(1001):deleting SA reason "No reason" state (I) QM_IDLE       (peer 8.8.8.8)

Feb  2 20:41:52.255: ISAKMP: Unlocking peer struct 0x496F7F08 for isadb_mark_sa_deleted(), count 0

Feb  2 20:41:52.255: ISAKMP: Deleting peer node by peer_reap for 8.8.8.8: 496F7F08

Feb  2 20:41:52.259: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Feb  2 20:41:52.259: ISAKMP:(1001):Old State = IKE_DEST_SA  New State = IKE_DEST_SA

Feb  2 20:45:06.659: ISAKMP:(1002):DPD/R_U_THERE received from peer 6.6.6.6, sequence 0x7950C76E

Feb  2 20:45:06.663: ISAKMP: set new node -474901432 to QM_IDLE

Feb  2 20:45:06.663: ISAKMP:(1002):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1

Finally, R6 notifies R8 that SA has been destroyed. R8 also frees up its resources :

R8#ISAKMP:(1002):deleting SA reason "No reason" state (R) QM_IDLE       (peer 6.6.6.6)

Feb  2 20:45:14.671: ISAKMP:(1002):deleting node -119033128 error FALSE reason "Informational (in) state 1"

Feb  2 20:45:14.671: ISAKMP: set new node 116233501 to QM_IDLE

Feb  2 20:45:14.671: ISAKMP:(1002): sending packet to 6.6.6.6 my_port 500 peer_port 500 (R) QM_IDLE

Feb  2 20:45:14.671: ISAKMP:(1002):Sending an IKE IPv4 Packet.

Feb  2 20:45:14.675: ISAKMP:(1002):purging node 116233501

Feb  2 20:45:14.675: ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

Feb  2 20:45:14.675: ISAKMP:(1002):Old State = IKE_P1_COMPLETE  New State = IKE_DEST_SA

int f0/0

ip access-gr OUTSIDE_IN in

R6#ping 10.8.8.8 so l0 rep 1

R6 has destroyed the SA :

R6(config-if)#

Feb  2 20:53:36.279: ISAKMP:(1003):DPD incrementing error counter (5/5)

Feb  2 20:53:36.279: ISAKMP:(1003):peer 8.8.8.8 not responding!

Feb  2 20:53:36.279: ISAKMP:(1003):Input = IKE_MESG_FROM_TIMER, IKE_TIMER_PEERS_ALIVE

Feb  2 20:53:36.279: ISAKMP:(1003):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Feb  2 20:53:36.283: ISAKMP (1003): No more ipsec tunnels for this SA.

Feb  2 20:53:36.283: ISAKMP: set new node -466199712 to QM_IDLE

Feb  2 20:53:36.283: ISAKMP:(1003): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE

Feb  2 20:53:36.283: ISAKMP:(1003):Sending an IKE IPv4 Packet.

Feb  2 20:53:36.283: ISAKMP:(1003):purging node -466199712

Feb  2 20:53:36.283: ISAKMP:(1003):Input = IKE_MESG_FROM_IPSEC, IKE_PHASE2_DEL

Feb  2 20:53:36.283: ISAKMP:(1003):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

R8(config-if)#do sh cry isa pe

Peer: 6.6.6.6 Port: 500 Local: 8.8.8.8

Phase1 id: 6.6.6.6

Initiate some traffic from R8 :

R8#ping 10.6.6.6 so l0 rep 2

R6(config-if)#

Feb  2 20:54:50.519: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=6.6.6.6, prot=50, spi=0x26BFA9D3(650095059), srcaddr=8.8.8.8

Feb  2 20:54:50.519: ISAKMP: ignoring request to send delete notify (no ISAKMP sa) src 6.6.6.6 dst 8.8.8.8 for SPI 0x26BFA9D3

R6(config)#cry isakmp invalid-spi-recovery

R8#ping 10.6.6.6 so l0 rep 2

Feb  2 20:55:59.663: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=6.6.6.6, prot=50,

spi=0x26BFA9D3(650095059), srcaddr=8.8.8.8

Feb  2 20:55:59.667: ISAKMP: Created a peer struct for 8.8.8.8, peer port 500

Feb  2 20:55:59.667: ISAKMP: New peer created peer = 0x48DFCDF8 peer_handle = 0x80000005

Feb  2 20:55:59.667: ISAKMP: Locking peer struct 0x48DFCDF8, refcount 1 for ike_initiate_sa_for_inv_spi_recovery

Feb  2 20:55:59.667: ISAKMP: local port 500, remote port 500

Feb  2 20:55:59.667: ISAKMP:(0):found peer pre-shared key matching 8.8.8.8

Feb  2 20:55:59.667: ISAKMP:(0): Unknown DOI 0

Feb  2 20:55:59.667: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

Feb  2 20:55:59.667: ISAKMP:(0): constructed NAT-T vendor-07 ID

Feb  2 20:55:59.667: ISAKMP:(0): constructed NAT-T vendor-03 ID

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

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 post we are going to cover three things.

• The basic configuration of a Zone Based Firewall
• How to monitor the drops
• How to think like a CCIE —> You’re going to do this part!

Lets begin with the configuration. For this simple example I’ve used gns3 to create a three interface firewall. We have an inside zone, outside zone, and a dmz zone. We will have the goal of allowing TCP and UDP connections from inside to outside as wekk as dmz to outside, http from the outside to the dmz along with any other “required” connections from the outside to the inside.

The starting configurations are pretty straigt forward but Ill show them in case you want to recreate the scenario. On thing I should mention is that some confuguraiton may be added later based on out diagram. With that said, here are the configs:

R1:

R1#sh run

Building configuration…

Current configuration : 922 bytes

!

version 12.4

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet1/0

ip address 10.2.1.1 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet1/1

no ip address

shutdown

duplex auto

speed auto

!

router eigrp 100

network 1.0.0.0

network 10.0.0.0

no auto-summary

!!

!

line con 0

exec-timeout 0 0

logging synchronous

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login

!

!

end

R1#

R2:

R2#sh run

Building configuration…

Current configuration : 1098 bytes

!

version 12.4

!

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet1/0

ip address 10.2.1.2 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet1/1

ip address 10.2.3.2 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet2/0

ip address 10.2.4.2 255.255.255.0

duplex auto

speed auto

!

router eigrp 100

network 2.0.0.0

network 10.0.0.0

no auto-summary

!

!

line con 0

exec-timeout 0 0

logging synchronous

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login

!

!

end

R2#

R3:

R3#sh run

Building configuration…

Current configuration : 922 bytes

!

version 12.4

!

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

!

interface FastEthernet1/0

ip address 10.2.3.3 255.255.255.0

duplex auto

speed auto

!

router eigrp 100

network 3.0.0.0

network 10.0.0.0

no auto-summary

!

!

line con 0

exec-timeout 0 0

logging synchronous

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login

!

!

end

R3#

R4:

R4#sh run

*Jan 6 15:10:12.431: %SYS-5-CONFIG_I: Configured from console by console

R4#sh run

Building configuration…

Current configuration : 922 bytes

!

version 12.4

!

interface Loopback0

ip address 4.4.4.4 255.255.255.255

!

interface FastEthernet1/0

ip address 10.2.4.4 255.255.255.0

duplex auto

speed auto

!

router eigrp 100

network 4.0.0.0

network 10.0.0.0

no auto-summary

!

line con 0

exec-timeout 0 0

logging synchronous

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login

!

!

end

R4#

A word of caution- if you do this on your own- test connectivity before moving on. I’ve already done it so we will continue on.

Now the next step would be to define an access-list to allow http traffic into the DMZ web server. All of this configuration will be done on R2:

Ip access-list extended OUT_IN

Permit tcp any host 3.3.3.3 eq 80

Next create the class-maps that will reference the traffic in the ACL and the protocol traffic to inspect.

Class-map type inspect match-any INSIDE

Match Protocol TCP

Match Protocol UDP

Class-map type inspect match-all OUTSIDE

Match Protcol http

Match access-g name OUT_IN

Class-map type inspect match-any DMZ

Match Protocol TCP

Match Protocol UDP

Next we want to define the policy for this traffic with a policy map:

Policy-map type inspect IN_OUT

Class INSIDE

Inspect

Policy-map type inspect OUT_IN

Class OUTSIDE

inspect

Policy-map type inspect DMZ_OUT

Class DMZ

inspect

Policy-map type inspect OUT_DMZ

Class OUTSIDE

inspect

Next we create the zones:

Zone security inside

Zone security outside

Zone security dmz

Next the zone-pairs which essentially defines directionality of traffic:

Zone-pair security IN->OUT source inside destination outside

Policy-map type inspect IN_OUT

Zone-pair security OUT->IN source outside destination inside

Policy-map type inspect OUT_IN

Zone-pair security DMZ->OUT source dmz destination outside

Policy-map type inspect DMZ_OUT

Zone-pair security OUT->DMZ source outside destination dmz

Policy-map type inspect OUT_DMZ

Now assign them to the interfaces:

Interface f2/0

Zone-member security inside

Interface f1/0

Zone-member security outside

Interface f1/1

Zone-member security dmz

At this point we are pretty close to testing. First lets enable telnet on all the routers and the http server on R3.

All routers:

Line vty 0 15

password ipexpert

login

R3:

Ip http server enable

Now if all goes according to plan we should be able to telnet from R4 to R1 and R3 to R1 but not from R1 to R3 or R4. We should, however, be able to telnet to R3 on port 80, thus testing the http access.

So we test on R4:

R4#telnet 1.1.1.1

Trying 1.1.1.1 … Open

User Access Verification

Password:

R1>

And next on R3:

R3#telnet 1.1.1.1

Trying 1.1.1.1 … Open

User Access Verification

Password:

R1>

For now we can leave those sessions connected. Next lets try to telnet from the outside R1 to R3 and R4. Before we do that lets turn on a handy little command on R2:

R2(config)#ip inspect log drop-pkt

Now, when packets are dropped we should see them. So lets go back to R1 and test:

R1#telnet 4.4.4.4

Trying 4.4.4.4 …

% Connection timed out; remote host not responding

R1#telnet 3.3.3.3

Trying 3.3.3.3 …

% Connection timed out; remote host not responding

We should now see the drops on R2:

*Jan 6 17:31:55.575: %FW-6-DROP_PKT: Dropping Other session 10.2.1.1:60632 4.4.4.4:23 on zone-pair OUT->IN class class-default due to DROP action found in policy-map with ip ident 0

R2#

*Jan 6 17:32:51.143: %FW-6-LOG_SUMMARY: 4 packets were dropped from 10.2.1.1:60632 => 4.4.4.4:23 (target:class)-(OUT->IN:class-default)

R2#

*Jan 6 17:33:27.135: %FW-6-DROP_PKT: Dropping Other session 10.2.1.1:46475 3.3.3.3:23 on zone-pair OUT->DMZ class class-default due to DROP action found in policy-map with ip ident 0

R2#

*Jan 6 17:33:51.143: %FW-6-LOG_SUMMARY: 4 packets were dropped from 10.2.1.1:46475 => 3.3.3.3:23 (target:class)-(OUT->DMZ:class-default)

Remember we were going to be allowing http into the DMZ so lets test that from R1:

R1#telnet 3.3.3.3 80

Trying 3.3.3.3, 80 … Open

Now that was successful but lets verify on R2 by looking at the sessions:

R2#sh policy-map type inspect zone-pair OUT->DMZ sessions

policy exists on zp OUT->DMZ

Zone-pair: OUT->DMZ

Service-policy inspect : OUT_DMZ

Class-map: OUTSIDE (match-all)

Match: protocol http

Match: access-group name OUT_IN

Inspect

Number of Established Sessions = 1

Established Sessions

Session 676863C0 (10.2.1.1:25424)=>(3.3.3.3:80) http:tcp SIS_OPEN

Created 00:00:48, Last heard 00:00:48

Bytes sent (initiator:responder) [0:0]

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

Match: any

Drop

12 packets, 288 bytes

R2#sh policy-map type inspect zone-pair IN->OUT sessions

policy exists on zp IN->OUT

Zone-pair: IN->OUT

Service-policy inspect : IN_OUT

Class-map: INSIDE (match-any)

Match: protocol tcp

3 packets, 72 bytes

30 second rate 0 bps

Match: protocol udp

0 packets, 0 bytes

30 second rate 0 bps

Inspect

Number of Established Sessions = 1

Established Sessions

Session 67685FC0 (10.2.4.4:51576)=>(1.1.1.1:23) tcp SIS_OPEN

Created 00:07:26, Last heard 00:07:23

Bytes sent (initiator:responder) [34:71]

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

Match: any

Drop

0 packets, 0 bytes

R2#sh policy-map type inspect zone-pair DMZ->OUT sessions

policy exists on zp DMZ->OUT

Zone-pair: DMZ->OUT

Service-policy inspect : DMZ_OUT

Class-map: DMZ (match-any)

Match: protocol tcp

7 packets, 168 bytes

30 second rate 0 bps

Match: protocol udp

0 packets, 0 bytes

30 second rate 0 bps

Inspect

Number of Established Sessions = 1

Established Sessions

Session 676861C0 (10.2.3.3:18939)=>(1.1.1.1:23) tcp SIS_OPEN

Created 00:07:06, Last heard 00:07:03

Bytes sent (initiator:responder) [34:71]

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

Match: any

Drop

0 packets, 0 bytes

R2#

Now lets take this back to the real lab exam since this is a topic that you may be tested on and we want you to think like you would in the actual lab. What is missing in this configuration? Would the above configuration get you the points? Submit your answer by commenting and we will review it in the next post.

Brandon Carroll – CCIE #23837

Senior Technical Instructor – IPexpert

Mailto: bcarroll@ipexpert.com

Telephone: +1.810.326.1444

Live Assistance, Please visit: www.ipexpert.com/chat

eFax: +1.810.454.0130