magicport

ZBF Overview.

2012-07-17T00:01:00.000+05:30

• MQC-like syntax wrapper for CBAC
– Makes configuration more modular than CBAC
– Uses same CBAC inspection engine behind the
scenes.
• Allows for more granular control than CBAC
– Interfaces grouped together based on zone assignment
• E.g. zone “outside”, “inside”, “dmz”, etc.
– Firewall policy applies based on association of zones
• Called zone pairing
• E.g. “inside-to-outside” pairing, “outside-to-dmz” pairing, etc.
– Decoupling of interface and zone allows for better
maintenance
• Easy to add new “inside” or “outside” interfaces
• New interfaces automatically inherit policy applied to zone pairing.

ZBF Zone Types
• Two types of zones
– User defined zones
• E.g. “outside”, “inside”, etc.
– Self zone
• Traffic locally originated from and destined to router.

ZBF Traffic Filtering
• Intra zone traffic allowed
– E.g. “inside” to “inside”
• Inter zone traffic denied
– E.g. “outside” to “inside”
– Policy must manually define inspected/allowed
traffic flows.
• Self traffic allowed by default
– Allows for control plane sessions
• E.g. OSPF adjacency
– Can be manually filtered with policy applied to
zone pairing
• E.g. “outside-to-self” pairing.

ZBF Classification
• Like MQC, ZBPF uses class-map to match traffic flows
– class-map type inspect
– match-all vs. match-any
• Two different types of inspection classes
– Layer 3/4 class-maps
• Matches ACLs or protocols
• E.g. TCP port 23 from host 1.2.3.4
– Layer 7 class-maps
• Deep Packet Inspection (DPI)
• Application specific inspections
• E.g. HTTP POST message, SMTP recipient count, etc.

ZBF Policies
• Like MQC, ZBPF uses policy-map to apply actions
– policy-map type inspect
• Two different types of inspection policies
– Layer 3/4 policy-maps
• Calls Layer 3/4 class-map
– Layer 7 policy-maps
• Calls Layer 7 class-map
• Like MQC policy-map ends in class-default
– class-default drops all traffic by default.

ZBF Layer 3/4 Policy Map Actions
• Inspect
– CBAC stateful inspection, similar to ASA MPF inspection
– Automatically allows return flows based on state table
• Pass
– One-way manual exception
– Traffic passed inside to outside does not automatically
pass outside to inside
• Drop
• Discard packets.
• Log
– Generate syslog message
• Police
– Rate limit traffic to specified value
• Service-Policy
– Call Layer 7 policy-map for Deep Packet
Inspection.

ZBF Layer 7 Policy Map Actions.
• Applies application specific action
– Different protocols support different actions
• Actions are…
– Allow
• Allow the session through
– Reset
• Send TCP RST to terminate session
– Log
• Generate syslog message

Context Based Access Control

2012-07-16T23:53:00.004+05:30

• CBAC adds true stateful inspection to IOS
• Performs protocol-specific inspection
– Protocols matched based on port-number
– Port-map table defined with ip port-map
• Inspection rule defines protocols to inspect
– ip inspect name <NAME>
– Applies to an interface inbound or outbound
– Opens hole in ACL applied in opposite direction.

Context Based Access Control
CBAC TCP Intercept
• TCP Intercept is always on with CBAC inspection
– Only Watch Mode supported
• Configurable options:
– ip inspect max-incomplete {high|low}
– ip inspect one-minute {high|low}
– ip inspect tcp max-incomplete host (perhost
limit)
– ip inspect tcp synwait-time (watch timeout).
CBAC Scenarios.
• Users protection
– CBAC inspects users’ traffic
– Only specific protocols inspected, e.g. HTTP/DNS
– All incoming traffic blocked, returning sessions allowed
• Server protection
– CBAC inspects traffic to server
– Only selected traffic allowed from server.
– TCP Intercept + Protocol Enforcement.

Reflexive ACLs

2012-07-16T23:48:00.002+05:30

• Adds simple state tracking to ACLs
– Outbound ACL triggers “mirror” entry in state table
– Inbound ACL checks state table first before denying
• Entries expire after 5 minutes of inactivity
– Modified via ip reflexive-list timeout
• No application level inspection
– Only works with “standard” TCP/UDP applications.

Reflexive ACL Configuration
• Reflect outbound traffic
• ip access-list extended OUTBOUND
• permit tcp any any reflect STATEFUL
• Check state table in opposite direction
• ip access-list extended INBOUND
• evaluate STATEFUL
• deny ip any any (implicit)

Dynamic ACLs

2012-07-16T23:46:00.001+05:30

