6in4 is a tunneling protocol acting in the same way as GRE but it is only used to transport IPv6 packets over IPv4 network. 6in4 is the IPv4 protocol 41. 6in4 tunneling is also referred to as proto-41 static because it requires static configuration… But as we will see, with good API, it does not necessarily need manual reconfiguration even with dynamic IP on a DSL line.

First you need to register to one tunnel broker provider. For the exemple I’ve chosen Hurricane Electric’s tunnel broker but other providers work similarly.

The you have to configure your 6in4 tunnel. On BSD system (here Mac OS X) you can use the following script :

#!/bin/bash
LOCAL_IF=en1
LOCAL_IP=`ifconfig $LOCAL_IF | grep "inet " | awk -F" " '{ print $2 }'`
LOCAL_IPV6=2001:db8::2
REMOTE_IP=216.66.80.26
REMOTE_IPV6=2001:db8::1
TUNNEL_IF=gif0

ifconfig $TUNNEL_IF tunnel $LOCAL_IP $REMOTE_IP
ifconfig $TUNNEL_IF inet6 $LOCAL_IPV6 $REMOTE_IPV6 prefixlen 128
route -n add -inet6 default $REMOTE_IPV6

Then if you have a dynamic public IP you may want to use the following script as a cron job to check whether your IP has changed and eventually update the tunnel broker.

#!/bin/bash
OLD_IPv4=/tmp/ipv4
CURRENT_IPv4=`curl -s http://demo.exp-networks.be/tools/ip.php`
UPDATE="TRUE"
USERID="xxx"
PASSWORD="xxx"
TUN="123"

if [ -f $OLD_IPv4 ];
then
  if [ "$CURRENT_IPv4" = "`cat $OLD_IPv4`" ];
  then
    UPDATE="FALSE"
  fi
fi

if [ "$UPDATE" = "TRUE" ];
then
  echo $CURRENT_IPv4 > $OLD_IPv4
  curl --insecure -s \
  "https://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=AUTO&pass=$PASSWORD&user_id=$USER&tunnel_id=$TUN"
fi

Where USERID has to be replaced by the user id found on the main page of HE’s tunnel broker; PASSWORD is an md5 hash of your password; and TUN is the global tunnel id found on your tunnel details’ page.

When done, you are ready to enter in the IPv6 world. And maybe starts the HE IPv6 certification and get your badge…

1) install snmpd package

# aptitude install snmpd

2) edit /etc/default/snmpd to remove restriction or replace the default listening address (127.0.0.1 by default). the line to modify is

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'

or you can simply remove it with sed

# sed -i "s/.pid 127.0.0.1'/.pid'/" /etc/default/snmpd

3) add snmpd: 192.168.1.1 in /etc/hosts.allow to allow 192.168.1.1 to poll the server

# echo snmpd: 192.168.1.1 >> /etc/hosts.allow

4) edit /etc/snmp/snmpd.conf to define your community string(s), view(s) and allowed hosts (yes, again)

####
# First, map the community name (COMMUNITY) into a security name:
#        sec.name   source          community
com2sec  readonly   192.168.1.1/32  somecommunity

####
# Second, map the security names into group names:
#               sec.model  sec.name
group MyROGroup v2c        readonly

####
# Third, create a view for us to let the groups have rights to:
#          incl/excl   subtree   mask
view all   included    .1        80

####
# Finally, grant the groups access to the view with different
# read/write permissions:
#                context sec.model sec.level match  read   write  notif
access MyROGroup ""      any       noauth    exact  all    none   none

Once configured, start (or restart) the snmpd daemon.

# /etc/init.d/snmpd restart

And then test from the management station (here 192.168.1.1). We will try to get the hostname of the monitored device :

# snmpget -v 2c -c somecommunity 192.168.1.254 SNMPv2-MIB::sysName.0
SNMPv2-MIB::sysName.0 = STRING: gandalf

Here is what you need :

1. Native connectivity to IPv4 & IPv6 backbones

Connectivity to IPv4 should be OK. If you don’t have connectivity to IPv6 you may want to use 6in4 tunnel to connect to IPv6 backbone through a tunnel over IPv4 backbone. Several tunnel brokers are available for free, I personally know Hurricane Electric and SixXS.

2. An IPv4 gateway such as 192.168.1.1
3. An IPv4 address in that range such as 192.168.1.10
4. An IPv6 gateway such as 2001:db8:abcd::1
5. An IPv6 address in that range such as 2001:db8:abcd::e
6. Put all together in /etc/rc.conf

Extract from /etc/rc.conf

#IPv4 config
ifconfig_re0="inet 192.168.1.10 netmask 255.255.255.0"
static_routes="default"
route_default="default 192.168.1.1"

#IPv6 config
ipv6_enable="YES"
ipv6_ifconfig_re0="2001:db8:abcd::e/56"
ipv6_static_routes="default"
ipv6_route_default="default 2001:db8:abcd::1"

Then restart the server or the network related script from /etc/rc.d

ipv6#/etc/rc.d/netif start
re0: flags=8843 metric 0 mtu 1500
	options=9b
	ether 9e:65:96:1e:ca:5e
	inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet autoselect (100baseTX )
	status: active

