[j-nsp] ifa generation mismatch

[Brad Fleming]

Responding to my own post in case others stumble across this post in the future. After working with TAC we finally found our root problem.

We had accidentally misconfigured the DSC interface with two IPs. Like so…
unit 0 {
    family inet {
        filter {
            output v4-out-discard;
        }
        address 192.168.192.189/32
        address 192.168.192.190/32 {
            destination 192.168.192.189;
        }
    }
}

The presence of that top address also being the destination for the address below caused a mess. The moment we removed the top address all errant logs stopped and everything on the system went back to normal.

So if you happen to get hit with log entries like those below check very closely your interface address address configurations.

> On Oct 5, 2015, at 10:13 AM, Brad Fleming <bdflemin at gmail.com> wrote:
> 
> Has anyone seen anything like this before?
> 
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: Starting interface state recovery
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-5-RPD_KRT_IFA_GENERATION: ifa generation mismatch -- ifl dsc.0 rpd 130 kernel 132
> <<<hundreds of lines of stuff similar to what’s below>>>
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: Interface state recovery completed.
> 
> Our log file is filling up every 10mins or so with junk messages from RPD similar to this:
> 
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-6: EVENT <MTU> lt-11/2/0 index 249 <Up Broadcast Multicast> address #0 28.8a.1c.c7.c3.69
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-6: EVENT <MTU> lt-11/3/0 index 250 <Up Broadcast Multicast> address #0 28.8a.1c.c7.c3.92
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-6-KRT: Received IPv6 address 2001:db8:1:386::2 on ifl xe-0/3/0.0. Flag:0.
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-6-KRT: Received IPv6 address fe80::2a8a:1cff:fec7:bc7b on ifl xe-0/3/0.0. Flag:0.
> Oct  5 09:49:50  <hostname> rpd[3200]: %DAEMON-6: L2circuit IFF Change: IFL xe-11/2/0.1170 flags 0x0, nbr-id 0.0.0.0 vc-id 0
> 
> I see an old post to this list from RAS from 2004 but that’s about all I can find. We’ve been working with JTAC for about a month trying to figure out what’s going on an it just doesn’t seem there’s going to be a simple answer.
> 
> So far we’ve:
> + Disabled and re-enabled all GRES+NSR/NSB
> + Rebooted both REs ("request system reboot both-routing-engines”)
> + Upgraded software from 13.3R6.5 to 14.2R4.9
> + Removed all interfaces getting logged (roughly 30 IFLs) from the device configuration
> 
> None of these steps have stopped the log messages from piling up. Just kinda hoping some others have seen something similar and might be willing to share what you did to resolve the issue. Thanks in advance for any insights!