• “Lock and key” ACLs
– Used to open a hole in the ACL based on authentication
• Potential Applications
– From inside to outside
• User must first authenticate to send traffic to the Internet
– From outside to inside
• User must first authenticate to access internal web server
• Replaced by Authentication Proxy
– Per-user ACLs downloaded from AAA server

Dynamic ACL Configuration
• ACL entry is defined as dynamic
– access-list 100 dynamic TEST permit ip
any any
• Entry is activated by access-enable command
– Can be per user or per line
• username… autocommand access-enable [host]
• line vty 0 4
– autocommand access-enable [host].

NTP Access group

2012-03-27T14:53:00.003+05:30

R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.

In scenario 1 we set up R4 to sync to R6. In this scenario we
will prevent R5 from syncing with R6 by using ntp access-group command.

I have never used this command before, so I hope I am understanding it correctly. If not, please let me know how else to test this command.

On R6 we have the following ACL:

access-list 1 permit 172.12.45.4
access-list 1 permit 127.127.7.1

172.12.45.4 is the address of R4. 127.127.7.1 is the IP address that a cisco router uses as it's reference when you make the router an NTP master. This must be added to the ACL or it will become unsynchronized with itself.

In global config mode we enter:

ntp access-group serve-only 1

Let's check the current times:

R5#show clock
16:15:04.031 UTC Sat May 31 2008

R6#show clock
16:31:45.687 UTC Sat May 31 2008

R5 is about 15 minutes behind. I don't know a way to debug on R6 to make sure it's working, so what I will do is wait about 10 minutes then add R5's IP address to ACL. I think 10 minutes is sufficient to prove that R6 is not allowing R5 to sync to it.

...
...

Well it's almost 20 minutes now. Let's check if R4 is synchronized:

R4#show ntp status | inc Cloc
Clock is synchronized, stratum 3, reference is 172.12.45.6

How about R5:

R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock

Some quick show clocks:

R4#show clock
16:49:06.505 UTC Sat May 31 2008

R5#show clock
16:32:29.755 UTC Sat May 31 2008

R6#show clock
16:49:12.335 UTC Sat May 31 2008

R5 is still unsynchronized and more than 15 minutes behind R6. Let's add R5's address to ACL 1 on R6 and see how long it takes to sync...

R6(config)#access-list 1 permit 172.12.45.5

We'll debug on R5:

R5#debug ntp sync
NTP clock synchronization debugging is on
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
R5#
May 31 16:33:54.039: NTP: synced to new peer 172.12.45.6

Took less than a minute!

This is the second of many NTP scenarios to come. It really seems so simple, but I have always had problems understanding NTP server/peer relationships and authentication configurations. So these will be the topics of future NTP blogs. Hopefully I (and you!) will become NTP masters in time for CCIE :)

Basic NTP Configuration

I will call this NTP Scenario 1: Basic NTP with no authentication. There will be more blogs about NTP but this is just to get it started.

R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.

First set the clock on R6:

R6#clock set 15:47:30 31 May 2008
*May 31 15:47:30.003: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:
05:19 UTC Fri Mar 1 2002 to 15:47:30 UTC Sat May 31 2008, configured from consol
e by console.

Verify the time with show clock:

R6#show clock
15:47:36.651 UTC Sat May 31 2008

Configure R6 as the master along with stratum:

R6#conf t
R6(config)#ntp master ?
<1-15> Stratum number

R6(config)#ntp master 3
R6(config)#^Z

Verify that R6 is synced with itself:

R6#show ntp associations

address ref clock st when poll reach delay offset disp
*~127.127.7.1 127.127.7.1 2 22 64 1 0.0 0.00 15875.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured

R6#show ntp status
Clock is synchronized, stratum 3, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is CBEBF22C.1583DCD8 (15:50:04.084 UTC Sat May 31 2008)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 15875.02 msec, peer dispersion is 15875.02 msec

Now it's time to configure the clients, let's first check the time on R4:

R4#show clock
*03:03:44.823 UTC Fri Mar 1 2002
R4#conf t
R4(config)#ntp server 172.12.45.6
R4(config)#^Z
R4#show clock
*03:04:52.047 UTC Fri Mar 1 2002
R4#