ipv6#/etc/rc.d/routing start
add net default: gateway 192.168.1.1
Additional routing options:.

ipv6# /etc/rc.d/network_ipv6 start
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
net.inet6.ip6.forwarding: 0 -> 0
re0: flags=8843 metric 0 mtu 1500
	options=9b
	inet6 2001:db8:abcd::e prefixlen 56 tentative
plip0: flags=108810 metric 0 mtu 1500
lo0: flags=8049 metric 0 mtu 16384
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net default: gateway 2001:db8:abcd::1
IPv4 mapped IPv6 address support=NO

You may notice the IPv6 address is marked as tentative, that’s because DAD (Duplicate Address Detection) is still validating the IPv6 address. If you run ifconfig a bit later and if you IPv6 is not a duplicate address, the tentative flag should disappear.

Test connectivity with some awesome tools…

ipv6# ping -c3 www.google.com
PING www.l.google.com (209.85.229.147): 56 data bytes
64 bytes from 209.85.229.147: icmp_seq=0 ttl=55 time=10.624 ms
64 bytes from 209.85.229.147: icmp_seq=1 ttl=55 time=10.675 ms
64 bytes from 209.85.229.147: icmp_seq=2 ttl=55 time=10.815 ms

--- www.l.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.624/10.705/10.815/0.081 ms

ipv6# ping6 -c3 ipv6.google.com
PING6(56=40+8+8 bytes) 2001:db8:abcd::e --> 2a00:1450:8006::93
16 bytes from 2a00:1450:8006::93, icmp_seq=0 hlim=56 time=15.562 ms
16 bytes from 2a00:1450:8006::93, icmp_seq=1 hlim=56 time=15.529 ms
16 bytes from 2a00:1450:8006::93, icmp_seq=2 hlim=56 time=15.541 ms

--- ipv6.l.google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 15.529/15.544/15.562/0.014 ms

Congratulations, you now have IPv4 and IPv6 connectivity from your FreeBSD box!

In this scenario, the spoke routers will have two GRE tunnels, one ending on each hub routers.

First we configure the hub routers with mGRE interfaces and OSPF.

The tunnel interfaces use point-to-point OSPF network type by default, we will need to reconfigure them with  NBMA OSPF network type as we will have several spoke routers ending their tunnel on them. We will also set the OSPF costs in order to have R0 acting as the preferred hub router and R1 as the backup hub router.

Hub router R0′s config

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip ospf network non-broadcast
 ip ospf cost 10
 tunnel source FastEthernet2/1
 tunnel mode gre multipoint
 tunnel key 1
!
interface FastEthernet2/0
 ip address 10.10.10.1 255.255.255.0
!
interface FastEthernet2/1
 ip address 10.4.0.1 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.255 area 10
 network 10.10.10.0 0.0.0.255 area 10
!
ip route 0.0.0.0 0.0.0.0 10.4.0.2

Hub router R0′s config

interface Tunnel1
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip ospf network non-broadcast
 ip ospf cost 100
 tunnel source FastEthernet2/1
 tunnel mode gre multipoint
 tunnel key 1
!
interface FastEthernet2/0
 ip address 10.10.10.2 255.255.255.0
!
interface FastEthernet2/1
 ip address 10.4.1.1 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.255 area 10
 network 10.10.10.0 0.0.0.255 area 10
!
ip route 0.0.0.0 0.0.0.0 10.4.1.2

Then we can start to add spoke routers. The spoke routers will use point-to-point GRE (as we don’t want spoke-to-spoke direct communication) with NBMA OSPF network type in order to be compatible with the hub routers’ settings. We also need to define the neighbors as we’re on an NBMA network. I’ve chosen to do that on the spoke routers as ì don’t want to have to touch the hub routers config when new spoke routers are added.

Spoke router R2′s config

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp map 10.0.0.1 10.4.0.1
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1
 ip ospf network non-broadcast
 ip ospf cost 10
 ip ospf priority 0
 tunnel source FastEthernet1/0
 tunnel destination 10.4.0.1
 tunnel key 1
!
interface Tunnel1
 ip address 10.1.1.2 255.255.255.0
 ip nhrp map 10.1.1.1 10.4.1.1
 ip nhrp network-id 1
 ip nhrp nhs 10.1.1.1
 ip ospf network non-broadcast
 ip ospf cost 100
 ip ospf priority 0
 tunnel source FastEthernet1/0
 tunnel destination 10.4.1.1
 tunnel key 1
!
interface FastEthernet1/0
 ip address 10.4.2.1 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 10
 network 10.0.0.0 0.0.0.255 area 10
 network 10.1.1.0 0.0.0.255 area 10
 neighbor 10.0.0.1
 neighbor 10.1.1.1
!
ip route 0.0.0.0 0.0.0.0 10.4.2.2

Same config is applied on spoke router R3, only the IP change.

To check the GRE tunnels are operational, we only have to ping the tunnels’ internal IP from one router to the others three.

From spoke router R2 :

R2#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 = 8/8/8 ms
R2#ping 10.1.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/24 ms
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 100 percent (5/5), round-trip min/avg/max = 8/11/24 ms
R2#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/32 ms

