Description

This article explains DHCP address assignment issue where DHCP server address, irb interface, belongs to a non-primary VRRP group.

Symptoms

Customer may configure multiple VRRP groups on one irb interface in some use cases. VRRP VIPs hereby are used as gateways for different VLANs, and sometimes as server addresses such as DHCP server.

 

However, DHCP address assignment failed for DHCP clients residing in the group which is not primary. There are DHCP discover packets arriving at the switch but no responses (DHCP offer) observed as per monitoring.

 

Example configuration on VRRP Master node is listed below.

 

interfaces {

  irb {

    unit 15 {

      family inet {

        address 192.168.15.1/26 {

          vrrp-group 15 {

            virtual-address 192.168.15.62; <<<<<<< VRRP group 15

            priority 200;

            accept-data;

            track {

              interface xe-0/2/0.0 {

                priority-cost 100;

              }

            }

          }

        }

        address 172.16.16.1/26 {

          vrrp-group 16 {

            virtual-address 172.16.16.62; <<<<<<< VRRP group 16

            priority 200;

            accept-data;

            track {

              interface xe-0/2/0.0 {

                priority-cost 100;

              }

            }

          }

        }

      }

    }

  }

}

 

DHCP clients residing in VRRP group 15 (subnet 192.168.15.0/26) will not obtain IP addresses from the switch while clients in group 16 works fine.

 

The reason is that IP address (subnet) of VRRP group 16 is being elected as "Primary" on interface irb.15 on the switch. We can tell it from output of "show interface X.x extensive"

 

 Logical interface irb.15 (Index 546) (SNMP ifIndex 570) (HW Token 4294967295) (Generation 131)

  Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2

  Bandwidth: 1Gbps

  Routing Instance: default-switch Bridging Domain: MGMT

  Traffic statistics:

   Input bytes :    1615919307640

   Output bytes :     627000340259

   Input packets:     10670116196

   Output packets:      4752080055

  Local statistics:

   Input bytes :      2362508804

   Output bytes :      5454019230

   Input packets:       24064909

   Output packets:       87244914

  Transit statistics:

   Input bytes :    1613556798836        173264 bps

   Output bytes :     621546321029        90456 bps

   Input packets:     10646051287         146 pps

   Output packets:      4664835141          86 pps

  Protocol inet, MTU: 1500

  Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 56, Curr new hold cnt: 0, NH drop cnt: 0

  Generation: 147, Route table: 0

   Flags: Sendbcast-pkt-to-re, Is-Primary

   Addresses, Flags: Is-Default Is-Preferred Is-Primary <<<<<<<<<<<< Group 16 is primary

    Destination: 172.16.16.0/26, Local: 172.16.16.1, Broadcast: 172.16.16.63, Generation: 712

    Destination: 172.16.16.0/26, Local: 172.16.16.62, Broadcast: 172.16.16.63, Generation: 714

    Destination: 192.168.15.0/26, Local: 192.168.15.1, Broadcast: 192.168.15.63, Generation: 208

   Addresses, Flags: Is-Preferred

    Destination: 192.168.15.0/26, Local: 192.168.15.62, Broadcast: 192.168.15.63, Generation: 136secondary

 

This is default and expected behavior by Junos when multiple IP addresses are configured on the same interface. This behavior is explained on the link below.

 

https://www.juniper.net/documentation/us/en/software/junos/interfaces-fundamentals/topics/topic-map/protocol-family-interface-address-properties.html#id-configuring-default-primary-and-preferred-addresses-and-interfaces

 

Capture as below.

 

"When assigned multiple IP addresses, none of which are explicitly configured as primary, the numerically lowest IP address is uses as the primary address on that interface."

 

Thus, subnet "172.16.16.0/26" of VRRP group 16 are elected as primary as expected.

Solution

>>> To fix the issue, we need to explicitly configured address/subnet of VRRP group 15 as primary.

 

set interfaces irb.15 family inet address 192.168.15.1/26 primary

 

>>> However, this configuration will prevent VRRP group 16 from responding to DHCP discover so we may consider separate two VRRP groups into two individual IRB interfaces to make both groups work as DHCP server.

Modification History

2024-08-12 : Article Created