This article describes how to configure Allowed Address Pair (AAP) in Contrail web UI for two different scenarios.
When using Active/Standby high availability (HA) for VNFs of the same service chain, HA features other than Contrail are required to achieve the scenario. As a possible solution, the setup must provide a virtual IP (VIP) address and a corresponding MAC address. By configuring the Allowed Address Pair (AAP) feature, the VIP is exposed and available to use.
For a brief introduction of AAP, refer to Service Chain Active-Standby Mode with Allowed Address Pair . For configuration via CLI, refer to KB33573 - Configuring and verifying AAP from CLI [juniper.net] .
For MAC address, there are two options depending on the HA feature, such as PCS (pacemaker + corosync) or VRRP. PCS is for the server-side clustering package, which does not have a virtual MAC address, whereas VRRP, which is a well-known feature in the router, has a virtual MAC address with VRRP group ID.
The GUI configuration in the following two scenarios is as follows:
HA clustering without virtual MAC address
In the scenario in the article, the protocol is described with PCS in CentOS 7 as an example of HA software. The following setting has already been configured and VM-a has a VIP address for the primary node.
VM-a: IP=10.1.0.6 MAC=00:66:66:66:66:66 VM-b: IP=10.1.0.6 MAC=00:77:77:77:77:77 VIP: 10.1.0.99
Notes
[root@vm-a ~]# pcs status Cluster name: <snip> Online: [ vm-a vm-b ] Full list of resources: VIP (ocf::heartbeat:IPaddr2): Started vm-a Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled [root@vm-a ~]# ip a show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:66:66:66:66:66 brd ff:ff:ff:ff:ff:ff inet 10.1.0.6/24 brd 10.1.0.255 scope global noprefixroute eth0 valid_lft forever preferred_lft forever inet 10.1.0.99/24 brd 10.1.0.255 scope global secondary eth0 <<<< VIP is in VM-a's interface. valid_lft forever preferred_lft forever [root@vm-b ~]# ip a show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:77:77:77:77:77 brd ff:ff:ff:ff:ff:ff inet 10.1.0.7/24 brd 10.1.0.255 scope global noprefixroute eth0 valid_lft forever preferred_lft forever
Now, ping is not yet reachable from other host.
$ ping 10.1.0.99 PING 10.1.0.99 (10.1.0.99): 56 data bytes ^C --- 10.1.0.99 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss $
To configure AAP, navigate to Configure > Ports > Gear icon > Edit for the Virtual Machine Interface (VMI) IP address of the target VM.
In the first VMI edit window, fill the Advanced Options > Allowed address pair(s) IP field with the VIP address.
To accomplish a VIP address without the virtual MAC address for PCS, the MAC field must be blank (displays "MAC" in light gray string).
The Address Mode field has Active-Standby selected by default.
Then, click Save .
In the second VMI edit window, fill the Advanced Options > Allowed address pair(s) IP field with the same VIP address as the first VMI setting.
The MAC field is blank again. The Address Mode field has Active-Standby selected by default.
After the above configuration, the ping is reachable from the other host.
$ ping 10.1.0.99 -c 3 PING 10.1.0.99 (10.1.0.99): 56 data bytes 64 bytes from 10.1.0.99: seq=0 ttl=64 time=6.243 ms 64 bytes from 10.1.0.99: seq=1 ttl=64 time=2.453 ms 64 bytes from 10.1.0.99: seq=2 ttl=64 time=2.848 ms --- 10.1.0.99 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 2.453/3.848/6.243 ms $
VM-a's MAC address is on the ARP table of the sender of the ping.
$ arp -n 10.1.0.99 ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 $
When you try to perform a switchover, then the MAC address updates are seen as shown below:
[root@vm-a ~]# pcs status resources VIP (ocf::heartbeat:IPaddr2): Started vm-a [root@vm-a ~]# pcs resource move VIP [root@vm-a ~]# pcs status resources VIP (ocf::heartbeat:IPaddr2): Started vm-b $ while :; do arp -n 10.1.0.99; sleep 1; done ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 ? (10.1.0.99) at 00:66:66:66:66:66 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ? (10.1.0.99) at 00:77:77:77:77:77 [ether] on eth0 ^C $ ping 10.1.0.99 -c 3 PING 10.1.0.99 (10.1.0.99): 56 data bytes 64 bytes from 10.1.0.99: seq=0 ttl=64 time=8.825 ms 64 bytes from 10.1.0.99: seq=1 ttl=64 time=3.053 ms 64 bytes from 10.1.0.99: seq=2 ttl=64 time=2.566 ms --- 10.1.0.99 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 2.566/4.814/8.825 ms $
In this scenario, the vSRX devices have the following setting:
vSRX-a: IP=10.2.0.4 MAC=00:44:44:44:44:44 vSRX-b: IP=10.2.0.5 MAC=00:55:55:55:55:55 VRRP group: 1 VRRP address: 10.2.0.99 Virtual MAC: 00:00:5e:00:01:01 user@vsrx-a# show interfaces ge-0/0/1 { unit 0 { family inet { address 10.2.0.4/24 { vrrp-group 1 { virtual-address 10.2.0.99; } } } } }
The virtual MAC is automatically assigned as "00:00:5e:00:01:01:xx". The last part of xx is the number of the vrrp-group parameter.
user@vsrx-a# run show vrrp interface ge-0/0/1 <snip> Physical interface: ge-0/0/1, Unit: 0, Address: 10.2.0.4/24 Index: 70, SNMP ifIndex: 512, VRRP-Traps: disabled, VRRP-Version: 2 Interface state: up, Group: 1, State: master, VRRP Mode: Active Priority: 100, Advertisement interval: 1, Authentication type: none Advertisement threshold: 3, Computed send rate: 0 Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.2.0.99 Advertisement Timer: 0.237s, Master router: 10.2.0.4 Virtual router uptime: 00:00:19, Master router uptime: 00:00:12 Virtual Mac: 00:00:5e:00:01:01
For details of VRRP, refer to the following documents:
Configuring VRRP
Configuring Basic VRRP Support
The configuration is similar to Scenario 1. On the vSRX-a VMI, fill the Advanced Options > Allowed address pair(s) IP field with the VIP address and the MAC field with the virtual MAC address, which is collected from the vSRX CLI.
Again on the second node vSRX-b, fill the Advanced Options > Allowed address pair(s) IP field with the VIP address and the MAC field.
The same IP/MAC address pair needs to be configured in both VMI setting.
After that, VRRP works in this VNF.
To identify which node vSRX is active, refer to KB35842- [Contrail] Determine the active and backup VMI for an AAP address configured with vMAC [juniper.net] .
Note: When the VIP/MAC address pair is updated, GARP is transmitted. This is handled as a BUM packet. Therefore, the multicast tree needs to be created properly. The information is conveyed by the erm-vpn (Edge Replicated Multicast) route between controllers. The Address family erm-vpn is enabled by default.
Navigate to Configure > Infrastructure > BGP Routers > Gear icon.
If this address family is removed, the BUM packet might not be transferred as expected, so do not remove it.
Here is an example of the problematic scenario.
There are several compute nodes. Some are ping-able to VIP but some are not.
[root@comp01 ~]# vif --list | grep -C1 10.1.0 vif0/3 OS: tap862d7923-f9 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.1.0.6 Vrf:2 Mcast Vrf:2 Flags:PL3L2DEr QOS:-1 Ref:6 < Check the vrf number to use next to the curl command "vrf_index=" parameter. [root@comp01 ~]# curl -s "http://${compute-node-ip}:8085/Snh_Layer2RouteReq?vrf_index=2" | xmllint --format - | sed -n '/ff:ff:ff:ff/,/\/mc_list/p'
Working scenario node output:
<mc_list type="list" identifier="14"> <list type="struct" size="6"> <McastData> <type type="string" identifier="1">Interface 0 <itf type="string" identifier="5" link="ItfReq">tapc1e1c18e-23 <McastData> <type type="string" identifier="1">Interface 0 <itf type="string" identifier="5" link="ItfReq">tapf6b67bfe-d6 <McastData> <type type="string" identifier="1">Tunnel <sip type="string" identifier="2">192.168.101.21 <dip type="string" identifier="3">192.168.101.22 4146 <McastData> <type type="string" identifier="1">Tunnel <sip type="string" identifier="2">192.168.101.21 <dip type="string" identifier="3">192.168.101.23 <-- source-ip 192.168.101.21/destination-ip 192.168.101.23 is listed. 4666 <McastData> <type type="string" identifier="1">Tunnel <sip type="string" identifier="2">192.168.101.21 <dip type="string" identifier="3">192.168.101.24 4146 <McastData> <type type="string" identifier="1">Tunnel <sip type="string" identifier="2">192.168.101.21 <dip type="string" identifier="3">192.168.101.28 4624
Wrong scenario node output:
<mc_list type="list" identifier="14"> <list type="struct" size="5"> <McastData> <type type="string" identifier="1">Interface 0 <itf type="string" identifier="5" link="ItfReq">tapc1e1c18e-23 <McastData> <type type="string" identifier="1">Interface 0 <itf type="string" identifier="5" link="ItfReq">tapf6b67bfe-d6 <McastData> <type type="string" identifier="1">Tunnel <sip type="string" identifier="2">192.168.101.21 <dip type="string" identifier="3">192.168.101.22 4257 <McastData> <type type="string" identifier="1">Tunnel <-- source-ip 192.168.101.21/destination-ip 192.168.101.23 is missing. <sip type="string" identifier="2">192.168.101.21 <dip type="string" identifier="3">192.168.101.24 4144 <McastData> <type type="string" identifier="1">Tunnel <sip type="string" identifier="2">192.168.101.21 <dip type="string" identifier="3">192.168.101.28 4637
The controller nodes do not transfer the erm-vpn information to each other if the family is deleted from GUI.
If compute nodes form XMPP to the same controller, the BUM packet will reach to the other node via the tree information.
The above node in the wrong scenario is not connected to the same controller. Hence, it cannot get the correct tree information. Eventually, it installs the wrong tree and then BUM packets are cannot reach the other node.
2021-03-24: Updated the article terminology to align with Juniper's Inclusion & Diversity initiatives
2021-07-19: Corrected the IP address field of AAP configuration with virtual MAC