• Tunnel network: 172.16.1.0 / 24
• NBMA network: 8.7.6.0 / 24
• No spoke-to-spoke tunnels in DMVPN Phase 1

Hub

crypto isakmp key 0 cisco address 8.7.6.0 255.255.255.0
!
crypto isakmp policy 100
  encryption aes 256
  hash sha
  authentication pre-share
!
crypto ipsec transform-set AES256_SHA esp-aes 256 esp-sha-hmac
  mode transport
!
crypto ipsec profile DMVPN
  set transform-set AES256_SHA
!
interface serial0/0
  ip address 8.7.6.100 255.255.255.0
!
interface Tunnel100
  ip address 172.16.1.100 255.255.255.0
  ip nhrp map multicast dynamic
  ip nhrp network-id 1
  tunnel source Serial0/0
  tunnel mode gre multipoint
  tunnel key 1
  tunnel protection ipsec profile DMVPN
  no ip split-horizon eigrp 100
  no ip next-hop-self eigrp 100
!
router eigrp 100
  network 172.16.1.100 0.0.0.0
  no auto-summary
!

Spoke

crypto isakmp key 0 cisco address 8.7.6.1
!
crypto isakmp policy 100
  encryption aes 256
  hash sha
  authentication pre-share
!
crypto ipsec transform-set AES256_SHA esp-aes 256 esp-sha-hmac
  mode transport
!
crypto ipsec profile DMVPN
  set transform-set AES256_SHA
!
interface Serial0/0
  ip address 8.7.6.50 255.255.255.0
!
interface Tunnel100
  ip address 172.16.1.50 255.255.255.0
  ip nhrp map multicast 8.7.6.100
  ip nhrp map 172.16.1.100 8.7.6.100
  ip nhrp server 172.16.1.100
  ip nhrp network-id 1
  tunnel source Serial0/0
  tunnel destination 8.7.6.100
  tunnel key 1
  tunnel protection ipsec profile DMVPN
!
router eigrp 100
  network 172.16.1.50 0.0.0.0
  no auto-summary
!

aaa new-model
aaa authentication login EZ_AUTHEN local
aaa authorization network EZ_AUTHOR local
!
username cisco password cisco1234
!
clock timezone GMT 0
ntp server 1.2.3.4
!
crypto pki trustpoint CA
  enrollment url http://1.2.3.4
  subject-name ROUTER.example.com
  revocation-check none
!
crypto pki authenticate CA
crypto pki enroll CA
!
crypto isakmp policy 1
  encryption 3DES
  hash SHA
  authentication rsa-sig
  group 2
!
crypto isakmp identity dn
!
ip local pool EZ_POOL 2.0.0.1 2.0.0.254
!
ip access-list extended EZ_ROUTES
  permit 3.0.0.0 0.0.0.255
!
crypto isakmp client configuration group EZVPN
  pool EZ_POOL
  acl EZ_ROUTES
!
crypto isakmp profile EZ_PROFILE
  match identity group EZVPN
  client authentication list EZ_AUTHEN
  isakmp authorization list EZ_AUTHOR
  client configuration address respond
  virtual-template 1
!
crypto ipsec transform-set 3DES_SHA esp-3des esp-sha-hmac
!
crypto ipsec profile EZ_IPSEC_PROFILE
  set transform-set 3DES_SHA
  set isakmp-profile EZ_PROFILE
!
interface Virtual-Template 1 type tunnel
  ip unnumbered FastEthernet0/1
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile EZ_IPSEC_PROFILE
!

Otherwise you’ll spend an hour beating your head against the wall trying to figure out why ssh slavehost date works, but send2slaves -t slavehost doesn’t.

The Management Plane Protection (MPP) feature in Cisco IOS software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces. Device management traffic is permitted to enter a device only through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces will accept network management traffic destined to the device.

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htsecmpp.html

