This article describes a possible issue that may be encountered when using "hardware timestamping" for Real-Time Performance Monitoring (RPM) and recommends removing the hardware timestamping feature in this case to resolve such an issue.

As described in Real-Time Performance Monitoring , the Real-Time Performance Monitoring timers are more accurate when hardware timestamps are used than software timers (the default setting).

However, if the hardware timestamps feature is enabled and if the management interface is used as the next-hop interface for a configured "target address," the device that is running Junos OS could continuously generate packets with an unexpected MAC address and fill out the peer device.

For example:

probe RPM-VZM {
    test ICMP-VZM {
        probe-type icmp-ping;
        target address 10.24.20.1;
        test-interval 1;
        hardware-timestamp;
    }
}

{MASTER}[edit]
root@MX# run show route 10.24.20.1 

inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 13:23:16
                    >  to 10.52.100.1 via fxp0.0

With a configuration similar to the above, several packets with unexpected MAC addresses could be sent to the peer device to which the management interface is connected. The number of unexpected MAC addresses with the format 00:00:40:01:xx:xx could reach 10K+ and fill out the MAC table of the peer device.

labroot@EX4300> show ethernet-switching table vlan-id 1000    
Jul 10 08:34:18

MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
           SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)


Ethernet switching table : 19335 entries, 19335 learned
Routing instance : default-switch
    Vlan                MAC                 MAC         Age    Logical                NH        RTR 
    name                address             flags              interface              Index     ID
    WIRED_CORP          00:00:40:01:00:02   D             -   ge-1/0/1.0             0         0       
    WIRED_CORP          00:00:40:01:00:05   D             -   ge-1/0/1.0             0         0       
    WIRED_CORP          00:00:40:01:00:09   D             -   ge-1/0/1.0             0         0       
    WIRED_CORP          00:00:40:01:00:0c   D             -   ge-1/0/1.0             0         0       
    WIRED_CORP          00:00:40:01:00:0f   D             -   ge-1/0/1.0             0         0 
<truncated>

The issue is caused by unexpected packets being sent out from the management interface because the interface does not support "hardware timestamping." For line cards that support "hardware timestamping", refer to Configuring RPM Timestamping on MX, M, T, and PTX Series Routers and EX Series Switches .

On MX Series routers, M320 Series routers that use the Enhanced Queuing MPC, MX10000 Series routers, PTX5000, PTX10008, and PTX10016 routers, and on EX Series switches, you can include the  hardware-timestamp  statement at the  [edit services rpm probe probe-name test test-name]  hierarchy level to specify that the probes are to be timestamped in the Packet Forwarding Engine (PFE) host processor.

On MX Series routers, hardware timestamping is supported on the following line cards:

• DPC

• DPCE

• MPC1

• MPC2

• MPC3

• MPC4

• MPC5

• MPC6

• MPC7

When the next-hop for "target address" is configured in RPM through a management interface, only a software timer can be used.

In this case, delete the " hardware-timestamp " option from the RPM configuration stanza to resolve the problem.