This Simple UCarp Lab, will introduce a sample configuration of UCarp in a Routing environment.

For this lab, I used the bsdrp version 0.32 full vga i386 image. The vitual lab has been made with the Qemu 0.11.0. . The Routeur images have been created with these names R1.qcow, R2.qcow, R3.qcow and R4.qcow respectively for R1, R2, R3 and R4.

The virtual routeur creation will have:

Note: The harddrive path can be needed depending on the method used to create them.

qemu -m 128 -hda R1.qcow \
     -net nic,macaddr=08:00:27:01:12:01,vlan=12 -net socket,mcast=230.10.0.1:1212,vlan=12 \
     -net nic,macaddr=08:00:27:01:13:01,vlan=13 -net socket,mcast=230.10.0.1:1313,vlan=13

qemu -m 128 -hda R2.qcow \
     -net nic,macaddr=08:00:27:02:12:02,vlan=12 -net socket,mcast=230.10.0.1:1212,vlan=12 \
     -net nic,macaddr=08:00:27:02:24:02,vlan=24 -net socket,mcast=230.10.0.1:2424,vlan=24

qemu -m 128 -hda R3.qcow \
     -net nic,macaddr=08:00:27:03:13:03,vlan=13 -net socket,mcast=230.10.0.1:1313,vlan=13 \
     -net nic,macaddr=08:00:27:03:34:03,vlan=34 -net socket,mcast=230.10.0.1:3434,vlan=34

qemu -m 128 -hda R4.qcow \
     -net nic,macaddr=08:00:27:04:24:04,vlan=24 -net socket,mcast=230.10.0.1:2424,vlan=24 \
     -net nic,macaddr=08:00:27:04:34:04,vlan=34 -net socket,mcast=230.10.0.1:3434,vlan=34

Any liveCD with a Linux distribution should be suffisant. In this example we will use a Dawn Small Linux version (dsl-4.4.10.iso).

qemu -m 128 -cdrom  dsl-4.4.10.iso \
     -net nic,macaddr=08:00:27:55:12:55,vlan=12 -net socket,mcast=230.10.0.1:1212,vlan=12

For all routers at the first boot

system virtualized
reboot

Edit rc.conf and add/modify

hostname="R1.carp.lab"
ifconfig_re0="inet 10.0.12.1 netmask 255.255.255.0"

The configuration will be active after the following command.

/etc/rc.d/netif restart

Edit rc.conf and add/modify

hostname="R2.carp.lab"
ifconfig_re0="inet 10.0.12.2 netmask 255.255.255.0"

The configuration will be active after the following command.

/etc/rc.d/netif restart

Edit rc.conf and add/modify

hostname="R3.carp.lab"

The configuration will be active after the BSDRP reboot.

Edit rc.conf and add/modify

hostname="R4.carp.lab"
cloned_interfaces="lo4"
ifconfig_lo4="inet 10.0.4.4 netmask 255.255.255.255"

The configuration will be active after the following command.

/etc/rc.d/netif restart

If you are using linux based workstation guest with a harddrive installation, we can make a permanent configuration to restart the lab without initial setup.

Example for a debian environment: Edit the file /etc/network/interfaces

iface eth0 inet static
  address 10.0.12.100
  netmask 255.255.255.0
  gateway 10.0.12.254

Then bring the interface down and up should enable the IP configuration of the interface Eth0. The configuration will be present after a reboot.

Or if we want to change the configuration of a Live Distribution Example for a debian DSL environment: Open a terminal

sudo su
ifconfig 10.0.12.100 netmask 255.255.255.0
route add default gw 10.0.12.254

To enable ucarp, you have to modify the following parameters on the router configuration file /etc/rc.conf:

ucarp_enable="YES"

ucarp_if="re0"

ucarp_src="10.0.12.1"

ucarp_vhid="1"

ucarp_pass="passcarp"

ucarp_preempt="NO"

ucarp_addr="10.0.12.254"

ucarp_advskew="200"
ucarp_shutdown="NO"

ucarp_facility="daemon"

The IP adress of re0 is 10.0.12.1, and if R1 is the ucarp Master it will route the packet adress to 10.0.12.254 has a next hop.

ucarp_enable="YES"

ucarp_if="re0"

ucarp_src="10.0.12.2"

ucarp_vhid="1"

ucarp_pass="passcarp"