Notice the time is 6 years behind the current date, I have noticed that NTP will not sync when the times are so far apart (Not sure how this works, but let's manually 'push' R4 a little closer)

R4#clock set 15:30:40 31 May 2008

Now we're about 15 minutes behind. Let's do some debugging:

R4#debug ntp sync
NTP clock synchronization debugging is on

.May 31 15:31:43.107: NTP: synced to new peer 172.12.45.6

Noe that we're synced let's verify on R6 and R4:

R4#show clock
15:59:42.466 UTC Sat May 31 2008

R6#show clock
15:59:41.135 UTC Sat May 31 2008

Parser View

2012-03-27T14:51:00.001+05:30

FIRST, ENABLE AAA:

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#aaa new-model

SET ENABLE PASSWORD:

R4(config)#enable secret cisco
R4(config)#^Z

SWITCH TO VIEW MODE:

R4#en view
Password:
R4#
*Mar 2 23:03:20.352: %PARSER-6-VIEW_SWITCH: successfully set to view 'root'.
R4#

NOW WE CAN CREATE THE VIEW:

R4(config)#parser view operator
R4(config-view)#?
View commands:
commands Configure commands for a view
default Set a command to its defaults
exit Exit from view configuration mode
no Negate a command or set its defaults
secret Set a secret for the current view
R4(config-view)#commands exec include ping
% Password not set for the view operator
R4(config-view)#secret operator
R4(config-view)#commands exec include ping
R4(config-view)#commands exec include show hardware
R4(config-view)#commands exec include show interface
R4(config-view)#commands exec include show ver
R4(config-view)#exit

R4#en view operator
Password:*Mar 2 23:05:41.212: %PARSER-6-VIEW_SWITCH: successfully set to view 'operator'.R4#show ?
flash: display information about flash: file system
hardware Hardware specific information
interfaces Interface status and configuration
parser Display parser information
slot0: display information about slot0: file system
slot1: display information about slot1: file system
version System hardware and software status ALSO, YOU CAN ADD THE VIEW TO THE USER:

R4(config)#username operator view operator password operator

Configuring RIP

2012-03-17T18:40:00.000+05:30

RIP uses broadcast User Datagram Protocol (UDP) data packets to exchange routing information.
The Cisco IOS software sends routing information updates every 30 seconds; this process is termed
advertising. If a router does not receive an update from another router for 180 seconds or more, it
marks the routes served by the nonupdating router as being unusable. If there is still no update after
240 seconds, the router removes all routing table entries for the nonupdating router.
The metric that RIP uses to rate the value of different routes is hop count. The hop count is the
number of routers that can be traversed in a route. A directly connected network has a metric of zero;
an unreachable network has a metric of 16. This small range of metrics makes RIP an unsuitable
routing protocol for large networks.
If the router has a default network path, RIP advertises a route that links the router to the
pseudonetwork 0.0.0.0. The network 0.0.0.0 does not exist; RIP treats 0.0.0.0 as a network to
implement the default routing feature. The Cisco IOS software will advertise the default network if
a default was learned by RIP, or if the router has a gateway of last resort and RIP is configured with
a default metric.
RIP sends updates to the interfaces in the specified networks. If an interface’s network is not
specified, it will not be advertised in any RIP update.
Cisco’s implementation of RIP Version 2 supports plain text and MD5 authentication, route
summarization, classless interdomain routing (CIDR), and variable-length subnet masks (VLSMs).
For protocol-independent features, which also apply to RIP, see the chapter “Configuring IP Routing
Protocol-Independent Features” in this document.

RIP Configuration Task List
To configure RIP, complete the tasks in the following sections. You must enable RIP. The remaining
tasks are optional.
• Enable RIP
• Allow Unicast Updates for RIP
Enable RIP
P1C-90 Network Protocols Configuration Guide, Part 1
• Apply Offsets to Routing Metrics
• Adjust Timers
• Specify a RIP Version
• Enable RIP Authentication
• Disable Route Summarization
• Run IGRP and RIP Concurrently
• Disable the Validation of Source IP Addresses
• Enable or Disable Split Horizon
• Configure Interpacket Delay
• Filtering RIP information
• Key management (available in RIP Version 2)
• VLSM
Enable RIP
To enable RIP, use the following commands, starting in global configuration mode:
Allow Unicast Updates for RIP
Because RIP is normally a broadcast protocol, in order for RIP routing updates to reach
nonbroadcast networks, you must configure the Cisco IOS software to permit this exchange of
routing information. To do so, use the following command in router configuration mode:
To control the set of interfaces with which you want to exchange routing updates, you can disable
the sending of routing updates on specified interfaces by configuring the passive-interface
command. See the discussion on filtering in the “Filter Routing Information” section in the
“Configuring IP Routing Protocol-Independent Features” chapter.
Apply Offsets to Routing Metrics
An offset list is the mechanism for increasing incoming and outgoing metrics to routes learned via
RIP. This is done to provide a local mechanism for increasing the value of routing metrics.
Optionally, you can limit the offset list with either an access list or an interface. To increase the value
of routing metrics, use the following command in router configuration mode:

router rip
version 1 or 2 ( 1 is default)
network X.X.X.X ( X=IP address)
no auto-summary

Adjust Timers
Routing protocols use several timers that determine such variables as the frequency of routing
updates, the length of time before a route becomes invalid, and other parameters. You can adjust
these timers to tune routing protocol performance to better suit your internetwork needs. You can
make the following timer adjustments:
• The rate (time in seconds between updates) at which routing updates are sent
• The interval of time (in seconds) after which a route is declared invalid
• The interval (in seconds) during which routing information regarding better paths is suppressed
• The amount of time (in seconds) that must pass before a route is removed from the routing table
• The amount of time for which routing updates will be postponed
It also is possible to tune the IP routing support in the software to enable faster convergence of the
various IP routing algorithms, and, hence, quicker fallback to redundant routers. The total effect is
to minimize disruptions to end users of the network in situations where quick recovery is essential.
To adjust the timers, use the following command in router configuration mode:
Specify a RIP Version
Cisco’s implementation of RIP Version 2 supports authentication, key management, route
summarization, classless interdomain routing (CIDR), and variable-length subnet masks (VLSMs).
Key management and VLSM are described in the chapter “Configuring IP Routing
Protocol-Independent Features.”
By default, the software receives RIP Version 1 and Version 2 packets, but sends only Version 1
packets. You can configure the software to receive and send only Version 1 packets. Alternatively,
you can configure the software to receive and send only Version 2 packets. To do so, use the
following command in router configuration mode:
Command Purpose
offset-list [access-list-number | name] {in | out} offset
[type number]
Apply an offset to routing metrics.
Command Purpose
timers basic update invalid holddown flush [sleeptime] Adjust routing protocol timers.
Command Purpose
version {1 | 2} Configure the software to receive and send only
RIP Version 1 or only RIP Version 2 packets.
The preceding task controls the default behavior of RIP. You can override that behavior by
configuring a particular interface to behave differently. To control which RIP version an interface
sends, use one of the following commands in interface configuration mode:

Similarly, to control how packets received from an interface are processed, use one of the following
commands in interface configuration mode:

Enable or Disable Split Horizon
Normally, routers that are connected to broadcast-type IP networks and that use distance-vector
routing protocols employ the split horizon mechanism to reduce the possibility of routing loops.
Split horizon blocks information about routes from being advertised by a router out of any interface
from which that information originated. This behavior usually optimizes communications among
multiple routers, particularly when links are broken. However, with nonbroadcast networks (such as
Frame Relay and SMDS), situations can arise for which this behavior is less than ideal. For these
situations, you might want to disable split horizon. This applies to IGRP and RIP.
If an interface is configured with secondary IP addresses and split horizon is enabled, updates might
not be sourced by every secondary address. One routing update is sourced per network number
unless split horizon is disabled.
To enable or disable split horizon, use one of the following commands in interface configuration
mode:
Split horizon for Frame Relay and SMDS encapsulation is disabled by default. Split horizon is not
disabled by default for interfaces using any of the X.25 encapsulations. For all other encapsulations,
split horizon is enabled by default.
See the “Split Horizon Examples” section at the end of this chapter for examples of using split
horizon.
Note In general, changing the state of the default is not recommended unless you are certain that
your application requires making a change in order to advertise routes properly. Remember: If split
horizon is disabled on a serial interface (and that interface is attached to a packet-switched network),
you must disable split horizon for all routers in any relevant multicast groups on that network.
ip split-horizon :Enable split horizon.
no ip split-horizon :Disable split horizon.

Default 802.1X Configuration

2012-03-08T14:07:00.000+05:30

Enabling 802.1X Authentication
Step 1 configure terminal
Enter global configuration mode.
Step 2 aaa new-model Enable AAA.

Step 3 aaa authentication dot1x {default}
method1 [method2...]
Create an 802.1X authentication method list.
To create a default list that is used when a named list is not specified in
the authentication command, use the default keyword followed by the
methods that are to be used in default situations. The default method list
is automatically applied to all interfaces.
Enter at least one of these keywords:
• group radius—Use the list of all RADIUS servers for authentication.
• none—Use no authentication. The client is automatically
authenticated without the switch using the information supplied by
the client.

Step 4 interface interface-id
Enter interface configuration mode, and specify the interface to be
enabled for 802.1X authentication.

Step 5 dot1x port-control auto Enable 802.1X authentication on the interface.
For feature interaction information with trunk, dynamic, dynamic-access,
EtherChannel, secure, and SPAN ports see the “802.1X Configuration
Guidelines” section on page 8-7.

Step 6 end Return to privileged EXEC mode.

Step 7 show dot1x Verify your entries.
Check the Status column in the 802.1X Port Summary section of the
display. An enabled status means the port-control value is set either to
auto or to force-unauthorized.

Step 8 copy running-config startup-config (Optional) Save your entries in the configuration file.
eg:
Switch# configure terminal
Switch(config)# aaa new-model
Switch(config)# aaa authentication dot1x default group radius
Switch(config)# interface fastethernet0/1
Switch(config-if)# dot1x port-control auto
Switch(config-if)# end

Configuring the Switch-to-RADIUS-Server Communication

Step 1 configure terminal Enter global configuration mode.
Step 2 radius-server host {hostname |
ip-address} auth-port port-number key
string
Configure the RADIUS server parameters on the switch.
For hostname | ip-address, specify the host name or IP address of the
remote RADIUS server.
For auth-port port-number, specify the UDP destination port for
authentication requests. The default is 1812.
For key string, specify the authentication and encryption key used
between the switch and the RADIUS daemon running on the RADIUS
server. The key is a text string that must match the encryption key used on
the RADIUS server.
Note Always configure the key as the last item in the radius-server
host command syntax because leading spaces are ignored, but
spaces within and at the end of the key are used. If you use spaces
in the key, do not enclose the key in quotation marks unless the
quotation marks are part of the key. This key must match the
encryption used on the RADIUS daemon.
If you want to use multiple RADIUS servers, re-enter this command.
Step 3 end Return to privileged EXEC mode.
Step 4 show running-config Verify your entries.
Step 5 copy running-config startup-config (Optional) Save your entries in the configuration file.

To delete the specified RADIUS server, use the no radius-server host {hostname | ip-address} global
configuration command.
This example shows how to specify the server with IP address 172.20.39.46 as the RADIUS server, to
use port 1612 as the authorization port, and to set the encryption key to rad123, matching the key on the
RADIUS server:
Switch(config)# radius-server host 172.l20.39.46 auth-port 1612 key rad123
You can globally configure the timeout, retransmission, and encryption key values for all RADIUS
servers by using the radius-server host global configuration command. If you want to configure these
options on a per-server basis, use the radius-server timeout, radius-server retransmit, and the
radius-server key global configuration commands.

Enabling Periodic Re-Authentication
Step 1 configure terminal Enter global configuration mode.
Step 2 dot1x re-authentication Enable periodic re-authentication of the client, which is disabled by
default.
Step 3 dot1x timeout re-authperiod seconds Set the number of seconds between re-authentication attempts.
The range is 1 to 4294967295; the default is 3600 seconds.
This command affects the behavior of the switch only if periodic
re-authentication is enabled.
Step 4 end Return to privileged EXEC mode.
Step 5 show dot1x Verify your entries.
Step 6 copy running-config startup-config (Optional) Save your entries in the configuration file.

Switch(config)# dot1x re-authentication
Switch(config)# dot1x timeout re-authperiod 4000

Manually Re-Authenticating a Client Connected to a Port
You can manually re-authenticate the client connected to a specific port at any time by entering the
dot1x re-authenticate interface interface-id privileged EXEC command. If you want to enable or
disable periodic re-authentication
Switch# dot1x re-authenticate interface fastethernet0/1
Starting reauthentication on FastEthernet0/1

Dynamic Multipoint VPN (DMVPN)

2012-03-08T13:53:00.001+05:30

Configuring an IPsec Profile.
The IPsec profile shares most of the same commands with the crypto map configuration, but only a
subset of the commands are valid in an IPsec profile. Only commands that pertain to an IPsec policy can
be issued under an IPsec profile; you cannot specify the IPsec peer address or the access control list
(ACL) to match the packets that are to be encrypted.
Prerequisites
Before configuring an IPsec profile, you must define a transform set by using the crypto ipsec
transform-set command.
SUMMARY STEPS
1. enable
2. configure terminal
3. crypto ipsec profile name
4. set transform-set transform-set-name
5. set identity
6. set security association lifetime {seconds seconds | kilobytes kilobytes}
7. set pfs [group1 | group2]

Step 1 enable
Example:
Router> enable (enableEnables higher privilege levels, such as privileged EXEC
mode.Enter your password if prompted.)

Step 2 configure terminal
Example:
Router# configure terminal (Enters global configuration mode).

Step 3 crypto ipsec profile name
Example:
Router(config)# crypto ipsec profile vpnprof (Defines the IPsec parameters that are to be used for IPsec
encryption between “spoke and hub” and “spoke and spoke”
routers.
This command enters crypto map configuration mode.
• The name argument specifies the name of the IPsec
profile).

