Zayo Belle Plaine - April 15th
Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now. From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace. Best of luck everyone, Anthony
I experienced the same and will open a ticket as well. thanks for the update! On Thu, Apr 15, 2021 at 18:04 AnthonyAnderberg@nuvera.net < AnthonyAnderberg@nuvera.net> wrote:
Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now.
From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace.
Best of luck everyone,
Anthony
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of AnthonyAnderberg@nuvera.net Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now. From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace. Best of luck everyone, Anthony ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
Frank, Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of AnthonyAnderberg@nuvera.net Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now.
From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace.
Best of luck everyone, Anthony 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
Is there anything configured on the MICE core switches to police/drop unknown unicast? I saw mention on the MICE technical page of 100mbps limit of unknown unicast, seems like maybe that could be more aggressive (or at a minimum, on route server ports and/or interfaces facing the Juniper?)
On Apr 15, 2021, at 10:52 PM, Jeremy Lumby <jlumby@MNVOIP.COM> wrote:
Frank,
Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation.
Jeremy
From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th
We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened?
Frank
From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of AnthonyAnderberg@nuvera.net <mailto:AnthonyAnderberg@nuvera.net> Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET <mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th
Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now.
From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace.
Best of luck everyone, Anthony
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <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 <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 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>
Right now it is setup for broadcast, and multicast, however I am in favor of adding unknown unicast. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Friday, April 16, 2021 12:38 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Is there anything configured on the MICE core switches to police/drop unknown unicast? I saw mention on the MICE technical page of 100mbps limit of unknown unicast, seems like maybe that could be more aggressive (or at a minimum, on route server ports and/or interfaces facing the Juniper?) On Apr 15, 2021, at 10:52 PM, Jeremy Lumby <jlumby@MNVOIP.COM> wrote: Frank, Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of AnthonyAnderberg@nuvera.net Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now.
From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace.
Best of luck everyone, Anthony 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 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
If the MICE’s technical page documented limiting unknown unicast to 100 Mbps, shouldn’t its gear be set up that way? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Friday, April 16, 2021 7:52 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Right now it is setup for broadcast, and multicast, however I am in favor of adding unknown unicast. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Friday, April 16, 2021 12:38 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Is there anything configured on the MICE core switches to police/drop unknown unicast? I saw mention on the MICE technical page of 100mbps limit of unknown unicast, seems like maybe that could be more aggressive (or at a minimum, on route server ports and/or interfaces facing the Juniper?) On Apr 15, 2021, at 10:52 PM, Jeremy Lumby <jlumby@MNVOIP.COM<mailto:jlumby@MNVOIP.COM>> wrote: Frank, Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of AnthonyAnderberg@nuvera.net<mailto:AnthonyAnderberg@nuvera.net> Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now. From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace. Best of luck everyone, Anthony ________________________________ 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 ________________________________ 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 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
It is interesting that it is stated in the text, but not shown in the sample port config. I think it probably got missed when migrating from the Juniper core. I can correct it. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Friday, April 16, 2021 4:45 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th If the MICE’s technical page documented limiting unknown unicast to 100 Mbps, shouldn’t its gear be set up that way? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Friday, April 16, 2021 7:52 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Right now it is setup for broadcast, and multicast, however I am in favor of adding unknown unicast. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Friday, April 16, 2021 12:38 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Is there anything configured on the MICE core switches to police/drop unknown unicast? I saw mention on the MICE technical page of 100mbps limit of unknown unicast, seems like maybe that could be more aggressive (or at a minimum, on route server ports and/or interfaces facing the Juniper?) On Apr 15, 2021, at 10:52 PM, Jeremy Lumby <jlumby@MNVOIP.COM> wrote: Frank, Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of AnthonyAnderberg@nuvera.net Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now.
From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace.
Best of luck everyone, Anthony 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 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 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
In this case it was BFD that kicked in – I have BFD only set up for the two route reflectors. Other BGP sessions stayed up. I also got this alert from our Arista 7504: 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) Is Arista falling bit short in this situation, by not supporting 10 msec? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Thursday, April 15, 2021 10:52 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Frank, Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of AnthonyAnderberg@nuvera.net<mailto:AnthonyAnderberg@nuvera.net> Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now. From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace. Best of luck everyone, Anthony ________________________________ 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 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
We saw another BFD event at 2:04 pm today – was there a disturbance in the force? 😉 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? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> Sent: Friday, April 16, 2021 4:43 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [External GPC] Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th In this case it was BFD that kicked in – I have BFD only set up for the two route reflectors. Other BGP sessions stayed up. I also got this alert from our Arista 7504: 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) Is Arista falling bit short in this situation, by not supporting 10 msec? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of Jeremy Lumby Sent: Thursday, April 15, 2021 10:52 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Frank, Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of AnthonyAnderberg@nuvera.net<mailto:AnthonyAnderberg@nuvera.net> Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now. From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace. Best of luck everyone, Anthony ________________________________ 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 ________________________________ 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
Frank, I have been gradually implementing the unknown unicast rate limiting (starting with my own extension) to make sure it does not cause any unexpected problems. I had not applied it to the route servers yet, so I can understand why you saw another blip when a member with a significant amount of traffic had their port go down unexpectedly today. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Wednesday, April 21, 2021 3:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We saw another BFD event at 2:04 pm today – was there a disturbance in the force? 😉 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? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> Sent: Friday, April 16, 2021 4:43 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [External GPC] Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th In this case it was BFD that kicked in – I have BFD only set up for the two route reflectors. Other BGP sessions stayed up. I also got this alert from our Arista 7504: 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) Is Arista falling bit short in this situation, by not supporting 10 msec? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Thursday, April 15, 2021 10:52 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Frank, Ideally it should not have, however what tends to happen is that when large ports go down the MAC addresses leave the table, and therefore the traffic gets flooded to all ports until BGP times out on the networks sending the traffic. Since the route servers only have 1G ports, the 10G of traffic that typically is flowing to Belle Plaine probably saturated the route server ports for a short amount of time. If you have short timeouts, or use something more sensitive like BFD I could see how your sessions dropped from the saturation. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, April 15, 2021 9:40 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th We (AS18883) saw our BGP sessions with the MICE router reflectors bounce at that time – should that have happened? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of AnthonyAnderberg@nuvera.net Sent: Thursday, April 15, 2021 6:05 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Zayo Belle Plaine - April 15th Looks like the Zayo Belle Plaine remote went down at 5:37pm, I believe Lee @ SW MN Broadband is opening a ticket now.
From the MICE side we have light but no frames, and looking at other unrelated systems it appears the cut is South of Hwy 212 someplace.
Best of luck everyone, Anthony 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 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 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
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. -- Richard
On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <rlaager@wiktel.com> 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. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
On Apr 21, 2021, at 5:52 PM, David Farmer <0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET> wrote:
On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <rlaager@wiktel.com <mailto:rlaager@wiktel.com>> 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 hoyosa@gmail.com <mailto:hoyosa@gmail.com>
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 ben.wiechman@arvig.com 150 Second Street SW | Perham, MN 56573 | arvig.com On Wed, Apr 21, 2021, 17:57 Andrew Hoyos <hoyosa@gmail.com> wrote:
On Apr 21, 2021, at 5:52 PM, David Farmer < 0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET> wrote:
On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <rlaager@wiktel.com> 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 hoyosa@gmail.com
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
So can we change the route reflectors to use 50 msec? Frank From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Ben Wiechman Sent: Wednesday, April 21, 2021 8:47 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 ben.wiechman@arvig.com<mailto:ben.wiechman@arvig.com> 150 Second Street SW | Perham, MN 56573 | arvig.com<http://arvig.com> On Wed, Apr 21, 2021, 17:57 Andrew Hoyos <hoyosa@gmail.com<mailto:hoyosa@gmail.com>> wrote: On Apr 21, 2021, at 5:52 PM, David Farmer <0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET<mailto:0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET>> wrote: On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <rlaager@wiktel.com<mailto:rlaager@wiktel.com>> 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 hoyosa@gmail.com<mailto:hoyosa@gmail.com> ________________________________ 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
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 <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Ben Wiechman Sent: Wednesday, April 21, 2021 8:47 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 ben.wiechman@arvig.com<mailto:ben.wiechman@arvig.com> 150 Second Street SW | Perham, MN 56573 | arvig.com<http://arvig.com>
On Wed, Apr 21, 2021, 17:57 Andrew Hoyos <hoyosa@gmail.com<mailto:hoyosa@gmail.com>> wrote: On Apr 21, 2021, at 5:52 PM, David Farmer <0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET<mailto:0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET>> wrote:
On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <rlaager@wiktel.com<mailto:rlaager@wiktel.com>> 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 hoyosa@gmail.com<mailto:hoyosa@gmail.com>
________________________________
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
On 4/27/21 12:01 AM, Doug McIntyre wrote:
So, you're looking to lower it from 500ms down to 50ms when most of the recomendations are a bottom limit of 150ms?
That raises a good point. BFD negotiates the /higher/ of the two configured timeouts. So even if Frank has his set crazy low, if the route servers have a minimum of 500 ms, that's what they'll end up using. Frank, can you check "show bfd neighbor detail" or similar on your router? Are you negotiating 500 ms timeouts with the route servers? That would make the detection time 1500 ms (1.5s), which might suggest we're on the wrong track with the low timeouts causing the bouncing. (Or, maybe it still is that, meaning the disruption lasted long enough?) -- Richard
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 <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Tuesday, April 27, 2021 12:01 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Ben Wiechman Sent: Wednesday, April 21, 2021 8:47 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 ben.wiechman@arvig.com<mailto:ben.wiechman@arvig.com> 150 Second Street SW | Perham, MN 56573 | arvig.com<http://arvig.com>
On Wed, Apr 21, 2021, 17:57 Andrew Hoyos <hoyosa@gmail.com<mailto:hoyosa@gmail.com>> wrote: On Apr 21, 2021, at 5:52 PM, David Farmer <0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET<mailto:0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET>> wrote:
On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <rlaager@wiktel.com<mailto:rlaager@wiktel.com>> 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 hoyosa@gmail.com<mailto:hoyosa@gmail.com>
________________________________
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
micemn-01 protocol bfd { interface "bce1" { interval 500 ms; multiplier 3; passive; }; } micemn-02 protocol bfd { interface "bce1" { interval 500 ms; multiplier 3; passive; }; } On Tue, Apr 27, 2021 at 01:28:13PM +0000, Frank Bulk wrote:
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 <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Tuesday, April 27, 2021 12:01 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Ben Wiechman Sent: Wednesday, April 21, 2021 8:47 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 ben.wiechman@arvig.com<mailto:ben.wiechman@arvig.com> 150 Second Street SW | Perham, MN 56573 | arvig.com<http://arvig.com>
On Wed, Apr 21, 2021, 17:57 Andrew Hoyos <hoyosa@gmail.com<mailto:hoyosa@gmail.com>> wrote: On Apr 21, 2021, at 5:52 PM, David Farmer <0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET<mailto:0000000e7948cb21-dmarc-request@LISTS.IPHOUSE.NET>> wrote:
On Wed, Apr 21, 2021 at 5:36 PM Richard Laager <rlaager@wiktel.com<mailto:rlaager@wiktel.com>> 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 hoyosa@gmail.com<mailto:hoyosa@gmail.com>
________________________________
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
I am also getting 10ms as the received value from 206.108.255.2 and 2001:504:27::d1af:0:2. I do get the expected 500ms from .1 and :1. -- Richard
I have always wondered why there was more traffic leaving RS2, and this would support that. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Tuesday, April 27, 2021 12:00 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Zayo Belle Plaine - April 15th I am also getting 10ms as the received value from 206.108.255.2 and 2001:504:27::d1af:0:2. I do get the expected 500ms from .1 and :1. -- Richard To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
participants (9)
-
Andrew Hoyos -
AnthonyAnderberg＠nuvera.net -
Ben Wiechman -
David Farmer -
Doug McIntyre -
Frank Bulk -
James Urwiller -
Jeremy Lumby -
Richard Laager