If we check the NHRP entries on the hubs R0 or R1, we can see the two entries have been learned dynamically and the public IP used by the remote routers.

R1#sh ip nhrp
10.1.1.2/32 via 10.1.1.2, Tunnel1 created 02:08:37, expire 01:38:57
  Type: dynamic, Flags: authoritative unique registered used
  NBMA address: 10.4.2.1 
10.1.1.3/32 via 10.1.1.3, Tunnel1 created 02:08:36, expire 01:38:57
  Type: dynamic, Flags: authoritative unique registered used
  NBMA address: 10.4.3.1 

R0#sh ip nhrp
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 02:15:15, expire 01:53:44
  Type: dynamic, Flags: authoritative unique registered
  NBMA address: 10.4.2.1
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 02:11:04, expire 01:53:44
  Type: dynamic, Flags: authoritative unique registered
  NBMA address: 10.4.3.1 

Now, check OSPF is doing what we want. First we check the ospf neighbors on spoke router R2

R2#sh ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2        1   FULL/DR         00:01:54    10.1.1.1        Tunnel1
10.10.10.1        1   FULL/DR         00:01:55    10.0.0.1        Tunnel0

Then we can check corporate subnet 10.10.10.0/24 and other spokes (here R3′s Loopback 3.3.3.3) are reachable via the primary hub router R0.

R2#sh ip route ospf
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/11] via 10.0.0.3, 00:42:46, Tunnel0
     10.0.0.0/24 is subnetted, 4 subnets
O       10.10.10.0 [110/11] via 10.0.0.1, 00:42:46, Tunnel0

On the hub routers we can check the spoke routers are always reached via R0.

R0#sh ip route ospf
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/11] via 10.0.0.2, 00:49:41, Tunnel0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/11] via 10.0.0.3, 00:49:41, Tunnel0
     10.0.0.0/24 is subnetted, 4 subnets
O       10.1.1.0 [110/101] via 10.10.10.2, 00:49:41, FastEthernet2/0

R1#sh ip route ospf
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/12] via 10.10.10.1, 00:50:52, FastEthernet2/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/12] via 10.10.10.1, 00:50:52, FastEthernet2/0
     10.0.0.0/24 is subnetted, 4 subnets
O       10.0.0.0 [110/11] via 10.10.10.1, 00:50:52, FastEthernet2/0

Now that we have IP connectivity, we can enable IPSec exactly as we did last time.

crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set mySet esp-aes esp-sha-hmac
!
crypto ipsec profile myDMVPN
set security-association lifetime seconds 120
set transform-set mySet
set pfs group2

interface Tunnel0
tunnel protection ipsec profile myDMVPN

interface Tunnel1
tunnel protection ipsec profile myDMVPN

That’s all folks! Now we have a DMVPN setup with redundant hub routers…

Now, in cluster mode, you can do the software upgrade with no or very limited impact if you follow the correct sequence of operations. Here are the steps I used last time and it went perfectly and transparent for the users.

Note this procedure has been tested on ACE modules for Catalyst 6500 only but it should remain valid for the ACE 4710 appliances.

Step 1

First you need to ensure all the contexts are properly synchronized and the standby contexts are in STANDBY_HOT state.

ACE_1/Admin# sh ft group brief
FT Group ID: 1  My State:FSM_FT_STATE_ACTIVE    Peer State:FSM_FT_STATE_STANDBY_HOT
                Context Name: Admin     Context Id: 0
FT Group ID: 2  My State:FSM_FT_STATE_ACTIVE    Peer State:FSM_FT_STATE_STANDBY_COLD
                Context Name: C1        Context Id: 4
FT Group ID: 3  My State:FSM_FT_STATE_ACTIVE    Peer State:FSM_FT_STATE_STANDBY_HOT
                Context Name: C2        Context Id: 3

Here as you can see context C1 is stuck in STANDBY_COLD state. Usually put that context out of service on the standby ACE and then put it back in service solve the issue. If it is not the case you won’t have a fully transparent software upgrade for that context; current session will be dropped but new session will be accepted after the failover. If it is acceptable for you, go on with the upgrade otherwise try to find out why it is not in STANDBY_HOT state.

Note it might take several minutes to leave the STANDBY_BULK state (it took 2 minutes during my tests).

ACE_2/Admin(config)# ft group 2
ACE_2/Admin(config-ft-group)# no inservice
ACE_2/Admin(config-ft-group)# do sh ft group 2 detail

FT Group                     : 2
No. of Contexts              : 1
Context Name                 : C1
Context Id                   : 4
Configured Status            : out-of-service
Maintenance mode             : MAINT_MODE_OFF
My State                     : FSM_FT_STATE_INIT
My Config Priority           : 90
My Net Priority              : 90
My Preempt                   : Enabled
Peer State                   : FSM_FT_STATE_UNKNOWN
Peer Config Priority         : Unknown
Peer Net Priority            : Unknown
Peer Preempt                 : Unknown
Peer Id                      : 1
Last State Change time       : Wed Feb  3 14:35:36 2010
Running cfg sync enabled     : Enabled
Running cfg sync status      :
Startup cfg sync enabled     : Enabled
Startup cfg sync status      :
Bulk sync done for ARP: 0
Bulk sync done for LB: 0
Bulk sync done for ICM: 0
ACE_2/Admin(config-ft-group)# inservice