Step 4 set transform-set transform-set-name
Example:
Router(config-crypto-map)# set transform-set
trans2
Specifies which transform sets can be used with the IPsec
profile.
• The transform-set-name argument specifies the name
of the transform set.

Step 5 set identity
Example:
Router(config-crypto-map)# set identity
(Optional) Specifies identity restrictions to be used with the
IPsec profile.

Step 6 set security association lifetime {seconds
seconds | kilobytes kilobytes}
Example:
Router(config-crypto-map)# set security
association lifetime seconds 1800
(Optional) Overrides the global lifetime value for the IPsec
profile.
• The seconds seconds option specifies the number of
seconds a security association will live before expiring;
the kilobytes kilobytes option specifies the volume of
traffic (in kilobytes) that can pass between IPsec peers
using a given security association before that security
association expires.
• The default for the seconds argument is 3600 seconds.

Step 7 set pfs [group1 | group2]
Example:
Router(config-crypto-map)# set pfs group2
(Optional) Specifies that IPsec should ask for perfect
forward secrecy (PFS) when requesting new security
associations for this IPsec profile. If this command is not
specified, the default (group1) will be enabled.
• The group1 keyword specifies that IPsec should use the
768-bit Diffie-Hellman (DH) prime modulus group
when performing the new DH exchange; the group2
keyword specifies the 1024-bit DH prime modulus
group.

