In this article, we describe a scenario where two devices are configured in an MC‑LAG architecture running VRRP between them. Even though one device shows as Active and the other as Backup, and VRRP advertisements are being exchanged, they are unable to ping each other. We also include a scenario where ICCP remains down which is also due to the same root cause.

• VRRP is up, with Active/Backup roles assigned correctly.
• No connectivity between the IRBs used for VRRP across the ICL/ICCP link.
• ICCP is down, and ">show system connections" does not display the full handshake for ICCP port.
• A Firewall is configured either on the IRB or on the loopback interface.

The devices are unable to reach each other; however, the VRRP outputs display the correct states between them. MC‑lag1 shows as the Active member, while MC‑lag2 is in Backup state, and VRRP advertisements are being exchanged from the peer across the ICL/ICCP link:

root@MC-lag1> show vrrp extensive
Interface: irb.1, Interface index :835, Groups: 1, Active :1
Interface VRRP PDU statistics
Advertisement sent :188577
Advertisement received :6

Physical interface: irb, Unit: 1, Address: 10.10.10.2/24
Index: 835, SNMP ifIndex: 551, VRRP-Traps: disabled, VRRP-Version: 2
Interface state: up, Group: 1, State: master, VRRP Mode: Active
Priority: 110, Advertisement interval: 1, Authentication type: none
Advertisement threshold: 3, Computed send rate: 0
Preempt: yes, Accept-data mode: yes, VIP count: 1, VIP: 10.10.10.1
Advertisement Timer: 0.356s, Master router: 10.10.10.2  > Sees itself as the Active router.
Virtual router uptime: 1d 22:04, Master router uptime: 1d 22:04
Virtual Mac: 00:00:5e:00:01:6e

root@MC-lag2> show vrrp extensive
Interface: irb.1, Interface index :890, Groups: 1, Active :1
Interface VRRP PDU statistics
Advertisement sent :298
Advertisement received :190644

Physical interface: irb, Unit: 1, Address: 10.10.10.3/24
Index: 890, SNMP ifIndex: 616, VRRP-Traps: disabled, VRRP-Version: 2
Interface state: up, Group: 1, State: backup, VRRP Mode: Active
Priority: 100, Advertisement interval: 1, Authentication type: none
Advertisement threshold: 3, Computed send rate: 0
Preempt: yes, Accept-data mode: yes, VIP count: 1, VIP: 10.10.10.1
Dead timer: 3.456s, Master priority: 110, Master router: 10.10.10.2 > Sees MC-lag1 as the Active router.
Virtual router uptime: 1d 22:39
Preferred: yes

Upon further review, we can see that the Firewall filter "PROTECT‑RE" is applied on the Loopback interface. Below is the Firewall configuration as it appears on both peers:

set firewall family inet filter PROTECT-RE term ICMP from protocol icmp
set firewall family inet filter PROTECT-RE term ICMP from icmp-type echo-request
set firewall family inet filter PROTECT-RE term ICMP from icmp-type echo-reply
set firewall family inet filter PROTECT-RE term ICMP then accept
set firewall family inet filter PROTECT-RE term VRRP from protocol vrrp
set firewall family inet filter PROTECT-RE term VRRP from protocol ah
set firewall family inet filter PROTECT-RE term VRRP then accept
set firewall family inet filter PROTECT-RE term Discard then log
set firewall family inet filter PROTECT-RE term Discard then discard

VRRP exchanges were functioning correctly, but ICMP should also have been allowed. After disabling and reapplying the Firewall filter, ICMP traffic began flowing through the ICL as permitted by the Firewall terms; however, ICCP remained down. When we checked "> show system connections inet | match 33012", the TCP connection was still in "LISTEN" state. Please ensure that the TCP and UDP ports required for ICCP are included if you configure a filter on the loopback interface.

• ICCP session – TCP 33012: This is the control channel for ICCP (Inter‑Chassis Communication Protocol). It’s the TCP port used to establish and maintain the ICCP session between MC‑LAG peers, allowing them to synchronize state information.
• BFD – UDP 4784: Bidirectional Forwarding Detection (BFD) runs over UDP port 4784: It’s used to provide rapid detection of link or path failures between peers, ensuring ICCP can quickly react if connectivity drops.
• BLD – UDP 50015: This port is used for the Backplane Link Detection (BLD) mechanism. It helps monitor and validate connectivity across the inter‑chassis link, ensuring that traffic forwarding remains consistent and reliable.

After adding the following statements, the ICCP connection came up:

set firewall family inet filter PROTECT-RE term ICCP-IN from protocol tcp
set firewall family inet filter PROTECT-RE term ICCP-IN from destination-port 33012
set firewall family inet filter PROTECT-RE  term ICCP-IN then accept
set firewall family inet filter PROTECT-RE  term ICCP-OUT from protocol tcp
set firewall family inet filter PROTECT-RE term ICCP-OUT from source-port 33012
set firewall family inet filter PROTECT-RE  term ICCP-OUT then accept
set firewall family inet filter PROTECT-RE  term MHBFD from protocol udp
set firewall family inet filter PROTECT-RE term MHBFD from destination-port 4784
set firewall family inet filter PROTECT-RE  term MHBFD then accept
set firewall family inet filter PROTECT-RE  term ICCP-BLD from protocol udp
set firewall family inet filter PROTECT-RE  term ICCP-BLD from source-port 50015
set firewall family inet filter PROTECT-RE  term ICCP-BLD from destination-port 50015
set firewall family inet filter PROTECT-RE  term ICCP-BLD then accept