This feature was added in 12.4(6)T but only seems to be documented under Feature Guides, not in the main IOS command reference or configuration guides.  Gee, thanks Cisco!

A configuration example (based on the practice lab task above):

control-plane host
  management-interface GigabitEthernet0/1 allow ssh snmp
end

When this configuration is applied to the router (assuming SSH has been previously configured), remote SSH and SNMP connections to the router will only be accepted when entering through Gi0/1.  This is based on the interface, not on the IP address.  SSH and SNMP connections to Gi0/1′s IP address entering through other interfaces will fail.  In addition, other management traffic (telnet, etc.) entering through Gi0/1 will also fail.  The complete list of what IOS considers management traffic is:

• SSH v1 and v2
• telnet
• HTTP / HTTPS
• FTP
• SNMP (all version)
• TFTP
• BEEP (Blocks Extensible Exchange Protocol)

Note that other traffic destined for the router (such as routing protocols and ARP) are not affected, nor is traffic routed through the management interface.  This is different from the management-interface functionality on an ASA, where the designated port can only be used for management traffic.

In summary, it is quite annoying that Cisco doesn’t seem to have actually documented this feature properly, since it has the potential to be a very useful tool in the network administrator’s toolbox.  Depending on the network design, enabling MPP makes it less likely that a management protocol becomes accessible on an interface connected to a hostile network, while simplifying interface ACLs needed to properly secure the device.

Assumptions

1. The ACE has been configured (possibly using the setup wizard) with interface and trunking options.
2. You are deploying the ACE in “routed mode”, e.g. the ACE is the default gateway for the backend servers and the VIPs live on a different network on the “outside” interface.
3. You have three web servers, WEB1, WEB2, and WEB3 all listening on port 80.

Configuration

Unlike a router, the ACE is a “deny by default” device.  You must explicitly permit any traffic entering the ACE from the network.  Thus, we need an access list (ACL) to allow traffic to our HTTP virtual IP (VIP).

access-list VLAN1 extended permit tcp any host 1.1.1.100 eq www

Next, we need to define our backend servers.  The “inservice” keyword is the ACE equivalent of the “no shutdown” command for an interface.  If you forget it, things won’t work.

rserver host WWW1
  ip address 2.2.2.101
  inservice

rserver host WWW2
  ip address 2.2.2.102
  inservice

rserver host WWW3
  ip address 2.2.2.103
  inservice

Now we need to define a health check, so that the ACE can determine if each backend server is functional and should receive traffic.  We’ll use a very basic HTTP service check at this point. We configure the probe to check each server every 10 seconds and accept the default behavior of marking a server as “failed” if it fails 3 checks. Also by default, the ACE will use an HTTP GET request for the root or “/” URL. That’s fine for this example. Finally, we tell the ACE that a server must respond for at least 60 seconds before it is marked as “back up” after a failure.

An important note: the HTTP probe must have an expected status code or range of codes defined. If you omit this statement, your backend servers will never come up!

probe http HTTP_PROBE
  interval 10
  passdetect interval 60
  expect status 200

Now that we have our backend servers defined, as well as a probe to check their status, we can join them together into a server farm. Again, don’t forget to “inservice” each rserver, or it won’t come up.

serverfarm host HTTP_FARM
  probe HTTP_PROBE
  rserver WWW1
    inservice
  rserver WWW2
    inservice
  rserver WWW3
    inservice

We need to tell the ACE about the virtual IP (VIP) on which we want it to listen. This is done with a class-map.

class-map match-all HTTP_VIP
  2 match virtual-address 1.1.1.100 tcp eq www

Next, we need to define our load-balancing policy, to tell the ACE what to do with traffic once it hits the VIP. In this case, we just direct it to the server farm defined above.

policy-map type loadbalance http first-match HTTP_POLICY
  class class-default
    serverfarm HTTP_FARM

The last piece we need is something to tie the policy to the VIP. We do this with a policy-map of type “multi-match”. For convenience, we configure the VIP to respond to ICMP echo request (pings) as long as at least one backend server is up.