Configuring the Hub for DMVPN
To configure the hub router for mGRE and IPsec integration (that is, associate the tunnel with the IPsec

profile configured in the previous procedure), use the following commands:
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip address ip-address mask [secondary]
5. ip mtu bytes
6. ip nhrp authentication string
7. ip nhrp map multicast dynamic
8. ip nhrp network-id number
9. tunnel source {ip-address | type number}
10. tunnel key key-number
11. tunnel mode gre multipoint
12. tunnel protection ipsec profile name
13. bandwidth kbps
14. ip tcp adjust-mss max-segment-size
15. ip nhrp holdtime seconds
16. delay number

Step 1 enable
Example:
Router> enable
Enables higher privilege levels, such as privileged EXEC
mode.
Enter your password if prompted.

Step 2 configure terminal
Example:
Router# configure terminal
Enters global configuration mode.
Dynamic Multipoint VPN (DMVPN)
How to Configure Dynamic Multipoint VPN (DMVPN)
14
Cisco IOS Security Configuration Guide

Step 3 interface tunnel number
Example:
Router(config)# interface tunnel 5
Configures a tunnel interface and enters interface
configuration mode
• The number argument specifies the number of the
tunnel interface that you want to create or configure.
There is no limit on the number of tunnel interfaces you
can create.

