Re: [j-nsp] Network automation vs. manual config
Hi, > On 18/08/2018, at 1:06 AM, Michael Still wrote: > > Side note on apply groups and display inheritance. I've submitted a Juniper > ER for an enhancement to have the ability to have ' | display inheritance' > a 'default' cli behavior (configurable via 'set cli display-inheritance' > option that is defaulted to off). I've also asked for a login-class option > to enable this for specific user role such as front line NOC users who may > benefit from having it on by default. This is ER-077163 if you want to poke > your Juniper SE about it. Interesting. Personally I’d probably not make use of this - part of the intention of using groups, for me, is to keep the config succinct, and make it very clear when something is done outside a group - it’s either non-standard, or it’s config that’s only relevant here (i.e. IP addressing). Perhaps it would work if it marked up the config in some way that indicated it was inherited — I.e. in a way that isn’t the 3 or so lines of `## blah` stuff, which makes the config difficult to read. What about commit-scripts, and apply-flags omit? You’d need to have those included as well. I would be interested in a way to build a command alias with `| display inheritance | display commit-scripts | display omit | exclude #` or something - `exclude #` isn’t the best either, as # is often in int description etc. Perhaps an opscript or something. `show functional-configuration` Perhaps that could be a better feature (`show configuration functional` maybe), than the one you’ve proposed? I’d support that. I’d still want a way to indicate something is from a commit script or is normally omitted or what not - perhaps first char of the line could have > or * or some other markup. > The reason I've asked for this is specifically because I've seen NOC > personnel spend many cycles investigating an issue not realizing that > particular hidden apply-group config was affecting their investigation. We have so much stuff in groups that it’s almost impossible to know it’s not there. Groups first - only local config (IPs etc.) goes outside groups. > I have a couple other semi-related (to automation / configuration > enhancement) ER's going if folks are interested and would like to chat > about those directly. Would love to hear about them, maybe we can collaborate from different view points. -- Nathan Ward ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] L3VPN/RR/PE on Same router
> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Saturday, August 18, 2018 12:15 PM > > On Sat, 18 Aug 2018 at 14:02, wrote: > > > Really? Interesting, didn't know that, are these features documented > anywhere? I could not find anything looking for multi instance RPD. > > Are the RPD instances as ships in night, each maintaining its own set of > tables and protocols? > > Yes. It's old old feature: > > https://www.juniper.net/documentation/en_US/junos/topics/concept/logi > cal-systems-overview-solutions.html > > The ability to run multiple FreeBSD KVM on Linux guest is very new. It also > allows you to connect the separate instances via virtual fabric interface, so > you don't need to eat physical interface to connect the separate instances. > This is really 100% separate JunOS, they only share the Linux hypervisor from > software POV. > > https://www.juniper.net/documentation/en_US/junos/information- > products/pathway-pages/junos-node-slicing/junos-node-slicing.html > > Use case might be buy 128GB RE, collapse edge + pure-core without having > hardware. > Or Megaport on steroids, drop Calient optical switch in pops and MX, have > customers build via API their entire global backbone in seconds, with active > devices and optical network to connect them. > Aah these two! I feel embarrassed now haha :) I actually have high hopes for the node-slicing thing -in particular the ability to run CP externally on x86 based COTS HW, hopefully it will get adopted by all the vendors soon (and if the API between CP and DP gets standardized well be living in an SDN utopia). I'm actually having this "architect personality crises" cause I can't make up my mind between centralizing and decentralizing on the PE edge i.e. whether to have couple big monolithic chassis to fit/scale for all service types (thus scale up/vertically) or rather decentralize and create many smaller maybe even specialized node types and scale by adding more types or more of the same from each type (thus scale out/horizontally). And I'm very aware of this whole industry swinging back and forth between the two extremes over the years. There is a finite limit to how much CP state can one fit onto these huge monolithic chassis you can have a big N slot chassis full even though there are just a few line-cards in it, just because you ran out of CP resources because of too many routes/VRFs/BGP sessions. (this problem gets even more pronounced with multi-chassis systems). This is the problem we're facing currently. I mean this idea of additional CP HW is not new, it's been around since juniper T Matrix and cisco CRS1. CRS1 -introducing Distributed Route Processors (DRPs) onto which one could offload say an instance of additional BGP process (but one could have just one additional per main system or just two DRPs per SDR). Another example from past was the T Matrix with JCS1200 so you could have separate CP for each logical system (but again one could have just two REs per logical system). And then with the advent of MX and ASR9k -we kind of lost the ability to scale out CP. So I really welcome this flexibility of being able to scale CP up (assigning more CPUs to the CP VM) or scale CP out (more CP VMs), while maintaining single monolithic DP. This would help me address one of the biggest drawbacks of decentralization (many smaller PEs) -that is separate cooling/power/chassis for each PE -really eats up rack space and is power inefficient. On the other hand I'm mindful of added complexity in terms of maintaining resiliency in this external CP environment. Biggest problem is though that this node-slicing/external x86 based CP is very fresh and I'm not aware of same thing available in cisco or other vendors and unfortunately I need to provide solutions now, adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] L3VPN/RR/PE on Same router
On Sat, 18 Aug 2018 at 14:02, wrote: > Really? Interesting, didn't know that, are these features documented > anywhere? I could not find anything looking for multi instance RPD. > Are the RPD instances as ships in night, each maintaining its own set of > tables and protocols? Yes. It's old old feature: https://www.juniper.net/documentation/en_US/junos/topics/concept/logical-systems-overview-solutions.html The ability to run multiple FreeBSD KVM on Linux guest is very new. It also allows you to connect the separate instances via virtual fabric interface, so you don't need to eat physical interface to connect the separate instances. This is really 100% separate JunOS, they only share the Linux hypervisor from software POV. https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-node-slicing/junos-node-slicing.html Use case might be buy 128GB RE, collapse edge + pure-core without having hardware. Or Megaport on steroids, drop Calient optical switch in pops and MX, have customers build via API their entire global backbone in seconds, with active devices and optical network to connect them. > Yeah all the costs are in edge devices, even core routers HW is order of > magnitude more expensive than that of RRs Depends, for access networks, 5 year costs tend to be dominated on MRC's on the backhauls. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] L3VPN/RR/PE on Same router
> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Saturday, August 18, 2018 11:44 AM > > On Fri, 17 Aug 2018 at 16:40, wrote: > > > Another alternative would be to spin up a separate BGP process, which I > think is supported only in XR, but once again that somewhat places one on > the outskirts of the common deployment graph. > > But I know Mark is using csr1k -so depending on the available NFVI > resources (I guess dedicated servers in this case), I think it's not that > onerous > to spin up yet another VM right? > > I think many vendors support this. JunOS supports multiple RPD instances in > single FreeBSD instance and multiple FreeBSD instances in single Linux > instance. > Really? Interesting, didn't know that, are these features documented anywhere? I could not find anything looking for multi instance RPD. Are the RPD instances as ships in night, each maintaining its own set of tables and protocols? > Personally I'd run the RRs for different AFIs in separate hardware, because > RR hardware is not really where the costs are. > Yeah all the costs are in edge devices, even core routers HW is order of magnitude more expensive than that of RRs adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] L3VPN/RR/PE on Same router
On Fri, 17 Aug 2018 at 16:40, wrote: > Another alternative would be to spin up a separate BGP process, which I think > is supported only in XR, but once again that somewhat places one on the > outskirts of the common deployment graph. > But I know Mark is using csr1k -so depending on the available NFVI resources > (I guess dedicated servers in this case), I think it's not that onerous to > spin up yet another VM right? I think many vendors support this. JunOS supports multiple RPD instances in single FreeBSD instance and multiple FreeBSD instances in single Linux instance. Personally I'd run the RRs for different AFIs in separate hardware, because RR hardware is not really where the costs are. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN/RR/PE on Same router
On 17/Aug/18 15:39, adamv0...@netconsultings.com wrote: > Another alternative would be to spin up a separate BGP process, which I think > is supported only in XR, but once again that somewhat places one on the > outskirts of the common deployment graph. > But I know Mark is using csr1k -so depending on the available NFVI resources > (I guess dedicated servers in this case), I think it's not that onerous to > spin up yet another VM right? Turning another one up? Not a problem at all. The issue is in operating more than you need to. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
