Hey, > 2 possibilities come to mind: > > - Create a BGP group for each different set of parameter combinations and > have the commit script set parameters for the neighbor based on what group > they are in. > or, > - Come up with a standard convention for defining the neighbor description, > such that the parameters could be encoded into the description. The commit > script could then set parameters based on the values in the appropriate > positions within the description. > > Both of these seem somewhat complex, but perhaps only because they are > unfamiliar. Are there other ways of doing this that might prove to be (more) > effective?
My recommendation is to minimally rely on vendor tooling, generate entire configuration offline and you have same tooling, same logic available to every current and future platform, making changing vendor much OPEX friendlier process. The issue what you explain is real, and you can dig yourself to similar hole going to opposite way from JunOS to IOS-XR, by relying heavily on apply-groups and apply-paths (IOS-XR groups are inferior and cannot express same things). I'm sure similarly we can see any V1=>V2 transition being complicated and expensive when we heavily commit on V1 specific tooling. Not the answer you probably wanted, but I think network engineers really need to start embracing less CLI-jockey and more centralised logic. -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
