Description

A redundant Ethernet (reth) interface is configured on SRX, which is connected to a switch and then to an upstream device. A proxy-arp is configured for an IP address on reth interface, but the upstream device is learning the MAC address of the secondary node's child interface of reth when it should be learning the reth of the virtual MAC.

This happens when IP-monitoring is configured and the IP-address is being used for which proxy-arp is configured as a secondary-ip-address in the IP-monitoring configuration. The secondary-ip-address should be an IP address which is not being used anywhere else.

Symptoms

The Upstream device should learn the virtual MAC of reth interface.

Solution

This happens when IP-monitoring is configured and the IP-address is being used for which proxy-arp is configured as a secondary-ip-address in the IP-monitoring configuration. This IP will be used as the source to send pings from secondary node for ip-monitoring. Since this IP-address will be used by the secondary-node to send ICMP probes, the upstream device learns the MAC of secondary node's child interface.

For example consider the following topology:

MAC Cluster

On SRX cluster we have the following configuration: 
root@CLUSTER# show chassis cluster redundancy-group 1 ip-monitoring 
global-weight 230;
global-threshold 70;
retry-interval 6;
retry-count 7;
family {
    inet {
        10.10.10.2 {
            weight 30;
            interface reth0.0 secondary-ip-address 10.10.10.3;
        }
    }
}

security {
    nat {
        proxy-arp {
            interface reth0.0 {
                address {
                    10.10.10.3/32;
                }
            }
        }
    }
}
From this it can be seen that there is a proxy-arp configured for 10.10.10.3, but that IP address is also being used as secondary-ip-address in ip-monitoring. Also the MAC addresses of child interface of reth0 (fe-0/0/5 from each node) are as follows: 
root@100-2# run show interfaces fe-0/0/5 extensive | match hardware
  Current address: 00:10:db:ff:10:00, Hardware address: 00:26:88:4f:c8:05

root@100-3# run show interfaces fe-0/0/5 extensive | match hardware
  Current address: 00:10:db:ff:10:00, Hardware address: 28:c0:da:e1:50:85
Checking the ICMP sessions   and arp entries on the upstream SRX 100-1 device: 
root@100-1# run show security flow session protocol icmp 
Session ID: 12566, Policy name: self-traffic-policy/1, Timeout: 2, Valid
  In: 10.10.10.1/877 --> 10.10.10.2/256;icmp, If: fe-0/0/5.0, Pkts: 1, Bytes: 44
  Out: 10.10.10.2/256 --> 10.10.10.1/877;icmp, If: .local..0, Pkts: 1, Bytes: 44

Session ID: 12567, Policy name: self-traffic-policy/1, Timeout: 2, Valid
  In: 10.10.10.3/877 --> 10.10.10.2/512;icmp, If: fe-0/0/5.0, Pkts: 1, Bytes: 44
  Out: 10.10.10.2/512 --> 10.10.10.3/877;icmp, If: .local..0, Pkts: 1, Bytes: 44
Total sessions: 2
[edit]
root@100-1# run show arp no-resolve | match 10.10.10.3 
28:c0:da:e1:50:85 10.10.10.3      fe-0/0/5.0           none
The ICMP sessions are the ip-monitoring ping packets sent by the cluster causing 100-1 to learn the MAC address of 10.10.10.3 as secondary node's interface. It can be seen that for 10.10.10.3 the MAC address learnt is not the virtual MAC of reth (which is 00:10:db:ff:10:00), but MAC address of fe-0/0/5 interface of 100-3.



The secondary-ip-address should be an IP address which is not being used anywhere else. The solution is to use a different IP address,

Related Information