[Note that I've already inquired internally about the original problem. I don't recall the answer from top of head and don't have time for code spelunking...]
As to the point below, we get to these headaches one commit at a time. Junos is long-lived enough that VRFs started as a hack on a system that didn't have them. A completely new system written from scratch likely would just assume arbitrary tables that can be spaghetti configured into whatever you want to do with them. When I was first studying the Juniper implementation of L3VPN VRFs, some of the rib-group constructs didn’t make a lot of sense to me. It was rather clearer after discovering that when the features were released in the 9.x (?) releases that all of the niceties we have today used to be completely done at a manual level with those same rib-groups. __ While I have a lot of sympathy for Saku's pragmatism, I prefer to file off the ugly edges of old justifications when I can... but it's done one commit at a time. -- Jeff On 6/5/23, 3:47 AM, "juniper-nsp on behalf of Saku Ytti via juniper-nsp" <juniper-nsp-boun...@puck.nether.net <mailto:juniper-nsp-boun...@puck.nether.net> on behalf of juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net>> wrote: I consider it a design error that NOS conceptually has two types of instances, main instance and VRF instance. This distinction makes it more expensive to write and maintain the NOS and it makes it more fragile. Juniper Business Use Only _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
