Aren't the two log lines indicating that our router saw the next hop from the MICE RR's? Can the RR's be configured to filter out "bad" addresses? Frank -----Original Message----- From: MICE Discuss <[log in to unmask]> On Behalf Of Doug McIntyre Sent: Friday, February 08, 2019 3:55 PM To: [log in to unmask] Subject: Re: [MICE-DISCUSS] Strange log message on our Arista regarding MICE traffic On Fri, Feb 08, 2019 at 02:55:08PM -0600, Richard Laager wrote: >On 2/8/19 2:30 PM, Frank Bulk wrote: >> I saw the following Thursday afternoon: >> >> Feb 7 15:21:54 207.32.15.28 Rib: mpbgp_recv_mpreach: peer 2001:504:27::d1af:0:1 (AS 53679) link-local next hop fe80::e2ac:f1ef:fe4b:d93b%10000 improper, ignoring this next-hop >> Feb 7 15:22:09 207.32.15.28 Rib: mpbgp_recv_mpreach: peer 2001:504:27::d1af:0:2 (AS 53679) link-local next hop fe80::e2ac:f1ef:fe4b:d93b%10000 improper, ignoring this next-hop > >That link local address seems to (other than a 2 vs 0) match MAC address >e0ac.f14b.d93b, which is currently in my ARP cache for 206.108.255.119, >which is Paul Bunyan Telephone. I wonder if their router advertised a >link local nexthop to the route servers. If Frank is setting the packet on his router from fe80::e2ac:f1ef:fe4b:d39b, it probably came directly across the wire, not bounced off the route-reflectors, which would add in their own link-local address. >Perhaps the route servers should be filtering the next hop? At a >minimum, it seems like we should limit it to the MICE address space. But >if trivial to implement, it would be best if the nexthop was that of the >peer. They do have some filtering. The next-hop for anything coming in should be the peer address already? In this case, it looks like some freaky BGP went out, and Frank's router ignored it. -- Doug McIntyre <[log in to unmask]> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades