Are both MICE route reflectors configure to be 500 msec as of this moment? It appears that RR#2 is configured differently.
Our router is stating that RR#2's Received RxInt is 10 msec:
Apr 15 17:37:34 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) Bfd: %BFD-5-INCOMPATIBLE_RX_INTERVAL: Received a BFD rx interval from peer (vrf:default, ip:206.108.255.2 (AS53679-MRS-2.micemn.net), intf:Port-Channel2, srcIp:0.0.0.0, type:normal) of 10 milliseconds, outside of the supported range of 50-60000 milliseconds. (message repeated 3 times in 1.18783e+06 secs)
SiouxCity-Fibernet-Arista(s2)#show bfd neighbors interface port-Channel 2 detail
VRF name: default
-----------------
Peer Addr 206.108.255.1, Intf Port-Channel2, Type normal, State Up
VRF default, LAddr 206.108.255.133, LD/RD 3460049634/334592880
Session state is Up and not using echo function
Last Up Apr 24 12:11:36 2021
Last Down Apr 24 12:11:33 2021
Last Diag: No Diagnostic
TxInt: 500, RxInt: 500, Multiplier: 3
Received RxInt: 500, Received Multiplier: 3
Rx Count: 595169, Rx Interval (ms) min/max/avg: 340/482/412 last: 632 ms ago
Tx Count: 566334, Tx Interval (ms) min/max/avg: 371/496/433 last: 632 ms ago
Detect Time: 1500
Sched Delay: 1*TxInt: 20967555, 2*TxInt: 4570, 3*TxInt: 0, GT 3*TxInt: 0
Registered protocols: bgp
Uptime: 2 days, 20:11:34.74
Last packet: Version: 1 - Diagnostic: 0
State bit: Up - Demand bit: 0
Poll bit: 0 - Final bit: 0
Multiplier: 3 - Length: 24
My Discr.: 334592880 - Your Discr.: 3460049634
Min tx interval: 500 - Min rx interval: 500
Min Echo interval: 0
Peer Addr 206.108.255.2, Intf Port-Channel2, Type normal, State Up
VRF default, LAddr 206.108.255.133, LD/RD 301505937/1393863972
Session state is Up and not using echo function
Last Up Apr 24 12:11:37 2021
Last Down Apr 24 12:11:33 2021
Last Diag: No Diagnostic
TxInt: 300, RxInt: 300, Multiplier: 3
Received RxInt: 10, Received Multiplier: 5
Rx Count: 991837, Rx Interval (ms) min/max/avg: 194/480/247 last: 634 ms ago
Tx Count: 949660, Tx Interval (ms) min/max/avg: 219/296/258 last: 634 ms ago
Detect Time: 1500
Sched Delay: 1*TxInt: 35149798, 2*TxInt: 13194, 3*TxInt: 0, GT 3*TxInt: 0
Registered protocols: bgp
Uptime: 2 days, 20:11:34.27
Last packet: Version: 1 - Diagnostic: 0
State bit: Up - Demand bit: 0
Poll bit: 0 - Final bit: 0
Multiplier: 5 - Length: 24
My Discr.: 1393863972 - Your Discr.: 301505937
Min tx interval: 100 - Min rx interval: 10
Min Echo interval: 0
SiouxCity-Fibernet-Arista(s2)#
Frank
-----Original Message-----
From: MICE Discuss <[log in to unmask]> On Behalf Of Doug McIntyre
Sent: Tuesday, April 27, 2021 12:01 AM
To: [log in to unmask]
Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th
So, you're looking to lower it from 500ms down to 50ms when most of
the recomendations are a bottom limit of 150ms?
On Tue, Apr 27, 2021 at 02:37:52AM +0000, Frank Bulk wrote:
>So can we change the route reflectors to use 50 msec?
>
>Frank
>
>From: MICE Discuss <[log in to unmask]> On Behalf Of Ben Wiechman
>Sent: Wednesday, April 21, 2021 8:47 PM
>To: [log in to unmask]
>Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th
>
>IOS-XR bottoms out at 15ms. IOS/XE has typically been 150ms.
>
>Agreed that in general unless you have <50ms failover requirements 150ms+ is probably a good compromise.
>
>Ben Wiechman
>Director of IP Strategy and Engineering
>Direct: 320.256.0184
>Cell: 320.247.3224
>[log in to unmask]
>150 Second Street SW | Perham, MN 56573 | arvig.com
>
>On Wed, Apr 21, 2021, 17:57 Andrew Hoyos <[log in to unmask]> wrote:
>On Apr 21, 2021, at 5:52 PM, David Farmer <[log in to unmask]> wrote:
>
>On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <[log in to unmask]> wrote:
>On 4/21/21 3:04 PM, Frank Bulk wrote:
>> And to follow up on my previous question, is Arista falling bit short in
>> our situation, by not supporting a receive interval of 10 msec?
>
>I've had a couple vendors suggest not to make it that short. Brocade,
>for example, suggested 150 ms as a minimum. Arista was more vague, but
>from your error message, apparently their implementation doesn't even
>try to do less than 50 ms.
>
>Maybe think about this from another perspective, 10 ms is 100 times a second, 50 ms is 20 times a second, and 150 ms just over 6 times a second. I think 10 ms is probably being a little impatient.
>
>Not the mention, the added CPU load on both ends dealing with said BFD packets 100x/sec.
>
>We’ve generally seen 50-250ms used in practice. 10ms does seem super aggressive. We use 250ms x 3 here for backbone links and peers/transit that support BFD, and 750ms x 3 facing internal gear.
>
>
>—
>Andrew Hoyos
>[log in to unmask]
>
>
>
>
>________________________________
>
>To unsubscribe from the MICE-DISCUSS list, click the following link:
>http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
>
>________________________________
>
>To unsubscribe from the MICE-DISCUSS list, click the following link:
>http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
