Description

The disable-arp-policer statement does not work after system reboot. This article gives the reason and the workaround for this issue.

 

Symptoms

  1. Configure disable-arp-policer on the interface:

Configuration Example 

interfaces {
    xe-5/2/0 {
        flexible-vlan-tagging;
        encapsulation flexible-ethernet-services;
        no-gratuitous-arp-request;
        unit 1008 {
            demux-source inet;
            proxy-arp restricted;
            vlan-id 1008;
            family inet {
                policer {                    
                    disable-arp-policer;
                }
                unnumbered-address lo0.0 preferred-source-address 10.0.0.1;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.0.0.1/32;
            }
        }
    }
}
user@mx# run show interfaces xe-5/2/0 extensive | match "index|arp"
  Interface index: 163, SNMP ifIndex: 19833, Generation: 196
  Logical interface xe-5/2/0.1008 (Index 335) (SNMP ifIndex 19784) (Generation 240)
      Donor interface: lo0.0 (Index 320)  
  <<<<<disable-arp-policer works and has no "__default_arp_policer__" on this unit>>>>>>
  Logical interface xe-5/2/0.32767 (Index 424) (SNMP ifIndex 20331) (Generation 329)
      Policer: Input: __default_arp_policer__

  1. Reboot the system. 

user@mx# run request system reboot
Reboot the system ? [yes,no] (no) yes

Shutdown NOW!
[pid 21846]

[edit]
user@mx#
*** FINAL System shutdown message from user@mx ***

System going down IMMEDIATELY

  1. After system bootup, the disable-arp-policer configuration does not work. 

user@mx# show interfaces xe-5/2/0 | display inheritance no-comments
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
no-gratuitous-arp-request;
unit 1008 {
    demux-source inet;
    proxy-arp restricted;
    vlan-id 1008;
    family inet {
        policer {
            disable-arp-policer;
        }
        unnumbered-address lo0.0 preferred-source-address 10.0.0.1;
    }
}

user@mx> show interfaces xe-5/2/0 extensive | match "index|arp"
  Interface index: 163, SNMP ifIndex: 19833, Generation: 166
  Logical interface xe-5/2/0.1008 (Index 335) (SNMP ifIndex 19784) (Generation 144)
      Donor interface: lo0.0 (Index 320)
      Policer: Input: __default_arp_policer__          <<<<<<<<<"__default_arp_policer__" still exists
  Logical interface xe-5/2/0.32767 (Index 336) (SNMP ifIndex 20331) (Generation 145)
      Policer: Input: __default_arp_policer__

 

Solution

The reason is the failure of the get fpc i2c_id command.

When the router reboots, the firewall daemon (DFWD) is launched with a commit check and after the commit check is complete, DFWD is restarted. During this process, DFWD is able to get the I2C ID.

However, immediately after the above step is complete, DFWD will restart again following an internal trigger. During this restart, DFWD fails to get the I2C ID from the hardware database. Therefore, the capability is masked out in the capability check that is performed through dfwd_platform_capability_check .

  
Oct  5 13:25:23 dfwd_dax_read_ifl(): action=DAX_ITEM_CHANGED parse_mode=DFWD_RESTART <<<<<<<<<
Oct  5 13:25:23 ifl init :mr(ge-0/0/0.0 :1)
Oct  5 13:25:23 iff family init (ge-0/0/0.0.2)
Oct  5 13:25:23 parse iff inet ge-0/0/0.
Oct  5 13:25:23 inet obj policer found in config
Oct  5 13:25:23 DFWD_IFD_FPC_STATUS_OK
Oct  5 13:25:23 iff family init ge-0/0/0 fpc_slot 0 ret_code 0
Oct  5 13:25:23 B PC iff family init ge-0/0/0 disable_arp_policer_flag = 0
Oct  5 13:25:23 dfwd_get_fpc_i2c_id (1263): error while getting i2cid from hwdb No such attribute
Oct  5 13:25:23 dfwd_get_fpc_i2c_id (1263): error while getting i2cid from hwdb No such attribute
Oct  5 13:25:23 dfwd_get_fpc_i2c_id (1263): error while getting i2cid from hwdb No such attribute
Oct  5 13:25:23 Default False
Oct  5 13:25:23 dfwd_platform_capability_check: is_trio 0     <<< is_trio capability check fails due to above error. Hence config is ignored.

 

To clear the failure, the commit full command must be executed after system reboot: 

user@mx# commit full
re0:
configuration check succeeds
re1:
commit complete
re0:
commit complete

From chassisd point, get fpc i2c_id failure is expected during router reboot till the hardware database is initialized.

However, in DFWD, get fpc i2c_id cannot be retried, which may lead to adverse effects.

Therefore, a " commit full " is the suggested workaround for any firewall or non-firewall feature that is dependent on I2C ID.