policy-map multi-match VIPs
  class HTTP_VIP
    loadbalance vip inservice
    loadbalance policy HTTP_POLICY
    loadbalance vip icmp-reply active

Finally, we need to apply our policy to the “outside” interface of the ACE, bringing up our VIP. We also need to apply the ACL we created above to allow the HTTP requests inbound.

interface vlan 1
  description Public Network
  ip address 1.1.1.1 255.255.255.0
  access-group input VLAN1
  service-policy input VIPs
  no shutdown

That’s the end! You can grab the full configuration here.

In this example, we want to manipulate the routing as follows:

• Traffic between the 192.168.1.0/24 local network and 10.0.1.0/24 remote network should prefer PATH #1
• Traffic between the 192.168.2.0/24 local network and 10.0.2.0/24 remote network should prefer PATH #2

Note: for the purpose of this example we will assume that the specified local and remote networks only talk to each other. We don’t need to consider traffic between 192.168.1.0/24 and other remote networks, for example.

router bgp 65000
  network 192.168.1.0 mask 255.255.255.0
  network 192.168.2.0 mask 255.255.255.0
  !
  neighbor 1.1.1.1 remote-as 65534
  neighbor 1.1.1.1 send-community
  neighbor 1.1.1.1 route-map PATH1-LEARN in
  neighbor 1.1.1.1 route-map PATH1-ADVERTISE out
  !
  neighbor 2.2.2.2 remote-as 65534
  neighbor 2.2.2.2 send-community
  neighbor 2.2.2.2 route-map PATH2-LEARN in
  neighbor 2.2.2.2 route-map PATH2-ADVERTISE out
!

First we need to define our ACLs to specify which traffic prefers which path

ip access-list standard PREFER-PATH1-LOCAL
  permit 192.168.1.0 0.0.0.255
!
ip access-list standard PREFER-PATH1-REMOTE
  permit 10.0.1.0 0.0.0.255
!
ip access-list standard PREFER-PATH2-LOCAL
  permit 192.168.2.0 0.0.0.255
!
ip access-list standard PREFER-PATH2-REMOTE
  permit 10.0.2.0 0.0.0.255
!

As we learn routes, we raise the local preference on routes coming from the preferred path, so they are chosen over the same routes learned on the other path with a default of 100.

The permit 999 ensures all routes are still learned from both peers, even if they’re not being manipulated.

route-map PATH1-LEARN permit 10
  match ip address PREFER-PATH1-REMOTE
  set local-preference 110
!
route-map PATH1-LEARN permit 999
!
route-map PATH2-LEARN permit 10
  match ip address PREFER-PATH2-REMOTE
  set local-preference 110
!
route-map PATH2-LEARN permit 999
!

For incoming traffic, we need to influence the ISP’s routing decisions. There are several ways of doing this, including the MED. In our case, we’ll use the ISP’s pre-defined community values to force them to set a local preference on certain routes.

Again, the permit 999 rules ensure that we’re still sending all our routes to both peers, even if they don’t get tagged.

route-map PATH1-ADVERTISE permit 10
  match ip address PREFER-PATH1-LOCAL
  set community 65534:110
!
route-map PATH1-ADVERTISE permit 999
!
route-map PATH2-ADVERTISE permit 15
  match ip address PREFER-PATH2-LOCAL
  set community 65534:110
!
route-map PATH2-ADVERTISE permit 999
!

regex domlist1 "facebook.com"
regex domlist2 "myspace.com"
!
class-map type regex match-any DomainBlockList
  match regex domlist1
  match regex domlist2
!
class-map type inspect http match-all BlockDomainsClass
  match request header host regex class DomainBlockList
!
policy-map type inspect http http_inspection_policy
  class BlockDomainsClass
  reset log
!
policy-map global_policy
  class inspection_default
  inspect http http_inspection_policy
!
service-policy global_policy global
wr mem