> On Sep 22, 2020, at 4:46 AM, Andy Davidson wrote:
>
> Hi,
>
> Douglas Fisher wrote:
>> B) There is any other alternative to that?
>
> Don't connect to IXPs with very very large and complicated topologies.
> Connect to local IXPs where the design makes a forwarding plane failure that
> ca
Hi,
Douglas Fisher wrote:
> B) There is any other alternative to that?
Don't connect to IXPs with very very large and complicated topologies. Connect
to local IXPs where the design makes a forwarding plane failure that causes the
problem you describe less likely.
Andy
Hello
ARP timeout should be lower than MAC timeout, but usually the default is
the other way around. Which is extremely stupid. To those who do not know
why, let me give a simple example:
Router R1 is connected to switch SW1 with a connection to server SRV: R1
<-> SW1 <-> SRV
Router R2 is connect
> a) Check if there is anything hindering the evolution of this draft to
> an RFC.
was i unclear?
> the draft passed wglc in 1948. it is awaiting two
> implementations, as is the wont of the idr wg.
randy
On 9/17/20 1:51 PM, Douglas Fischer wrote:
But 30 Seconds for an IXP? It does not make any sense!
Those packets are stealing CPU cycles of the Control Plane of any
router in the LAN.
Especially given how some exchanges lock the mac address of
participants. You could probably get away with ARP
If you look just to the normal situations...
1.2K vs 576K may not represent very much.
But if you look tho ARP Requests Graphs on a significative topology
changing on a big IXP, and also look to CPU-per-process graphs, maybe what
I'm suggesting could be more explicit.
I'm talking of good boxes fr
On Thu, 17 Sep 2020 at 20:51, Douglas Fischer wrote:
> Why should we spend CPU Cycles with 576K ARP Requests a day(2K participants,
> 5 min ARP-Timeout).
> Instead of 1.2K ARP Requests a day(2K participants, 4 hours ARP-Timeout)?
> I would prefer to use those CPU cycles to process other things l
Well...
My idea with the initial mail was:
a) Check if there is anything hindering the evolution of this draft to an
RFC.
b) Bet in try to make possible a thing that nowadays could be considered
impossible, like:
"How to enable the BFD capability on a route-server with 2000 BGP
Sessions withou
About this comparison between CAM-Table Timeout, and ARP-Table Timeout.
I tend to partially agree with you...
Ethernet is a so widely used protocol to sever scenarios.
We need to consider the different needs of the type of communications.
For example:
I'm not a big fan of Mikrotik/RouterOS.
But
>
> If the traffic is that important then the public internet is the wrong
> way to transport it.
Nonsense.
It is usually something said by those who do not know how to use Internet
as a transport in a reliable way between two endpoints.
In your books what is Internet good for ? Torrent and por
Am Mi., 16. Sept. 2020 um 02:57 Uhr schrieb Douglas Fischer
:
>
> Time-to-time, in some IXP in the world some issue on the forwarding plane
> occurs.
> When it occurs, this topic comes back.
>
> The failures are not big enough to drop the BGP sessions between IXP
> participants and route-servers.
On Wed, 16 Sep 2020 at 23:15, Chriztoffer Hansen
wrote:
> On 16/09/2020 04:01, Ryan Hamel wrote:
> > CoPP is always important, and it's not just Mikrotik's with default low
> > ARP timeouts.
> >
> > Linux - 1 minute
> > Brocade - 10 minutes
> > Cumulus - 18 minutes
> > BSD distros - 20 minutes
>
On Wed, Sep 16, 2020 at 4:55 PM Randy Bush wrote:
>
> >>> So, I was searching on how to solve that and I found a draft (8th release)
> >>> with the intention to solve that...
> >>> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
> >>>
> >>> If understood correctly, the effective implementatio
>>> So, I was searching on how to solve that and I found a draft (8th release)
>>> with the intention to solve that...
>>> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
>>>
>>> If understood correctly, the effective implementation of it will depend on
>>> new code on any BGP engine that will
On Tue, Sep 15, 2020 at 9:40 PM Randy Bush wrote:
>
> > So, I was searching on how to solve that and I found a draft (8th release)
> > with the intention to solve that...
> > https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
> >
> > If understood correctly, the effective implementation of it wi
Ryan Hamel wrote on 16/09/2020 03:01:
Install a route optimizer that constantly pings next hops
or if you want a more reliable IXP experience, don't install a route
optimiser and if you do, don't make it ping next-hops.
- you're not guaranteed that the icmp reply back to the route optimiser
Hi,
In some IXPs, getting a BFD protected BGP sessions with their
route-servers is possible. However, it is usualy optional, so there is
no way how to discover know who of your MLPA peering partners has their
sessions protected the same way and who don't.
You can also ask peers you have a session
> "How can I check if my communication against the NextHop of the routes that I
> learn from the route-servers are OK? If it is not OK, how can I remove it
> from my FIB?"
Install a route optimizer that constantly pings next hops, when the drop
threshold is met, remove the routes. No one is goi
> So, I was searching on how to solve that and I found a draft (8th release)
> with the intention to solve that...
> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
>
> If understood correctly, the effective implementation of it will depend on
> new code on any BGP engine that will want to do
19 matches
Mail list logo