NOTE: Configuration mode has been disabled on all sessions

ACE_2/Admin(config-ft-group)# do sh ft group 2 detail

FT Group                     : 2
No. of Contexts              : 1
Context Name                 : C1
Context Id                   : 4
Configured Status            : in-service
Maintenance mode             : MAINT_MODE_OFF
My State                     : FSM_FT_STATE_STANDBY_BULK
My Config Priority           : 90
My Net Priority              : 90
My Preempt                   : Enabled
Peer State                   : FSM_FT_STATE_ACTIVE
Peer Config Priority         : 120
Peer Net Priority            : 120
Peer Preempt                 : Enabled
Peer Id                      : 1
Last State Change time       : Wed Feb  3 14:36:02 2010
Running cfg sync enabled     : Enabled
Running cfg sync status      : Running configuration sync has completed
Startup cfg sync enabled     : Enabled
Startup cfg sync status      : Startup configuration sync has completed
Bulk sync done for ARP: 1
Bulk sync done for LB: 0
Bulk sync done for ICM: 0
ACE_2/Admin(config-ft-group)# do sh ft group 1 detail

FT Group                     : 2
No. of Contexts              : 1
Context Name                 : C1
Context Id                   : 4
Configured Status            : in-service
Maintenance mode             : MAINT_MODE_OFF
My State                     : FSM_FT_STATE_STANDBY_HOT
My Config Priority           : 90
My Net Priority              : 90
My Preempt                   : Enabled
Peer State                   : FSM_FT_STATE_ACTIVE
Peer Config Priority         : 120
Peer Net Priority            : 120
Peer Preempt                 : Enabled
Peer Id                      : 1
Last State Change time       : Wed Feb  3 14:37:51 2010
Running cfg sync enabled     : Enabled
Running cfg sync status      : Running configuration sync has completed
Startup cfg sync enabled     : Enabled
Startup cfg sync status      : Startup configuration sync has completed
Bulk sync done for ARP: 1
Bulk sync done for LB: 2
Bulk sync done for ICM: 2

Step 2

On the ACE, preemption is enabled by default for all the  contexts. It needs to be disabled to perform a manual failover.

ACE_1/Admin(config)# ft group 1
ACE_1/Admin(config-ft-group)# no preempt
ACE_1/Admin(config-ft-group)# ft group 2
ACE_1/Admin(config-ft-group)# no preempt
ACE_1/Admin(config-ft-group)# ft group 3
ACE_1/Admin(config-ft-group)# no preempt
ACE_1/Admin(config-ft-group)# end

Step 3

Download the new software image to the active and standby ACEs. Here I’ve chosen to use tftp because I hadn’t an ftp server configured in the lab… ftp can be used and is definitely faster.

ACE_1/Admin# copy tftp: image:
Enter source filename[]? c6ace-t1k9-mz.A2_2_3.bin
Enter the destination filename[]? [c6ace-t1k9-mz.A2_2_3.bin]
Address of remote host[]? 10.1.1.1
Trying to connect to tftp server......
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(…)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
TFTP get operation was successful
 31361516 bytes copied
ACE_1/Admin#
ACE_1/Admin# dir image:
 30788103  Apr 15 13:14:48 2009 c6ace-t1k9-mz.A2_1_4a.bin
 31361516  Feb  3 14:43:45 2010 c6ace-t1k9-mz.A2_2_3.bin
          Usage for image: filesystem
          461848576 bytes total used
          577126400 bytes free
         1038974976 total bytes

Check the file size is correct…

Step 4

Change the boot string on the active ACE, it will be synced to the standby ACE. By the way, configuration mode is disabled on the standby ACE therefore it is the only option…

ACE_1/Admin# sh run | i boot
Generating configuration....
boot system image:c6ace-t1k9-mz.A2_1_4a.bin
ACE_1/Admin# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ACE_1/Admin(config)# no boot system image:c6ace-t1k9-mz.A2_1_4a.bin
ACE_1/Admin(config)# boot system image:c6ace-t1k9-mz.A2_2_3.bin
ACE_1/Admin(config)# exit
ACE_1/Admin# wr mem all
Generating configuration....
running config of context Admin saved
Generating configuration....
running config of context C2 saved
Generating configuration....
running config of context C1 saved
Please wait ... sync to compact flash in progress.

This may take a few minutes to complete

Sync Done

Step 5 (optional)

Create checkpoint in all contexts on active and standby devices

ACE_2/Admin# checkpoint create 20100203
Generating configuration....
Created configuration checkpoint '20100203'
ACE_2/Admin# changeto C2

NOTE: Configuration mode has been disabled on all sessions

ACE_2/C2# checkpoint create 20100203
Generating configuration....
Created configuration checkpoint '20100203'
ACE_2/C2# changeto C1

NOTE: Configuration mode has been disabled on all sessions

ACE_2/C1# checkpoint create 20100203
Generating configuration....
Created configuration checkpoint '20100203'
ACE_2/C1# changeto Admin

Step 6

