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 <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades