Comment by deivid
3 days ago
After having used & automated configuration of "traditional" switching/routing devices for years (Cisco , Arista, Juniper), I can't wait for P4 devices to take over
3 days ago
After having used & automated configuration of "traditional" switching/routing devices for years (Cisco , Arista, Juniper), I can't wait for P4 devices to take over
I believe that Arista has (had?) P4 devices in their lineup, but after Intel's sunsetting of that platform, they probably axed them.
You know all those random python automation scripts network engineers use to configure devices? Now imagine them actually running on device controlling packet and frame flows. Does that sound like it would be fun to troubleshoot?
What do you want to use P4 for?
The dream is you never have to rely on buggy vendor software again.
The reality is, you end up with a complex stack with no or homegrown documentation that requires experienced engineers to operate and maintain.
In some environments, that's a perfectly fair trade-off. In most, it isn't.
The APIs these vendors provide are a joke. A bunch of functionality can only be accessed via scripting interactive CLI commands. Some API endpoints cause short downtime / unexpected behavior (eg: by deleting the routing table and adding all entries back 1 by 1), while the on-device commands do not.
And guess what, the switch may decide to print informational or environmental messages interleaved with the command output, because the commands were meant to be run by a human. Good luck knowing if your state-altering command succeeded when you receive broken JSON.
I ended up regex-removing known environmental messages from command outputs..
2 replies →