Reload the standby device

ACE_2/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes] no (already done in step 4)
Perform system reload. [yes/no]: [yes]

NOTE: Configuration mode is enabled on all sessions

Connection to ACE_2 closed by remote host.
Connection to ACE_2 closed.

Step 7

Check the standby device is running the new software version.

ACE_2/Admin# sh ver
Cisco Application Control Software (ACSW)
TAC support: http://C2 .cisco.com/tac
Copyright (c) 2002-2009, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://C2 .gnu.org/licenses/gpl.html.

Software
  loader:    Version 12.2[120]
  system:    Version A2(2.3) [build 3.0(0)A2(2.3)]
  system image file: [LCP] disk0:c6ace-t1k9-mz.A2_2_3.bin
  installed license: ACE-VIRT-020

Hardware
  Cisco ACE (slot: 6)
  cpu info:
    number of cpu(s): 2
    cpu type: SiByte
    cpu: 0, model: SiByte SB1 V0.2, speed: 700 MHz
    cpu: 1, model: SiByte SB1 V0.2, speed: 700 MHz
  memory info:
    total: 827128 kB, free: 256000 kB
    shared: 0 kB, buffers: 1824 kB, cached 0 kB
  cf info:
    filesystem: /dev/cf
    total: 1014624 kB, used: 451040 kB, available: 563584 kB

last boot reason:  reload command by Admin
configuration register:  0x1
ACE_2 kernel uptime is 0 days 0 hour 8 minute(s) 45 second(s)

Step 8

Wait until all the contexts on the standby devices stabilize in STANDBY_WARM or STANDBY_HOT state.

ACE_2/Admin# sh ft group brief

FT Group ID: 1  My State:FSM_FT_STATE_STANDBY_WARM      Peer State:FSM_FT_STATE_ACTIVE
                Context Name: Admin     Context Id: 0
FT Group ID: 2  My State:FSM_FT_STATE_STANDBY_WARM      Peer State:FSM_FT_STATE_ACTIVE
                Context Name: C1        Context Id: 4
FT Group ID: 3  My State:FSM_FT_STATE_STANDBY_WARM      Peer State:FSM_FT_STATE_ACTIVE
                Context Name: C2        Context Id: 3

For your information, here is what Cisco says about STANDBY_WARM state :

In the STANDBY_WARM state, as with the STANDBY_HOT state, configuration mode is disabled on the standby ACE and configuration and state synchronization continues. A failover from the active to the standby based on priorities and preempt can still occur while the standby is in the STANDBY_WARM state. However, while stateful failover is possible for a WARM standby, it is not guaranteed. In general, modules should be allowed to remain in this state only for a short period of time.

Step 9

Perform a failover from the active ACE to the standby ACE for all the contexts.

ACE_1/Admin# ft switchover all
This command will cause card to switchover (yes/no)?  [no] yes

NOTE: Configuration mode has been disabled on all sessions

Step 10

Check the newly upgraded ACE is well become active.

ACE_1/Admin# sh ft group brief

FT Group ID: 1  My State:FSM_FT_STATE_STANDBY_BULK      Peer State:FSM_FT_STATE_ACTIVE
                Context Name: Admin     Context Id: 0
FT Group ID: 2  My State:FSM_FT_STATE_STANDBY_BULK      Peer State:FSM_FT_STATE_ACTIVE
                Context Name: C1        Context Id: 4
FT Group ID: 3  My State:FSM_FT_STATE_STANDBY_BULK      Peer State:FSM_FT_STATE_ACTIVE
                Context Name: C2        Context Id: 3

Step 11

Reload the 2^nd ACE (previously active).

ACE_1/Admin# reload
This command will reboot the system
Save configurations for all the contexts. Save? [yes/no]: [yes] no
Perform system reload. [yes/no]: [yes]

NOTE: Configuration mode is enabled on all sessions

Connection to ACE_1 closed by remote host.
Connection to ACE_1 closed.

Step 12

When the 2^nd ACE state stabilize to FSM_FT_STATE_STANDBY_HOT state, perform again a failover for all the contexts.

ACE_2/Admin# sh ft group brief

FT Group ID: 1  My State:FSM_FT_STATE_ACTIVE    Peer State:FSM_FT_STATE_STANDBY_HOT
                Context Name: Admin     Context Id: 0
FT Group ID: 2  My State:FSM_FT_STATE_ACTIVE    Peer State:FSM_FT_STATE_STANDBY_HOT
                Context Name: C1        Context Id: 4
FT Group ID: 3  My State:FSM_FT_STATE_ACTIVE    Peer State:FSM_FT_STATE_STANDBY_HOT
                Context Name: C2        Context Id: 3

Step 13 (If you’re not superstitious)

Reconfigure preemption if it is in your standard… (personally I don’t like preemption because if a device has failed I prefer to check exactly why before activating it again)

ACE_1/Admin(config)# ft group 1
ACE_1/Admin(config-ft-group)# preempt
ACE_1/Admin(config-ft-group)# ft group 2
ACE_1/Admin(config-ft-group)# preempt
ACE_1/Admin(config-ft-group)# ft group 3
ACE_1/Admin(config-ft-group)# preempt
ACE_1/Admin(config-ft-group)# end
ACE_1/Admin# wr mem

