Strange log message on our Arista regarding MICE traffic
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 Was someone working on the router reflectors? Frank
On Fri, Feb 08, 2019 at 08:30:04PM +0000, 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
Was someone working on the router reflectors?
No, nobody was logged into them on 2/7/2018 at all. -- Doug McIntyre <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
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. 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. -- Richard
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
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 <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Friday, February 08, 2019 3:55 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <merlyn@iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades
participants (4)
-
Doug McIntyre -
Frank Bulk -
Richard Laager -
Steve Howard