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