And that’s it, you have upgraded your ACE cluster with no or limited impact. If you find this post helpful you may leave a comment to encourage me to publish more articles…

You need a server connected to Internet? You don’t want a shared server but you don’t want to pay for a dedicated server? exp-NETWORKS can rent you a Virtual Private Server (VPS). A VPS runs its own Linux OS with its own packages, users administration, configuration on a shared hardware. The VPS running on the same hardware are isolated from each other.

The VPS proposed by exp-NETWORKS comes with a minimal Debian 5 install and ssh access. Should you want another Linux distribution, please contact us.

VPS I	memory disk	512 Mo 10 Go
VPS II	memory disk	1024 Mo 20 Go
VPS III	memory disk	2048 Mo 30 Go

ClamXav

The default install of ClamXav does not enable the automatic virus definition update. When a user enables those automatic updates, a ‘good old cron job’ is created for that user. Three minor concerns with that method are:

1. Each users on the system can enable the automatic updates leading to multiple redundant checks for new virus definitions
2. The users do not have write access to ClamXav directories and are not able to create a temporary directory required for differential updates. Fortunately ClamXav fall back to a standard update where the entire virus definition file is downloaded.
3. All the users who enable the automatic updates will get e-mails containing an error message like this one :

   clamxav ERROR: chdir_tmp: Can't create directory ./clamav-97e66bd7fbb

Only the _clamav user has write access to his directories. I’ve found several workarounds for this by googling but most of them were either not secure like setting the _clamav user’s directories world wide writable, either not elegant like putting the cron job in the root’s crontab…

The only elegant workaround I’ve found so far is still requiring some manual configuration but at least it uses Apple’s vision of daemon and recurrent tasks; it uses launchd. I won’t explain launchd here but Apple website or AFP548 website are very good start to understand its philosophy.

We will configure a launchd daemon to start the virus definition update every day at 21:30 as _clamav user. Launchd is configured via property list files (.plist) placed in appropriate directories. In this case we want the daemon to be started as long as the system is started (i.e. regardless if a user is logged or not). We will place our plist file in /Library/LaunchDaemons/.

 1. <?xml version="1.0" encoding="UTF-8"?>
 2. <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 3. <plist version="1.0">
 4.   <dict>
 5.     <key>Label</key>
 6.     <string>com.clamxav.freshclam</string>
 7.     <key>UserName</key>
 8.     <string>_clamav</string>
 9.     <key>LowPriorityIO</key>
10.     <true/>
11.     <key>Nice</key>
12.     <integer>1</integer>
13.     <key>Program</key>
14.     <string>/usr/local/clamXav/bin/freshclam</string>
15.     <key>ProgramArguments</key>
16.     <array>
17.       <string>/usr/local/clamXav/bin/freshclam</string>
18.       <string>--quiet</string>
19.       <string>--log=/usr/local/clamXav/share/clamav/freshclam.log</string>
20.     </array>
21.     <key>StartCalendarInterval</key>
22.     <dict>
23.       <key>Hour</key>
24.       <integer>21</integer>
25.       <key>Minute</key>
26.       <integer>30</integer>
27.     </dict>
28.   </dict>
29. </plist>

Lines 5-6 : define the daemon’s name
Lines 7-8 : define the user the daemon will run as
Lines 9-12 : reduce the update process priority as it is not required to run fast
Lines 13-20 : define the daemon’s executable and its parameters
Lines 21- 27 : schedule when the daemon must run

That plist file must be placed in /Library/LaunchDaemons/. It will be automatically loaded after each reboot but you can manually load it with launchctl if you don’t want to restart your computer.

$ sudo launchctl load /Library/LaunchDaemons/com.clamxav.freshclam.plist
$ sudo launchctl list | grep com.clamxav.freshclam
-	0	com.clamxav.freshclam

Now you can check in the log file (/usr/local/clamXav/share/clamav/freshclam.log) the error message has disappeared and differential update is now working fine…

ClamAV update process started at Sat Nov 28 21:30:09 2009
main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
Downloading daily-10091.cdiff [100%]
daily.cld updated (version: 10091, sigs: 115838, f-level: 44, builder: ccordes)
Database updated (660873 signatures) from database.clamav.net (IP: 193.1.193.64)
Clamd successfully notified about the update.

Thanks for leaving a comment if you found this useful

You can have a look to the complete charter text in french.

First we will create IP connectivity via GRE tunnels and NHRP then we will secure the GRE tunnels with IPSec.

The hub router will use a multipoint GRE interface for ease of management. That way we do not need to provision a new tunnel interface per remote office. In fact, the central router will not need to be reconfigured at all for any additional remote site.

Hub router R1:

interface Tunnel0
ip address 10.10.10.1 255.255.255.0
ip nhrp network-id 1
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1

interface Fa0/0
ip address 1.1.1.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 1.1.1.1

Spoke routers (R2 and R3 in this example) will use point-to-point GRE tunnel pointing to central site’s hub router R1. NHRP will be configured to use R1 as next-hop server. With this setup, spoke-to-spoke traffic will flow through the hub making the hub a central point where you can enforce security…