Step 4 ip address ip-address mask [secondary]
Example:
Router(config-if)# ip address 10.0.0.1
255.255.255.0
Sets a primary or secondary IP address for the tunnel
interface.
Note All hubs and spokes that are in the same DMVPN
network must be addressed in the same IP subnet.

Step 5 ip mtu bytes
Example:
Router(config-if)# ip mtu 1400
Sets the maximum transmission unit (MTU) size, in bytes,
of IP packets sent on an interface.

Step 6 ip nhrp authentication string
Example:
Router(config-if)# ip nhrp authentication
donttell
Configures the authentication string for an interface using
NHRP.
Note The NHRP authentication string must be set to the
same value on all hubs and spokes that are in the
same DMVPN network.

Step 7 ip nhrp map multicast dynamic
Example:
Router(config-if)# ip nhrp map multicast dynamic
Allows NHRP to automatically add spoke routers to the
multicast NHRP mappings.

Step 8 ip nhrp network-id number
Example:
Router(config-if)# ip nhrp network-id 99
Enables NHRP on an interface.
• The number argument specifies a globally unique
32-bit network identifier from a nonbroadcast
multiaccess (NBMA) network. The range is from 1 to
4294967295.

Step 9 tunnel source {ip-address | type number}
Example:
Router (config-if)# tunnel source Ethernet0
Sets source address for a tunnel interface.

Step 10 tunnel key key-number
Example:
Router (config-if)# tunnel key 100000
(Optional) Enables an ID key for a tunnel interface.
• The key-number argument specifies a number from 0 to
4,294,967,295 that identifies the tunnel key.
Note The key number must be set to the same value on all
hubs and spokes that are in the same DMVPN
network.
Note This command should not be configured if you are
using a Cisco 6500 or Cisco 7600 platform.
Command or Action Purpose
Dynamic Multipoint VPN (DMVPN)
How to Configure Dynamic Multipoint VPN (DMVPN)
15
Cisco IOS Security Configuration Guide

Step 11 tunnel mode gre multipoint
Example:
Router(config-if)# tunnel mode gre multipoint
Sets the encapsulation mode to mGRE for the tunnel
interface.

Step 12 tunnel protection ipsec profile name
Example:
Router(config-if)# tunnel protection ipsec
profile vpnprof
Associates a tunnel interface with an IPsec profile.
• The name argument specifies the name of the IPsec
profile; this value must match the name specified in the
crypto ipsec profile name command.

Step 13 bandwidth kbps
Example:
Router(config-if)# bandwidth 1000
Sets the current bandwidth value for an interface to
higher-level protocols.
• The kbps argument specifies the bandwidth in kilobits
per second. The default value is 9. The recommend
bandwidth value is 1000 or greater.
Setting the bandwidth value to at least 1000 is critical if
EIGRP is used over the tunnel interface. Higher bandwidth
values may be necessary depending on the number of
spokes supported by a hub.

Step 14 ip tcp adjust-mss max-segment-size
Example:
Router(config-if)# ip tcp adjust-mss 1360
Adjusts the maximum segment size (MSS) value of TCP
packets going through a router.
• The max-segment-size argument specifies the
maximum segment size, in bytes. The range is from 500
to 1460.
The recommended value is 1360 when the number of IP
MTU bytes is set to 1400. With these recommended
settings, TCP sessions quickly scale back to 1400-byte IP
packets so the packets will “fit” in the tunnel.

Step 15 ip nhrp holdtime seconds
Example:
Router(config-if)# ip nhrp holdtime 450
Changes the number of seconds that NHRP NBMA
addresses are advertised as valid in authoritative NHRP
responses.
• The seconds argument specifies the time in seconds that
NBMA addresses are advertised as valid in positive
authoritative NHRP responses. The recommended
value ranges from 300 seconds to 600 seconds.

Step 16 delay number
Example:
Router(config-if)# delay 1000
(Optional) Used to change the EIGRP routing metric for
routes learned over the tunnel interface.
• The number argument specifies the delay time in

Configuring the Spoke for DMVPN
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip address ip-address mask [secondary]
5. ip mtu bytes
6. ip nhrp authentication string
7. ip nhrp map hub-tunnel-ip-address hub-physical-ip-address
8. ip nhrp map multicast hub-physical-ip-address
9. ip nhrp nhs hub-tunnel-ip-address
10. ip nhrp network-id number
11. tunnel source {ip-address | type number}
12. tunnel key key-number
13. tunnel mode gre multipoint
or
tunnel destination hub-physical-ip-address
14. tunnel protection ipsec profile name
15. bandwidth kbps
16. ip tcp adjust-mss max-segment-size
17. ip nhrp holdtime seconds
18. delay number

Step 1 enable
Example:
Router> enable
Enables higher privilege levels, such as privileged EXEC
mode.
Enter your password if prompted.

Step 2 configure terminal
Example:
Router# configure terminal
Enters global configuration mode.
Dynamic Multipoint VPN (DMVPN)
How to Configure Dynamic Multipoint VPN (DMVPN)
17
Cisco IOS Security Configuration Guide

Step 3 interface tunnel number
Example:
Router(config)# interface tunnel 5
Configures a tunnel interface and enters interface
configuration mode.
• The number argument specifies the number of the
tunnel interface that you want to create or configure.
There is no limit on the number of tunnel interfaces you
can create.

Step 4 ip address ip-address mask [secondary]
Example:
Router(config-if)# ip address 10.0.0.2
255.255.255.0
Sets a primary or secondary IP address for the tunnel
interface.
Note All hubs and spokes that are in the same DMVPN
network must be addressed in the same IP subnet.

Step 5 ip mtu bytes
Example:
Router(config-if)# ip mtu 1400
Sets the MTU size, in bytes, of IP packets sent on an
interface.

Step 6 ip nhrp authentication string
Example:
Router(config-if)# ip nhrp authentication
donttell
Configures the authentication string for an interface using
NHRP.
Note The NHRP authentication string be set to the same
value on all hubs and spokes that are in the same
DMVPN network.

Step 7 ip nhrp map hub-tunnel-ip-address
hub-physical-ip-address
Example:
Router(config-if)# ip nhrp map 10.0.0.1
172.17.0.1
Statically configures the IP-to-NBMA address mapping of
IP destinations connected to an MBMA network.
• hub-tunnel-ip-address—Defines the NHRP server at
the hub, which is permanently mapped to the static
public IP address of the hub.
• hub-physical-ip-address—Defines the static public IP
address of the hub.

Step 8 ip nhrp map multicast hub-physical-ip-address
Example:
Router(config-if)# ip nhrp map multicast
172.17.0.1
Enables the use of a dynamic routing protocol between the
spoke and hub, and sends multicast packets to the hub
router.

