[a-nsp] tracked static routes in EOS

[Drew Weaver]

Right but none of that is built into EOS correct?

That was what the post was mostly about.

Whether they had ever gone back and corrected the omission?

Thanks,
-Drew


From: Tyler Conrad <Tyler at tgconrad.com>
Sent: Friday, September 11, 2026 1:25 PM
To: Drew Weaver <drew.weaver at thenap.com>
Cc: arista-nsp at puck.nether.net
Subject: Re: [a-nsp] tracked static routes in EOS

Hi Drew,

I've worked on a couple extensions to do this over the years, and there's also a built-in way.

Built-in: Connectivity-monitor with an on-logging event-handler can work for script-less behavior.
PingCheck Extension: https://github.com/arista-eosext/PingCheck<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_arista-2Deosext_PingCheck&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=bPv27DsWHvJOKXO1fg-IGUnqlmv3IzCXU57K_UK6OKd83rMtLkgFxTjUGCICVrCw&s=U1Lbsb6ispBFDPisCYWxAwXksSBjf3cioxLYf8pn-ro&e=> - this one uses a simple ping check.
SynAcktor Extension: https://github.com/etedor/synacktor<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_etedor_synacktor&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=bPv27DsWHvJOKXO1fg-IGUnqlmv3IzCXU57K_UK6OKd83rMtLkgFxTjUGCICVrCw&s=49RFYRbP_3OyShNE6hz-8Ix9XOqpCVFYwaU7o1C8Uc8&e=> - adds flexibility to be able to monitor a tcp service and set an arbitrary next-hop. Useful for monitoring a path without changing the routing table.

Hope this helps,
-T

On Fri, Sep 11, 2026 at 9:03 AM Drew Weaver via arista-nsp <arista-nsp at puck.nether.net<mailto:arista-nsp at puck.nether.net>> wrote:
Howdy

Is it true that there really is no way to do tracked static routes in EOS without installing a python script that you have to reinstall every time the switch reboots?

By tracked static routes I just mean a route that withdrawals when something stops pinging (or another tracking mechanism) would just use BFD but the device on the far end of the L2 network doesn’t support it.

Use case is basically just a L2 network in between the route origin and the destination. if the entire network goes down and the physical link facing the route originating device disappears then the route is withdrawn anyway but if only the portion on the other side of the L2 network goes down then you’re null routing traffic unintentionally.

I’m just wondering.

Thanks,
-Drew

--
arista-nsp mailing list
arista-nsp at puck.nether.net<mailto:arista-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/arista-nsp<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_arista-2Dnsp&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=bPv27DsWHvJOKXO1fg-IGUnqlmv3IzCXU57K_UK6OKd83rMtLkgFxTjUGCICVrCw&s=swn2J_fnMYrd_r3G6EW4ljY7o_Qytb7wfPxQk74pBjE&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/arista-nsp/attachments/20260911/2a08590d/attachment.html>