Spoke router R2:

interface Tunnel0
ip address 10.10.10.2 255.255.255.0
ip nhrp map 10.10.10.1 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 10.10.10.1
tunnel source FastEthernet0/0
tunnel destination 1.1.1.2
tunnel key 1

interface Fa0/0
ip address 2.2.2.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 2.2.2.1

Spoke router R3

interface Tunnel0
ip address 10.10.10.3 255.255.255.0
ip nhrp map 10.10.10.1 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 10.10.10.1
tunnel source FastEthernet0/0
tunnel destination 1.1.1.2
tunnel key 1

interface Fa0/0
ip address 3.3.3.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0 3.3.3.1

At this stage, if the router can communicate with each others via their Fa0/0 interface then the GRE tunnels are usable. In this example, “Internet” router is directly connected to all the routers and the routers R1, R2 and R3 simply have a default route pointing to the “Internet” router.

To check the GRE tunnels are operational, we only have to ping the tunnels’ internal IP from one router to the others two.

R2#ping 10.10.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 272/313/420 ms
R2#ping 10.10.10.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 312/564/876 ms

If we check the NHRP entries on the hub R1, we can see the two entries have been learned dynamically and the public IP used by the remote routers.

R1#sh ip nhrp
10.10.10.2/32 via 10.10.10.2, Tunnel0 created 00:11:31, expire 01:48:28
Type: dynamic, Flags: authoritative unique registered used
NBMA address: 2.2.2.2
10.10.10.3/32 via 10.10.10.3, Tunnel0 created 00:08:19, expire 01:51:52
Type: dynamic, Flags: authoritative unique registered used
NBMA address: 3.3.3.2

Same info without the timers…

R1#sh ip nhrp brief
Target            Via         NBMA        Mode   Intfc   Claimed
10.10.10.2/32     10.10.10.2  2.2.2.2     dynamic  Tu0    <  >
10.10.10.3/32     10.10.10.3  3.3.3.2     dynamic  Tu0    <  >

Statistics about the NHRP protocol itself

R1#sh ip nhrp traffic
Tunnel0
Sent: Total 3
0 Resolution Request  0 Resolution Reply  0 Registration Request
3 Registration Reply  0 Purge Request  0 Purge Reply
0 Error Indication
Rcvd: Total 3
0 Resolution Request  0 Resolution Reply  3 Registration Request
0 Registration Reply  0 Purge Request  0 Purge Reply
0 Error Indication

R1#sh ip nhrp summary
IP NHRP cache 2 entries, 496 bytes
0 static  2 dynamic  0 incomplete

On the spoke routers we can check the same… Here we can see the NHRP entry is statically defined

R3#sh ip nhrp
10.10.10.1/32 via 10.10.10.1, Tunnel0 created 00:13:31, never expire
Type: static, Flags: authoritative
NBMA address: 1.1.1.2

R3#sh ip nhrp summary
IP NHRP cache 1 entry, 248 bytes
1 static  0 dynamic  0 incomplete

And we can check the NHRP’s next-hop server used.

R3#sh ip nhrp nhs
Legend:
E=Expecting replies
R=Responding

Tunnel0:
10.10.10.1       RE


Should you want to allow spoke-to-spoke tunnels to be built dynamically, you only need to replace the  tunnel destination 1.1.1.2 command on the spokes by tunnel mode gre multipoint making the spokes’ tunnel interface an mGRE interface. For the remaining of this article, we won’t use mGRE interfaces on the spokes.

Now that we have IP connectivity, we still have to secure those dynamically created GRE tunnels with IPSec. Here for simplicity we will use pre-shared key as authentication method which is not recommended for production deployment…

On the hub and spoke routers, just configure ISAKMP/IPSec parameters and enable IPSec on the tunnel insterfaces.

crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set mySet esp-aes esp-sha-hmac
!
crypto ipsec profile myDMVPN
set security-association lifetime seconds 120
set transform-set mySet
set pfs group2

interface Tunnel0
tunnel protection ipsec profile myDMVPN


Check IPSec SA are well negotiated

R1#sh crypto ipsec sa

interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 1.1.1.2

protected vrf: (none)
local  ident (addr/mask/prot/port): (1.1.1.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
current_peer 2.2.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 121, #pkts encrypt: 121, #pkts digest: 121
#pkts decaps: 121, #pkts decrypt: 121, #pkts verify: 121
#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

local crypto endpt.: 1.1.1.2, remote crypto endpt.: 2.2.2.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xA2BC2FED(2730242029)

inbound esp sas:
spi: 0x2884EDEA(679800298)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2005, flow_id: SW:5, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4463708/83)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xA2BC2FED(2730242029)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2004, flow_id: SW:4, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4463708/82)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

That’s it! The DMVPN setup is ready for wide deployment… Of course central hub router should be duplicated for redundancy, it will exposed in a future post.

Thanks for leaving a comment if you found this useful

If you don’t use IPv6 at all, disable it. On Debian, the interfaces configuration is located in /etc/network/interfaces. Remove all the inet6 configuration looking like this :

iface eth0 inet6 static
  address 2001:db8:4:fe34::3ea1
  netmask 64