Step 9 ip nhrp nhs hub-tunnel-ip-address
Example:
Router(config-if)# ip nhrp nhs 10.0.0.1
Configures the hub router as the NHRP next-hop server.

Step 10 ip nhrp network-id number
Example:
Router(config-if)# ip nhrp network-id 99
Enables NHRP on an interface.
• The number argument specifies a globally unique
32-bit network identifier from a NBMA network. The
range is from 1 to 4294967295.

Step 11 tunnel source {ip-address | type number}
Example:
Router (config-if)# tunnel source Ethernet0
Sets the source address for a tunnel interface.
Command or Action Purpose
Dynamic Multipoint VPN (DMVPN)
How to Configure Dynamic Multipoint VPN (DMVPN)
18
Cisco IOS Security Configuration Guide

Step 12 tunnel key key-number
Example:
Router (config-if)# tunnel key 100000
(Optional) Enables an ID key for a tunnel interface.
• The key-number argument specifies a number from 0 to
4,294,967,295 that identifies the tunnel key.
• The key number must be set to the same value on all
hubs and spokes that are in the same DMVPN network.
Note This command should not be configured if you are
using a Cisco 6500 or Cisco 7600 platform.

Step 13 tunnel mode gre multipoint
or
tunnel destination hub-physical-ip-address
Example:
Router(config-if)# tunnel mode gre multipoint
or
Router(config-if)# tunnel destination
172.17.0.1
Sets the encapsulation mode to mGRE for the tunnel
interface.
Use this command if data traffic can use dynamic
spoke-to-spoke traffic.
Specifies the destination for a tunnel interface.
Use this command if data traffic can use hub-and-spoke
tunnels.

Step 14 tunnel protection ipsec profile name
Example:
Router(config-if)# tunnel protection ipsec
profile vpnprof
Associates a tunnel interface with an IPsec profile.
• The name argument specifies the name of the IPsec
profile; this value must match the name specified in the
crypto ipsec profile name command.

Step 15 bandwidth kbps
Example:
Router(config-if)# bandwidth 1000
Sets the current bandwidth value for an interface to
higher-level protocols.
• The kbps argument specifies the bandwidth in kilobits
per second. The default value is 9. The recommend
bandwidth value is 1000 or greater.
The bandwidth setting for the spoke does not need to equal
the bandwidth setting for the DMVPN hub. It is usually
easier if all of the spokes use the same or similar value.

Step 16 ip tcp adjust-mss max-segment-size
Example:
Router(config-if)# ip tcp adjust-mss 1360
Adjusts the maximum segment size (MSS) value of TCP
packets going through a router.
• The max-segment-size argument specifies the
maximum segment size, in bytes. The range is from 500
to 1460.
The recommended number value is 1360 when the number
of IP MTU bytes is set to 1400. With these recommended
settings, TCP sessions quickly scale back to 1400-byte IP
packets so the packets will “fit” in the tunnel.
Command or Action Purpose.

Configuring Dynamic Access Lists (Lock-and-Key Security)

2012-03-04T12:56:00.003+05:30

A host (R1′s vlan network) to access a web server ( R2′s vlan network) on a remote box. Again this is basic as it is going to get.
First configure the access-list on R2 for the Dynamic ACL

access-list 101 permit tcp any any eq 23 (we need to allow telnet through so we can authenticate. Now we can get away without this line here since we have permit ip any any at the bottom of the ACL. This will all depend on how you have to build out the ACL if you need this or not.)
access-list 101 dynamic HTTP permit tcp any any eq 80 (we could specify a specific host that is allowed access here or a subnet but we want to allow anyone that can authenticate for this example.)
access-list 101 deny tcp any any eq 80 (Here we are blocking access to anyone that doesn’t authenticate for web traffic.)
access-list 101 permit ip any any (Here we are allowing the rest of the incoming traffic in.)

We need to configure login access now. Usually I would authenticate everyone against my active directory, but we will just use local login for this.

username r1 password cisco

Need to apply the access-list on the incoming interface.

int s0/0
ip access-group 101 in

Now we just need to configure the telnet lines

line vty 0 4
login local
autocommand access-enable

Just need to telnet to r2 and authenticate and then we will have access to the web server on the remote end.
This is what our access-list should look like once we have authenticated:
10 permit tcp any any eq telnet (183 matches)
20 Dynamic HTTP permit tcp any any eq www
permit tcp any any eq www (72 matches)
30 deny tcp any any eq www (9 matches)
40 permit ip any any
Notice the line statement under line 20. This is showing that the dynamic acl is active.
If you want to clear the access-list you need to use this command:
clear access-template [access-list-number | name] [dynamic-name] [source] [destination]