ucarp_preempt="YES"

ucarp_addr="10.0.12.254"
ucarp_advskew="10"

ucarp_shutdown="NO"

ucarp_facility="daemon"

The IP adress of re0 is 10.0.12.2, and if R2 is the ucarp Master it will route the packet adress to 10.0.12.254 has a next hop. The parameter ucarp_advskew=“10” make R2 a better choice for ucarp.

The previous configuration parameters are what are expecting to run the lab.

At this stage we can do a first check to see if the two Routers R1 and R2 have exchange UCarp information and decided Who is the master!

Depending on the boot order the first router that can provide the virtual IP will be the Master. Check the uCarp status:

R2:

[root@R2]~#cat /var/log/messages | grep ucarp
May 18 14:57:25 R2 ucarp[704]: [WARNING] Warning: no script called when going up
May 18 14:57:25 R2 ucarp[704]: [WARNING] Warning: no script calledwhen going down
May 18 14:57:25 R2 ucarp[705]: [WARNING] Switching to state: BACKUP
May 18 14:57:26 R2 ucarp[705]: [WARNING] Switching to state: MASTER
May 18 14:57:27 R2 ucarp[705]: [WARNING] Putting MASTER down - preemption
May 18 14:57:27 R2 ucarp[705]: [WARNING] Non-preferred master advertissing: reasserting control of VIP with another gratuitous arp 

R1:

[root@R1]~#cat /var/log/messages | grep ucarp
May 18 14:49:41 R1 ucarp[704]: [WARNING] Warning: no script called when going up
May 18 14:49:41 R1 ucarp[704]: [WARNING] Warning: no script calledwhen going down
May 18 14:49:41 R1 ucarp[705]: [WARNING] Switching to state: BACKUP
May 18 14:49:45 R1 ucarp[705]: [WARNING] Switching to state: MASTER
May 18 14:57:26 R1 ucarp[705]: [WARNING] Switching to state: BACKUP
May 18 14:57:26 R1 ucarp[705]: [WARNING] Preferred master advertised: going back to BACKUP state

Here we can see R1 is the BACKUP and R2 is the MASTER.

Quagga (vtysh)

configure terminal
interface re0
descriprtion conf in  rc.conf 10.0.12.1/24
exit
interface re1
ip address 10.0.13.1/24
exit
router ospf
 redistribute connected
 network 10.0.13.0/24 area 0
end

Quagga (vtysh)

configure terminal
interface re0
 descriprtion conf in  rc.conf 10.0.12.2/24
exit
interface re1
 ip address 10.0.24.2/24
exit
router ospf
 redistribute connected
 network 10.0.24.0/24 area 0
end

Quagga (vtysh)

configure terminal
interface re0
 ip address 10.0.13.3/24
exit
interface re1
 ip address 10.0.34.3/24
exit
router ospf
 network 10.0.13.0/24 area 0
 network 10.0.34.0/24 area 0
end

Quagga (vtysh)

configure terminal
interface re0
 ip address 10.0.24.4/24
exit
interface re1
 ip address 10.0.34.4/24
exit
router ospf
 redistribute connected
 network 10.0.24.0/24 area 0
 network 10.0.34.0/24 area 0
end

At this stage do not forget to save the configuration:

Quagga (vtysh)

write memory

BSDRP system

config save

Now we will test the behavior of the configuration. The workstation will contact the loopback 10.0.4.4 and we will create different events on the router R2.

Workstation contact lo4 with a ping

PING 10.0.4.4 (10.0.4.4) 56(84) bytes of data.
64 bytes from 10.0.4.4: icmp_seq=1 ttl=63 time=2.72 ms
64 bytes from 10.0.4.4: icmp_seq=2 ttl=63 time=1.92 ms
64 bytes from 10.0.4.4: icmp_seq=3 ttl=63 time=6.55 ms
64 bytes from 10.0.4.4: icmp_seq=4 ttl=63 time=5.23 ms
64 bytes from 10.0.4.4: icmp_seq=5 ttl=63 time=9.07 ms

The TTL is 63, so only one jump, we are passing by R2 to reach Lo4.

Now we shutdown the R2 routeur by the command line on R2 or by a more direct way with the virtual manager.

shutdown -h now

