Juniper Node Slicing and Universal Chassis
Seeing what’s on top of the stairs somewhere in the middle of it is as difficult as understanding which trends in the telecommunications industry will solidify and become the foundation of future developments, and which will disappear without a trace. Not so long ago, as part of the Cloud-Grade Networking design, Juniper Networks announced the emergence of a new virtualization mechanism for its products, and also introduced the concept of a universal chassis for routing and switching applications. News is important in terms of practical application and interesting as an occasion to tell fortunes about the future.
First, marketers, and then engineers, began to call modern routers multiservice. It is wonderful when one chassis can solve routing tasks at peer-to-peer joints, terminate broadband subscribers, transmit MPLS transit traffic, pull packets from the data center overlay, and even do address and protocol translation. The versatility and reduction of pieces of equipment seems reasonable both to people in suits who are good at counting Capex / Opex, and to people who calculate the rack space and the required UPS capacity, look at monitoring alerts at night, take inventory, configure or maintain this equipment, because one entity is easier to manage than ten. Everything would be fine, but as the number of functions increases, internal contradictions appear between them. Imagine a multi-appliance, which erases, cooks dinner and stores winter tires, due to imperfect software, the dinner may not be tasty, because the ingredients accidentally got a little washing powder, and the tires can be deformed due to the proximity of the oven. In my practice, I worked with clients, routers, which over the life cycle turned into a monolith. It is no longer possible to disassemble it, because “this is our everything”, and it becomes more and more difficult to operate, because one function, again due to non-ideal software, impedes the execution of another. which during the life cycle turned into a monolith. It is no longer possible to disassemble it, because “this is our everything”, and it becomes more and more difficult to operate, because one function, again due to non-ideal software, impedes the execution of another. which during the life cycle turned into a monolith. It is no longer possible to disassemble it, because “this is our everything”, and it becomes more and more difficult to operate, because one function, again due to non-ideal software, impedes the execution of another.
Our IT colleagues have long resolved similar problems for themselves - server administrators are increasingly using virtualization and containers, and developers are actively decomposing entities and writing micro-services. Until recently, network engineers could only afford virtualization, as one friend from Odessa said - virtualization for the poor, in the form of separate routing tables, management contexts, or logical routers. This adds stability and convenience as it shares tasks at least at the process level of the network operating system, but does not solve the problem of monolithicity globally. And finally, Donyel Jones-Williams Director of Service Provider Product Marketing Management from Juniper Networks stated the following - We are doing the same thing for routers that hypervisors did for servers. In my opinion, it turned out even more interesting,
As you can see from the illustration, GNF (guest network function) - an instance of Junos, runs as a separate virtual machine and solely has at its disposal a set of resources placed in FPC slots. Each GNF along with the FPC set is seen from the outside and functions as a completely separate router, while the traffic between GNF can be transmitted through the factory. This approach eliminates internal contradictions between the functions of the router, increases the stability of the system as a whole, and in addition has the “natural” ability to separate administrative management domains between organizational units. Let me give you another illustration, they began to draw them very beautifully.
The imminent appearance of a universal chassis, where interface cards from PTX10008, PTX10016, QFX10008, QFX10016 and MX can be used, and this is what was reported in the Juniper Networks press release, raises only one question - What was it possible? Juniper already has some groundwork in the field of unification, for example, some MX240-MX960 line card concentrators can be used on the top MX2010 and MX2020 for a long time. The current task looks more serious, since in one chassis you need to combine cards designed taking into account the features of work in all segments of the network - data center, core, border. How this is done has not yet been announced, but according to Donyel Jones-Williams, the new platform is already in test operation in the networks of large customers.
So what is the future trying to bring Juniper Networks closer? The manufacturer focuses not only on the equipment, but mixes the emphasis in the direction of management and operating flexibility. According to various estimates, the cost of the final product is only 40% determined by the hardware stuffing, about the same cost is the development of software, integration and automation tools. Let's see what happens and, if possible, we will take part in the development of the industry, because no one knows where the ladder will lead, as Doc Brown said - the future has not yet been written.
The press release and documentation for Junos Node Slicing can be viewed here:
→ Juniper Networks Unveils Cloud Grade Networking to Accelerate Agility and Innovation in the Cloud Era
→ Junos Node Slicing Feature Guide
First, marketers, and then engineers, began to call modern routers multiservice. It is wonderful when one chassis can solve routing tasks at peer-to-peer joints, terminate broadband subscribers, transmit MPLS transit traffic, pull packets from the data center overlay, and even do address and protocol translation. The versatility and reduction of pieces of equipment seems reasonable both to people in suits who are good at counting Capex / Opex, and to people who calculate the rack space and the required UPS capacity, look at monitoring alerts at night, take inventory, configure or maintain this equipment, because one entity is easier to manage than ten. Everything would be fine, but as the number of functions increases, internal contradictions appear between them. Imagine a multi-appliance, which erases, cooks dinner and stores winter tires, due to imperfect software, the dinner may not be tasty, because the ingredients accidentally got a little washing powder, and the tires can be deformed due to the proximity of the oven. In my practice, I worked with clients, routers, which over the life cycle turned into a monolith. It is no longer possible to disassemble it, because “this is our everything”, and it becomes more and more difficult to operate, because one function, again due to non-ideal software, impedes the execution of another. which during the life cycle turned into a monolith. It is no longer possible to disassemble it, because “this is our everything”, and it becomes more and more difficult to operate, because one function, again due to non-ideal software, impedes the execution of another. which during the life cycle turned into a monolith. It is no longer possible to disassemble it, because “this is our everything”, and it becomes more and more difficult to operate, because one function, again due to non-ideal software, impedes the execution of another.
Our IT colleagues have long resolved similar problems for themselves - server administrators are increasingly using virtualization and containers, and developers are actively decomposing entities and writing micro-services. Until recently, network engineers could only afford virtualization, as one friend from Odessa said - virtualization for the poor, in the form of separate routing tables, management contexts, or logical routers. This adds stability and convenience as it shares tasks at least at the process level of the network operating system, but does not solve the problem of monolithicity globally. And finally, Donyel Jones-Williams Director of Service Provider Product Marketing Management from Juniper Networks stated the following - We are doing the same thing for routers that hypervisors did for servers. In my opinion, it turned out even more interesting,
As you can see from the illustration, GNF (guest network function) - an instance of Junos, runs as a separate virtual machine and solely has at its disposal a set of resources placed in FPC slots. Each GNF along with the FPC set is seen from the outside and functions as a completely separate router, while the traffic between GNF can be transmitted through the factory. This approach eliminates internal contradictions between the functions of the router, increases the stability of the system as a whole, and in addition has the “natural” ability to separate administrative management domains between organizational units. Let me give you another illustration, they began to draw them very beautifully.
The imminent appearance of a universal chassis, where interface cards from PTX10008, PTX10016, QFX10008, QFX10016 and MX can be used, and this is what was reported in the Juniper Networks press release, raises only one question - What was it possible? Juniper already has some groundwork in the field of unification, for example, some MX240-MX960 line card concentrators can be used on the top MX2010 and MX2020 for a long time. The current task looks more serious, since in one chassis you need to combine cards designed taking into account the features of work in all segments of the network - data center, core, border. How this is done has not yet been announced, but according to Donyel Jones-Williams, the new platform is already in test operation in the networks of large customers.
So what is the future trying to bring Juniper Networks closer? The manufacturer focuses not only on the equipment, but mixes the emphasis in the direction of management and operating flexibility. According to various estimates, the cost of the final product is only 40% determined by the hardware stuffing, about the same cost is the development of software, integration and automation tools. Let's see what happens and, if possible, we will take part in the development of the industry, because no one knows where the ladder will lead, as Doc Brown said - the future has not yet been written.
The press release and documentation for Junos Node Slicing can be viewed here:
→ Juniper Networks Unveils Cloud Grade Networking to Accelerate Agility and Innovation in the Cloud Era
→ Junos Node Slicing Feature Guide