If you plan to use IPv6, first you have to know ICMPv6 should be filtered carefully. In IPv6, ICMPv6 is widely used. It replaces IPv4′s ARP with neighbour-solicitation and neighbour-advertisement ICMPv6 messages. It is used for router discovery via router-solicitation and router-advertisement ICMPv6 messages. It replaces IPv4′s IGMP with group-membership-query, group-membership-report and group-membership-reduction ICMPv6 messages.

Here is a small script to activate IPv6 filtering with netfilter/ip6tables. The script has been test on Debian but it should work on other Linux flavor.

#!/bin/sh -e
#
# Simple example IPv6 Firewall configuration.
#
# Caveats:
# - This configuration applies to all network interfaces
# if you want to restrict this to only a given interface use
# '-i INTERFACE' in the ip6tables calls.
# - Remote access for TCP/UDP services is granted to any host,
# you probably will want to restrict this using '--source'.
#
# description: Activates/Deactivates the firewall at boot time
#
# You should test this script before applying with safe-restart option
#

IP6TABLES=/sbin/ip6tables
#IP6TABLES="/sbin/ip6tables -i eth0"

[ -x "$IP6TABLES" ] || exit 1

# Inbound TCP ports
TCP_INPUT_PORTS="21 22 53 443"

# Inbound UDP ports
UDP_INPUT_PORTS="53"

# Allowed ICMP messages
ALLOWED_ICMP="\
packet-too-big \
destination-unreachable \
time-exceeded parameter-problem \
echo-request \
echo-reply \
router-advertisement \
neighbour-solicitation \
neighbour-advertisement"

fw_start () {
# Allow related and established connection.
$IP6TABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow ICMP as defined in ALLOWED_ICMP
if [ -n "$ALLOWED_ICMP" ] ; then
 for ICMP_TYPE in $ALLOWED_ICMP; do
  $IP6TABLES -A INPUT -p icmpv6 --icmpv6-type ${ICMP_TYPE} -j ACCEPT
 done
fi

# Open allowed TCP ports if any
if [ -n "$TCP_INPUT_PORTS" ] ; then
 for PORT in $TCP_INPUT_PORTS; do
  $IP6TABLES -A INPUT -m state --state NEW -p tcp --dport ${PORT} \
  -j ACCEPT
 done
fi

# Open allowed UDP ports if any
if [ -n "$UDP_INPUT_PORTS" ] ; then
 for PORT in $UDP_INPUT_PORTS; do
  $IP6TABLES -A INPUT -m state --state NEW -p udp --dport ${PORT} \
  -j ACCEPT
 done
fi

# Allow traffic to the loopback (needed by some applications)
$IP6TABLES -A INPUT -i lo -j ACCEPT

# Log and drop all other packets.
$IP6TABLES -A INPUT -j LOG
$IP6TABLES -P INPUT DROP

# Los and drop all packet to be forwarded, we're not a router...
$IP6TABLES -A FORWARD -j LOG
$IP6TABLES -P FORWARD DROP

# We're not going to filter outgoing packets
# but you can if you're paranoid like I am...
$IP6TABLES -P OUTPUT ACCEPT
}

# fw_stop disables completely the firewall and reset all chains to
# the default policy ACCEPT
fw_stop () {
  $IP6TABLES -P INPUT ACCEPT
  $IP6TABLES -P FORWARD ACCEPT
  $IP6TABLES -P OUTPUT ACCEPT
  $IP6TABLES -t mangle -P PREROUTING ACCEPT
  $IP6TABLES -t mangle -P POSTROUTING ACCEPT
  $IP6TABLES -t mangle -P INPUT ACCEPT
  $IP6TABLES -t mangle -P OUTPUT ACCEPT
  $IP6TABLES -t mangle -P FORWARD ACCEPT
  $IP6TABLES -t mangle -F
  $IP6TABLES -t mangle -X
  $IP6TABLES -F
  $IP6TABLES -X
}

# fw_clear remove the rule set from the firewall and keep the
# current default policy
fw_clear () {
  $IP6TABLES -t mangle -F
  $IP6TABLES -t mangle -X
  $IP6TABLES -F
  $IP6TABLES -X
}

case "$1" in
  start|restart)
    echo -n "Starting IPv6 firewall.."
    fw_clear
    fw_start
    echo "done."
    ;;
  stop)
    echo -n "Stopping IPv6 firewall.."
    fw_stop
    echo "done."
    ;;
  clear)
    echo -n "Clearing IPv6 firewall rules.."
    fw_clear
    echo "done."
    ;;
  test|safe-restart)
    echo -n "Safely restarting IPv6 firewall..."
    fw_clear
    fw_start
    test=""; read -t 10 -p "Is it still OK? " test ; \
    [ -z "$test" ] && fw_stop
    echo "done."
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|safe-restart|clear}"
    exit 1
    ;;
esac

exit 0

Now let’s make the ip6firewall to start at boot time :
update-rc.d ip6firewall start 41 S . stop 34 0 6 .

Now the server is only accepting packets on ports we have decided.

By the way, I’ve been certified ipv6 Guru by Hurricane Electric…

That’s all folks!

Thanks for leaving a comment if you found this useful