What we can see, as soon as the R2 goes down the ping echo stop, we have no more reply from lo4. In the example the ping stop to reply at the sequence number 27. If we check at R1, it is already the MASTER for ucarp, but not reply. It is due to the convergence time of OSPF. For the moment, R4 still holding the best return path to the ping through R2. The link that is between R4 and R2 is not a point to point, so R4 have to wait for its timers to expires before dropping the route from R2. Then at the sequence 54 we have the reply!

The TTL of the echo is now 62, that means this packet pass by R3.

Note: The ospf convergence time is around 50 seconds, it has an extra latency due to the host system.

64 bytes from 10.0.4.4: icmp_seq=24 ttl=63 time=12.2 ms
64 bytes from 10.0.4.4: icmp_seq=25 ttl=63 time=8.54 ms
64 bytes from 10.0.4.4: icmp_seq=26 ttl=63 time=3.19 ms
64 bytes from 10.0.4.4: icmp_seq=54 ttl=62 time=1.37 ms
64 bytes from 10.0.4.4: icmp_seq=55 ttl=62 time=1.43 ms
64 bytes from 10.0.4.4: icmp_seq=56 ttl=62 time=1.94 ms
64 bytes from 10.0.4.4: icmp_seq=57 ttl=62 time=1.26 ms

Now we restart the R2 router.

I have an interresting reading, that looks like the lost packets are replayed. It could be a buffer that kept thoses records.

As we can see, they were routed to R2 (TTL 63) until OSPF route them to R3 (starting sequence 54).

64 bytes from 10.0.4.4: icmp_seq=47 ttl=63 time=66455 ms
64 bytes from 10.0.4.4: icmp_seq=48 ttl=63 time=65454 ms
64 bytes from 10.0.4.4: icmp_seq=49 ttl=63 time=64439 ms
64 bytes from 10.0.4.4: icmp_seq=50 ttl=63 time=63440 ms
64 bytes from 10.0.4.4: icmp_seq=51 ttl=63 time=62441 ms
64 bytes from 10.0.4.4: icmp_seq=52 ttl=63 time=61440 ms
64 bytes from 10.0.4.4: icmp_seq=53 ttl=63 time=60439 ms

The router will create its ucarp interface and will challenge the other interfaces. Because it is the best interface it will claim back its MASTER status. At the same time it will reach R4 and send its routing information. R4 will update its routing table and send the packet back to R2 as it is the best path. It happens between sequence 125 and 126 in the following sequence.

64 bytes from 10.0.4.4: icmp_seq=123 ttl=62 time=7.59 ms
64 bytes from 10.0.4.4: icmp_seq=124 ttl=62 time=11.6 ms
64 bytes from 10.0.4.4: icmp_seq=125 ttl=62 time=6.50 ms
64 bytes from 10.0.4.4: icmp_seq=126 ttl=63 time=0.001 ms
64 bytes from 10.0.4.4: icmp_seq=127 ttl=63 time=8.27 ms
64 bytes from 10.0.4.4: icmp_seq=128 ttl=63 time=4.45 ms
64 bytes from 10.0.4.4: icmp_seq=129 ttl=63 time=2.98 ms

R2 interface re1 goes down:

• R2 stay the master of ucarp
• R4 will update is routing table to reach network 10.0.12.0/24 by R3
• R2 will reply to the workstation since it is the master network unreachable.

When R2 interface re1 goes up:

• R2 still the master.
• R2 reach its ospf neighbor R4 and send its routing information about 10.0.12.0/24
• R4 update its routing table and select the best path to 10.0.12.0/24 by R2
• workstation reach lo4 10.0.4.4.

if R2 interface re0 goes down:

• R1 will change status from backup to master
• R2 will update R4 about its connection lost
• R4 updates its routing table and choose to reach network 10.0.12.0/24 by R3
• workstation still reach lo4 10.0.4.4.

when R2 interface re0 goes back up

• R2 update R4 about its routing up
• R4 update its routing table and choose to reach network 10.0.12.0/24 by R2
• R1 stay the master.
• workstation traffic flow will go:

workstation → R1 → R3 → R4 → lo4

• and the return path is:

lo4 → R4 → R2 → Workstation

• we have an asymetric traffic

this lab example demonstrate the requirement of a correct architecture that could interoperate a routing protocol with a high availability protocol.

In this example the lack of direct routing protocol in between the ucarp router creates undesireable state and convergence time issue.