6in4 Tunnel
May 16, 2010
Thanks to company like Hurricane Electric or SixXS it is very easy to connect to IPv6 Internet backbone even if your ISP does not provide native access to IPv6. Those companies provide free access to their tunnel brokers. A tunnel broker is a dual homed router connected to IPv4 Internet backbone on one side and to IPv6 backbone on the other side. The concept is quite simple, you have access to the IPv4 world and you want to access the IPv6 world. You just need to build a 6in4 tunnel from your DSL router or from your PC or actually from whatever IPv4/IPv6 capable you want to the tunnel broker on the IPv4 side and you’ll encapsulate your IPv6 traffic into that tunnel. The broker will decapsulate your IPv6 packets and send them to the IPv6 Internet backbone. The tunnel broker will also advertise your IPv6 range to the backbone in order to allow the traffic to flow back to your 6in4 tunnel.
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…
SNMP on Debian
April 20, 2010
If you want to monitor your servers from a central management station, you’ll probably need to configure an SNMP daemon on your servers. Here is a quick note to show you how easy it is to get started with SNMP on Linux machine (examples are for Debian but should be easy to adapt for other distribution).
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
Dual stack IPv4/IPv6 on FreeBSD
April 14, 2010
Here is a quick note to show how easy it is to enable a dual IP stack on FreeBSD (and actually on most modern system)…
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=8843metric 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!
Dynamic Multipoint VPN – Dual hub
March 6, 2010
In a previous article, I exposed how to setup a basic DMVPN network with one hub router in a central location and several spoke routers negotiating a dynamically built IPSec protected GRE tunnel. I also explained the central site should be secured by deploying two hub routers… Here is one solution among others using DMVPN and OSPF. (Should you need another solution you can always contact our professional services)

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…
ACE software upgrade
February 10, 2010
Cisco Application Control Engine Module (ACE) loadbalancers are designed to work in standalone mode or in cluster mode. When running in standalone mode, software upgrade has obviously a great impact on the traffic going through the loadbalancer. All the sessions will be dropped and no new session will be accepted until the ACE restarts with the new image (up to 8 minutes).
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 2nd 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 2nd 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…



Recent Comments