MetaFabric Architecture

MetaFabric Architecture
Hello everyone. Thanks for joining. My name is Dan McGinnis. And today we're here to talk about Juniper’s MetaFabric architecture. MetaFabric Architecture

Business Challenges and Industry Trends
In the first section today we’ll talk a little bit about just in general what we’re seeing from business challenges, trends that are happening in the industry, and then that will lead us into the second section of how do you apply some of these challenges and set out some goals for yourself and how do we help our customers understand perhaps where they actually want to be in the future—how we see their next generation data centers (DCs) moving to cloud-like DCs or having attributes to get them to be more agile, more automated, and help them to make their businesses be more successful ultimately. And then in the last section we’ll actually talk about Juniper’s MetaFabric architecture—we’ll introduce our concepts and some of our technologies to where we take our products and help align them to what our customers who are actually trying to solve or trying to resolve in their DC. Business Challenges and Industry Trends Achieving your Goals—Path to Success Introducing MetaFabric Architecture

Our customers’ business challenges
So let’s first talk about what our customers are seeing as they talk to us about what their real business challenges are. So, a couple questions that tend to be very common ones across the majority of the industry—the first and foremost is, how do I embrace cloud? There’s so much confusion around private cloud, around public cloud, around hybrid cloud—what is the best approach for my business? There’s security implications, there's economic implications, there’s regulatory implications often in a lot of cases. So, for us, it’s about being an advisor to our customers to help them make some of the best decisions for their business. Once there’s a decision made on really what’s next—even if it’s not necessarily the full-blown cloud—there’s still this fear of, “Am I making a good decision if I were to purchase something today? How do I avoid a dead-end? If I make one decision today, is that going to impact me in one year or two years?” Sort of that conundrum of, “I don’t know what I don’t know, and I don’t want to paint myself into a place where I won’t be able to back out of it—at least not very easily or cheaply”. Another question we often see is, “How do I innovate without disrupting my business?” One of the things that we often kind of get caught up in on a white board or in a presentation is just how easy it may be or how easy we can make it look to do the next and greatest thing. But what we often forget about is, “How do I keep my business up and running? I already have a DC (most likely) that is supporting my business or running my business. So, how am I going to actually migrate what is potentially in the old environment into the new environment?” This often causes a lot more chaos than if I have the luxury of being able to build brand new. And then what’s the return on my investment? I think one of the things a lot of executives and business decision makers are challenged with is, “Am I even making a decision that’s going to benefit me in some way?” So, for example, if I was going to go and build a private cloud and invest all the resources in doing the development on these new technologies, what would be the return there? Would I have a one year return, would I have a three year return on my investment? Maybe I’d have no return on my investment at all. Maybe it would just be more expensive in the long run. So one of the things that Juniper really tries to focus on with our customers is not getting so caught up in SDN or cloud or any of these big buzzwords, but really trying to understand where the problem lies, what the challenges are, and then think about what is the best technology. Because, as you’ll see over the next 30 minutes or so, we have a lot of technologies to offer. It’s not just SDN or it’s not just automation. There’s a plethora of things that we can choose from. And that’s really where we try to help out. How should I embrace the cloud? How do I avoid dead-ends? How do I innovate without disrupting business? What is my Return on Investment (ROI)?

Our customers’ desired outcomes
Rapidly deploy apps Provide elastic scale Remove resource silos Increase Agility Lower OPEX Increase ROI Improve efficiency Reduce Costs Accelerate response time Increase uptime Automated response Enhance Experience Protect digital assets Thwart advanced threats Ensure compliance Reduce Risk So, business challenges sort of turn into desired outcomes—right? If we sit down and we really think about, in life, anything that we’re going to do, it’s a good idea to think about why we’re doing them and what we want to achieve when we’re done. So, we’ve kind of broken this down into four main categories that we see is driving a lot of the new technologies and a lot of the new designs that are being implemented in today’s DCs. The first really comes down to wanting to increase agility—whether it be maybe deploying applications more rapidly because I’m servicing a lot of internal customers and I need to be able to turn up new apps on demand. Elastic scale—we see a lot of businesses go through cyclical demand where they may need to grow at a certain time of the year, or around a certain season. But then they need to be able to decrease that size as well. So it’s not always just about scaling up; it’s also about being able to scale down when we’re not using some resources—or potentially allocate those resources to a different portion of our network. And then lastly, it’s about removing the resource silos. One of the things that has plagued the networking industry has been this switch or this firewall or even this server is dedicated to this business unit or this particular customer. And, in order to really realize the efficiency and some of the economics that are necessary to stay competitive, we can no longer limit devices or resources to any particular function; everything needs to be completely pooled and being able to be shared—regardless of where the box sits within the DC, how it’s cabled, etc. The second big outcome that we tend to see customers looking for is the reduction of cost. Yes, absolutely, there’s always a focus on the CapEx expenditures. But, more importantly and where, in today’s world, we can see even a bigger gain, or a bigger reduction in cost, is around the operational expenditures. So, by adding automation, taking the manual effort often associated with either turning up new applications or standing on new servers or whatever those series of tasks are that come in when a new request comes in from a customer—whether that be internal or external—being able to improve the efficiency associated with that turn-up can be much more of an economic factor or a cost saving factor than just the one time expenditure of buying the equipment. Another thing that we really see a lot of IT departments striving for is just to enhance the overall user experience. So, if you take any company that is doing business, they really are more and more dependent—every year, every quarter that goes by, they’re more dependent—on the technology—meaning they have a reliance on certain applications— either it’s CRMs, like customer relationship management software; it could be scheduling software; it could be database software for HR or for scheduling. Think about all the different applications that are used to support a business on a daily basis. So all those applications are supported by an IT shop somewhere. And so, in the enterprise, what we're really looking to do is to try and make sure that we’re increasing the uptime around these applications, because the business is so much more dependent on the technology. Where as recently as a few years ago, if we lost an application inside of the enterprise, we could probably deal with it being down. But now, it’s often essential to our business for these applications to be running—more and more so, anyway. More and more applications are becoming more and more critical to the business. And then the response time: being able to—as an IT department supporting an enterprise, being able to—respond to the needs of my customer—whether it be to turn up new applications, maybe provide new services. And ultimately where we’re trying to get is to a completely automated response, where there's no manual intervention in that process at all. And then, lastly I would say is the reduction of risk. So, as more and more assets stored digitally within our DC or within our cloud network, we all see in the news every single day about more security threats, more attacks being made. And then, to follow that, we see the lawsuits around were we in compliance, what regulatory laws and statutes were we not following that now potentially puts someone at financial or some sort of liability around were they doing the right thing for the business? So the key here is to make sure that you’re not putting your business in jeopardy and the stakeholders that are responsible for keeping the business up and running. These are all extremely important things when we think about: what do we want our DCs and our networks of the future to look like.

IT Quickly Moving Toward Cloud
One of the things we often see—and we’ve continuously seen this trend, so we have a lot of slides out there or a lot of data all pointing to this dramatic increase in the adoption of cloud. And it’s not limited to just private cloud or public cloud or hybrid cloud. We’re seeing all of them continually increase. As you can see, hybrid cloud, for many reasons, has a much slower uptake than what we’re seeing with private cloud or public cloud. But again, the trend is continually pointing aggressively to the growth and adoption of these types of deployments. Percentage of respondents utilizing different types of Cloud computing environments…….. 57% 60% 19% Public Cloud Private Cloud Hybrid Cloud Source: IDG Enterprise Cloud Computing Study 2014

Applications Driving Design Change
Modern App Flows ATTRIBUTES Increased Machine to Machine East-West traffic REQUIREMENTS Flatter Topology High performance and consistent Network Virtualization ATTRIBUTES Virtualized with Bare metal Introduction of Network Overlays REQUIREMENTS Physical to Virtual (P2V) integration Overlay visualization & management Everything “As-a-Service” ATTRIBUTES Scale-out On-demand REQUIREMENTS Multi-tenancy Simple to operate, easy to scale So, to us, I think the key thing is there just to think about is OK, well what’s driving this need for cloud? There’s really three key things that have changed or are driving customers to need something new and something different. The first is this modernization of application flows. So if you think about—if you take an application like Facebook, for example, for every one request that comes in from the Internet—so for every use that is about to connect to Facebook’s webpage or via whatever the interface you’d use to connect, that actually generates up to a 1,000 east-west connections in the DC. So, for every one user request coming in across the Internet, we’re seeing up to 1,000 connections from server to server within that same DC. So ultimately—and this is very common of a lot of applications, the way that they’re being designed today—think about you make a request to any common website—take American Airlines—you log in to that, you go to their website, you go to book a plane ticket, you’re getting information about hotels, you’re getting information about the weather of the city that you’re driving in, you’re getting offers or advertising offers to potentially participate in events when you arrive in the city that you searched for—let alone all of the scheduling activities that need to happen to get the information that you needed just to get you on the potential flights that you need to look at. So, anyway, think about pretty much all applications are serving up more and more enriched content to users as they come in across the Internet. So we classify this or we categorize this as the modernization of application flows. And what this is really doing is it’s setting the need for flatter topologies and to have higher performance, more consistent application flows within the DC. A second example is around network virtualization. So for years and years we’ve watched server virtualization sort of change the way that just about all compute resources are deployed. And now we’re starting to see the advent of network virtualization come into the DC. So, some of those examples, that is coming in the form of network overlays—like VXLAN, or MPLS over GRE, or EVPN—these are really just tunneling mechanisms in order to provide a layer of virtualization across the physical topology. A couple of the things that are really important there are one, it comes back to that, “How do I get my new DC talking to my legacy DC?” So we need some integration from the physical world to the virtual world. And then, with that, we need to make sure that we can provide the right amount of visualization and the management in order to provide the same SLAs and all of the operational efficiencies that we've been providing in IP networks for many years. And then the last thing we're seeing is that everything is being delivered as a service at this point. So you’re watching services like Google, or Salesforce, or SAP, take all the big Software as a Service (SaaS) type applications that are being built—whether or not you’re implementing that internally or you’re subscribing to some SaaS application externally—what we’re seeing is this need for scale out, on demand connectivity and on demand scaling requirements. So the requirements that get driven out of that are one, being able to support multi-tenancy, and then the simplicity in operation and scale.

Hi everyone. Welcome back to Part two or our MetaFabric series. We’re going to talk about achieving your goals and path to success. For us it’s about how do we help our customers really understand what it is that they don’t know and where they’re trying to get—where they’re trying to get to in their business or what they might want to aspire to achieve. Business Challenges and Industry Trends Achieving your Goals—Path to Success Introducing MetaFabric Architecture

Who are your customers? Off-the-shelf buyers Value simplicity
Limited customization Commercial Buyers Frustrated off-the-shelf Hands on and technical Requires customization Open Source Dev Ops Highly skilled, DIY Self-reliant, highly adept Automation is key So the first piece of this stage in my opinion is helping customers to self-identify—figuring out who they are and helping us to understand a little bit more about their business. So, the first type of customer that we tend to see is the commercial buyer. These tend to be ones that just sort of rely on someone like VMware—primarily VMware—to really be the heart of their business. These are off the shelf buyers. They very much value simplicity. They don’t have a ton of extra resources sitting around to do customization, nor do they actually need that customization. They just sort of want to be up and running as quickly as possible with not having to have a lot of people potentially managing their day-to-day environment when it comes to the necessity or the need to customize that environment. Then, the second type of customer that we’re seeing—and this is an areas that’s growing extremely rapidly—are our Open Source types of environments. So people that are gravitating towards OpenStack or OpenDaylight or CloudStack or maybe doing a little bit more of a homegrown solution with Python. These tend to be customers that are a little bit frustrated with off-the-shelf packages, they tend to be a little bit more hands on and technical, and they require customization. So they just don’t necessarily want to build everything from the ground up on their own, but they either find that the economics don’t work for their environment or they need more than potentially what an off the shelf package like VMware would offer. And then the third type of customer we have are these DevOps customers. And there’s really I think two different ways you could look at this type of a customer. The first is one that wants to completely build everything on their own. These are the likes of Amazon or Facebook or Google. They don’t even want to use an OpenStack or an OpenDaylight because they’re going to build that whole orchestration layer, that management layer, all completely from scratch with their own custom code. This is actually what they feel or they believe gives them an advantage over their competitors. Plus, there’s only a handful of customers like that in the world. So it’s not like they could just walk into a store and try to buy a solution off the shelf. That's their whole business—designing this from the ground up. But at the complete other end of the spectrum is this DevOps community that maybe are not fully bought into needing to build what a lot of people would call a cloud, but they very much desire automation. They realize that doing the same task over and over and over again by fairly expensive resources is not necessarily a good use of their time. So they tend to have a little bit more of a DIY attitude—highly adept, but they really are gravitating towards automation. It may not be end-to-end orchestration across the whole network—and we’re going to talk more in depth about all of this in the next few minutes—but see the value in automating series of tasks to help relieve some of their expensive operations teams that are maintaining the environment. And then, this is kind of interesting where Juniper sort of falls in or Contrail falls in, is that for probably in the beginning, when we first released Open Contrail or first made the acquisition and started to integrate it with the rest of our offerings, probably favored more into this Open Source project. But now what we’re starting to see is Juniper Contrail and with Juniper Contrail Cloud, starting to get more and more look like a fully packaged ready to go tool. So again, these by no means are supposed to set the stage and be definitive or draw any hard lines. And in fact, what you’re going to find is that most customers will be a combination of all three of these. For example, a customer may have a large pocket of VMware that they’re potentially looking to move to NSX, but at the same time, they’re evaluating and OpenStack environment with an alternative hypervisor to ESX. And actually this is where Juniper fairs very well. Our goal is not to talk a customer into being one or the other. It’s more about, “Hey, how can we look at all of the problems that you’re trying to solve, and align our technologies to help meet your needs”. So again, a lot of this beginning phase, when you start to lay out what the next few years look like for a customer, and where they’re trying to take the direction of their network, is to help them self-identify and help our customers really understand what it is that they need to be successful.

Path to Success: Identify
You Need to Be Here User Click Here Today You Are Here At a very, very high level, we’re going to talk about two extremes here for a couple minutes. So, on the left hand side, what we’re seeing is where most customers are today—where most enterprise customers are today. And what we’re depicting is a very manual process, so some sort of a change request comes in, someone’s looking for a new application or a new server, and what happens? A ticket gets opened and then a series of tasks get opened in the backend—provision some compute, provision some storage, make some networking changes, potentially modify some firewall policies. And then, days or weeks later, we finally receive something saying, “Oh, your change request has been completed”. That does not fly anymore; that is not acceptable. It’s becoming less and less acceptable every day and it’s soon to be a completely obsolete process when it comes to just doing business on a day-to-day basis. So ultimately where we’re trying to go—and some people will see this as very far-fetched or very far out but, if you look at the direction—and typically our enterprise customers are following in the paths of what a lot of our cloud providers are starting to offer. But think about how Amazon Web Services work. I need a new resource, I swipe a credit card, I say how much compute, how much storage? I need some firewall policies, I need some IDS services, etc. And, within a matter of minutes, I have a fully functioning network ready to host my Web application and my database servers. And so, we’re starting to see that similar trend catch on in the enterprise. So, even if someone’s not going to get to a point where their internal customers are going to work off of a self-service portal, we’re still getting to a point where all the changes that we just talked about (on the left hand side) are becoming fully automated. So a request comes in and, rather than a person actually taking action and fulfilling each one of those individual requests—whether it be as simple as a series of scripts running or an automation tool, like Ansible or Chef, being implemented or invoked, or a full-blown orchestration tool, like OpenStack, kicking off a series of work processes in the backend—these are the things that our customers are ultimately trying to achieve and trying to figure out what’s right for their environment. So, with that, what we see is a whole bunch of things that have to get thought about. In order to get from the left hand side to the right hand side of this diagram, we have to think about: Are we willing and ready to implement SDN technologies yet? What type of orchestration tools, if any, do we want to implement? What are the security implications going to look like? What type of security strategy are we going to put in place? What types of protocols are we going to look at? Are we looking at overlays with VXLAN? Are we going to put EVPN inside the DC? The intelligence around extracting the information—so how are we going to provide the support and the operational guarantees that we provide in a traditional environment? What types of tools, from a monitoring and a health reporting standpoint, are we going to implement? And then, how are we going to support all this? How are we going to get our people trained? How are we going to get the subscribers of our systems accustomed to working off of a more self-subscription type model—if that’s ultimately what we’re trying to achieve? So, anyway, moral of the story here is that there are a lot of decisions to be made. And often what we see is customers getting frustrated or uncertain of how to answer these questions. And then, they’re worried about making a bad decision even on something as elementary as deploying the foundational network that’s going to support all of this. User Change Request Days or Weeks later… IT Admin SDN? Orchestration? Security? Protocols? Intelligence? Support?

Path to Success: Set Goals
You Need to Be Here VIRTUALIZED HR MARKETING FINANCE Resources are pooled Network services are virtualized and distributed Moves/adds/changes are fully automated Orchestration is completely centralized Security is integrated Today You Are Here Resources are in silos Network services are on physical appliances Tasks are not automated Orchestration is decentralized Security is an afterthought VLANS FINANCE HR MARKETING Firewalls Load-Balancer Physical Servers Local Hard Drives So, what I like to do when I’m talking to customers is think about setting a path to success—setting goals. So today you’re here. Your resources are very siloed, meaning servers, switches, FWs, load balancers—they’re all dedicated to perhaps a single business unit or a single set of applications; network services are most likely on physical appliances, tasks are not automated or orchestration is decentralized, meaning there’s a lot of different systems that we have to log into to make a set of changes that are necessary in order to implement probably just one request. And security is often an afterthought. So ultimately where are we trying to go? In order to get to again this place of agility and elasticity when it comes to scale, and have something that the economics are more suited to being competitive in today’s world, we have to look at changing some of these points that we just talked about. So resources need to become completely pooled. We can no longer think about dedicated resources, dedicated environments—it just has to be a pool of resources that we can allocate towards the next request. Network services are becoming more and more virtualized and distributed. So being able to turn up new services—whether that be something like a load balancer or a firewall—but being able to deploy them more on demand and not having them tied to a physical appliance that takes time to turn up or needs to be bought and provisioned in advance of a change. Moves, adds, and changes start to become fully automated. So, when a request comes in—a request to turn up a server—has a very similar set of actions that get taken every time that same request comes in. So, putting automation behind this starts to set you up to be more agile and especially less prone to human error. So orchestration is more centralized—things like OpenStack sit in front of the entire environment so that our compute, our storage, our security, and our network provisioning is all done from a single place. We have holistic views of what the topologies and the infrastructure looks like. And security is integrated. Sometimes we make all these strides to go and build a flat network, and then we hang a firewall off to the side that everything has to hairpin in and out of. And it sort of defeats the whole purpose of some of the things we were trying to achieve when it came to building a flatter topology. So that’s just one example when I say that security is more integrated.

Path to Success: Plan Traditional Data Centers Cloud Data Centers
VLANS FINANCE HR MARKETING Firewalls Load-Balancer Physical Servers Local Hard Drives So, some things to think about. Often—as technologists, we often get caught up in all the latest and greatest technologies. But then the reality sort of sets in and says, “Oh, well we want to do all these things but there’s all these pre-requisites that we have to implement”. So, for example, we might want to introduce this next generation SDN controller into our environment, but we need network equipment that talks the right control plane protocol. And so we’re going to have to get all of our network replaced before we’re prepared to implement this SDN technology. So then we’re caught in a year’s worth of evaluation, proof of concept testing, etc., in order to realize some of the benefits that we wanted to achieve from SDN. When we talk about IT and networking infrastructure, we’re always going to be in that planning mode of what’s going to be here in a year, what’s going to be here in two years, what’s going to be here in three? But what I think is important is that we also think about how can we realize some of the benefits that we’re trying to achieve with the gear that we have today? So let’s kind of take look at some examples of what infrastructure is sitting in a traditional DC and then what we can do to sort of get us starting to move from the left hand side to the right hand side now, and then how that helps—how we can evolve that into what is yet to come. So, for Juniper, we’ve done a lot of work with OpenStack and CloudStack and Chef and Puppet. So we’ve done a lot of joint development with these tools to allow them to talk directly to our networking equipment, to our switches, to our routers, to our FWs, today. The same boxes that you already have deployed, if it’s a Juniper shop, can take advantage of some of this automation and these orchestration elements that we were just discussing. One of the other things that we’ve done with Network Director, which is our “single pane of glass” network management utility tool for the DC, is to allow that to act as a proxy so that, rather than OpenStack, CloudStack, or Puppet having to talk directly to each individual firewall, Network Director can sort of sit in the middle and via northbound APIs, talk to these tools. That tends to be a more preferred deployment in a lot of customer scenarios. The other thing that we’ve added here is VMware vSphere. And so Network Director and vSphere have a very tight integration in which Network Director is very much aware of all of the server virtualization that is being implemented and can take advantage of correlating what it knows about the network as well as what it knows about the server virtualization that’s being spun up and provide a lot of holistic visibility across different VMs as they move throughout the environment. We’ll talk a little bit more about this throughout the remainder of the presentation. But anyway, tight integration with VMware deployments outside of NSX. Now, as we move into more of the network virtualization DC—when we start to introduce an SDN controller—so, for example, VMware NSX. One of the things that Juniper has done is implement the OVSDB connectivity so that our switches can interact with the NSX controllers to provide hardware VTEP gateways. This is very important (as we alluded to earlier) in how legacy environments, that are non-SDN aware, can talk to our new SDN deployments. And so things like OpenStack and CloudStack and the VMware suite of tools still acting as orchestration layer tools but talking to a more modernized network topology. And then, side-by-side, Juniper also offers Contrail as an alternative means to deploying SDN in the environment—so things like OpenStack, CloudStack, sitting on top of Juniper Contrail and even integrating with other OSS and BSS systems from IBM and BMC and things like that. So again, it’s just important that from when we’re having conversations with our customers that we’re staying focused on what we can do now in the short term and then also setting up a more long term plan. And this kind of ties back to how do we avoid those dead ends, but make sure that we’re following a nice evolution as the technology matures, as we are able to actually get more of the modern infrastructure installed—and again, this is all a continuum. There’s no end state. Technology will continue to evolve and we just want to make sure that we always have the short term and a long term plan as we think about how we’re going to help our customers deploy our DC. API Network Director API NSX Controller OSVDB API BGP/ NETCONF VIRTUALIZED HR MARKETING FINANCE

Path to Success: Foundational Impediments
Suboptimal topologies Inconsistent performance Disaggregated elements Network is complex Security is difficult Physical is the default Bottlenecks Automation is key The other thing that we’d like to talk about, just a little bit, is what’s making this difficult? Why is there so much thought around how to deploy these networks and then what’s holding customers back? So, just a couple things that we could call out. One—the network is very complex. So right now, there’s traditionally a lot of sub-optimal topologies out there; performance is very inconsistent—whether that be a mix and match between 1G and 10G links, the way that we do load balancing across the spines, because of traditional routing protocols—like MC-LAG, potentially, or Spanning Tree even—not allowing for active-active across more than two boxes in the spine. And the fact that a lot of the elements tend to be disaggregated. So, yes, they’re connected by a common routing protocol, but we’re not seeing a lot of management interaction between those boxes—or the tools that are implemented today to help provide the management—the overall management and operational tools that we use on a day-to-day basis. Secondly—processes are very manual. So it’s difficult to provide automation—especially when you’re dealing with a lot of individual box-by-box touch points. It’s hard to actually get the data that you need in order to make intelligent decisions back into the network via scripts or automation tools. So that’s a problem. And then lastly—security. Right now—physical, for the most part, up until recently—physical FWs have really been the default inside the DC. But this creates a bottleneck within our network and isn’t allowing for a lot of automation when it comes to adding new policies as new applications turn up. So there’s certainly some newer ways to approach all of this and that we’ll start to talk about in the next section. Processes are manual Difficult to automate Box-by-box touch points Difficult to mine data

Hi everyone. Welcome back for part three of our MetaFabric architecture overview. So, in this last part, I’d actually like to introduce you to MetaFabric and talk a little bit about how we help take our technologies and align them to a lot of the things that we just talked about in the previous two sections. Business Challenges and Industry Trends Achieving your Goals—Path to Success Introducing MetaFabric Architecture

First let me start by saying, when we talk about MetaFabric, a lot of people will say, “Well, is MetaFabric a replacement for QFabric or a replacement for VC Fabric?” And the answer is, “No”. MetaFabric was designed and intended to be more of a blueprint or a vision for how Juniper sees the evolution of the modern DC—so how we help take a customer, that has a traditional legacy IT environment, and help migrate them and get them to move to this more elastic, on-demand, agile DC that we may (or may not) call cloud. And the reason I say that is, cloud potentially has some characteristics associated with it that a customer may never actually achieve what the industry may coin a “private cloud” or a “hybrid cloud”. But it doesn’t mean that we can’t take advantage of a lot of the same features in order to achieve what we’re trying to do to help our customer's business. So again, you can’t buy MetaFabric; you can’t license it. It is intended to be a holistic view of how we help our customers solve problems inside the DC and to help them connect DCs to one another. So, let’s explore this a little bit further.

Three Guiding Principles
Easy to buy Easy to deploy Easy to operate Easy to secure Simple Embrace open standards Enable choice Alleviate lock-in Standard APIs Open Smart Self-healing Proactive Event correlation Security intelligence When we started out and we thought about really what we wanted to do, we’re going back a couple years now when we said—when we introduced MetaFabric in October of 2013, we set out and said—“OK, well what is it that we’re trying to accomplish? How are we going to evolve the way that Juniper looks at the DC, looks at what the evolution of our products and what our software will look like?” So our first focus was around simplicity. Whether it was helping our customers making it easier for them to buy our gear and evaluate our gear, to deploy it, to operating it, to securing it—just pretty much simplifying the whole process of the time they start evaluation up through the time they deploy and operate. The second focus area for us—and I believe that this is actually the most important one of the three—is really around being open. So Juniper is a firm believer in that we know that there are other partners that are going to offer a “best of breed” technology that we may not—and vice versa. And so our goal is not to dictate to our customers, “Hey, this is what your end-to-end solution should look like, no matter what”. Our goal is to adhere to open standards as much as possible, whether that’s in the protocols that we deploy, in the APIs that we use, and allow our customers to have choice. So certainly we want to be there to guide them along the way and make recommendations, but we want to be able to integrate with technologies that they may already have, are looking to deploy—whether that’s in other networking infrastructure, in applications that help enable their network, etc. And so we’ll continue to talk about this a little bit further. But for us, the openness aspect is a big one. And then lastly, there’s this thing around being smart. And I find this to be probably the most interesting because this is where there’s just so much R&D and innovation happening in this space. So, if you just think about a network that is self-healing, that is more proactive, that has the ability to correlate events that are happening—not just in the routers and switches, but across all of the network—inside the applications, inside the compute, inside the storage element. Then to make intelligent decisions so that a human doesn’t even have to get involved to repair. I mean that’s ultimately the direction that we are heading. And certainly a lot of steps will be made over the next several years that help us get to that point. But it sort of starts with being able to extract the intelligence. We live in a world big data. Every industry that we look at, one of the most important initiatives is to gather more data to do something useful with it. In healthcare it’s about saving more lives. In financial services it’s often about being more profitable because we have all these spending habits, or potentially to alleviate risk by being able to do more calculations around where we stand in the market. So for us, for Juniper, big data is really about gathering intelligence from the network and then being able to do something useful with it. So these are just three guiding principles that we very much pay attention to and think about as we develop our solutions and our products for all DCs and networks to come.

Core Strengths Switching Routing Security Common building blocks
Flexible fabrics Industry leading scale Embedded automation and SDN Switching Enhanced custom silicon Advanced MPLS Unprecedented performance Virtual and physical Routing Security High throughput Low latency VNF integrations Virtual and physical We kind of start out with our core strengths. We have not strayed away from knowing that switching, routing, and security are the core to what Juniper does and does “best of breed”. So in switching, a couple of important attributes—first of all is around our common building blocks. One of the big things that Juniper is focused on is to not create a set of switches that is only useful in one architecture and then force our customers to “rip and replace” those boxes when they need to move to potentially a larger design or a more modern design. So we’ve been very emphatic about making sure that all of our switches are common across all of our fabric architectures. And then hence, adding the flexibility into the fabrics so that they’re deployable for many different use cases, and also upgradable in the event that perhaps a customer outgrows or needs change—being able to reuse that hardware in different architectures, or potentially not even in the Juniper fabric and more of just the standards-based IP fabric. We have industry leading scale across all of our platforms. And although I find this is somewhat of a leapfrog game in the industry, we still stay focused on making sure that, to us, it’s a pre-requisite to be able to have boxes that are competitive around size and performance. And then, very importantly, is making sure that embedded automation and SDN capabilities exist in our platforms so that we can enable some of the newer technologies that we’ll continue to talk about in the next few minutes. So, from a routing perspective, we still maintain a custom silicon program. So Juniper realizes that there’s a need for custom silicon and merchant silicon—and that’s why we have a two part strategy there. Our advanced L3 stack and our MPLS stack—and now we’re even starting to see those protocols like MPLS and EVPN—become more and more integrated into the DC; they’re not limited to just a DCI or WAN protocols but being able to lean on our heritage of advanced routing and start to implement those same technologies and collapse layers and provide more flexibility inside the DC—it’s something that we’re starting to see a lot of customers really gravitate to and prefer from our offerings. And also—in the routing aspect of that integration between the virtual world and the physical world—so how do we take our legacy non-SDN environments and help bridge them into the world of network virtualization? And so then lastly is security. So, still focused on high throughput, low latency, and having a multitude of virtual network function offerings that are applicable inside of today’s DC networks.

Cloud Analytics Engine
The Glue Acquisitions Technology Alliances Software Junos Space Universal SDN Gateway EVPN with VXLAN Standard APIs Cloud Analytics Engine Virtual SRX and MX Overlay Visibility So then, when we continue to look at MetaFabric and say, “Alright, well we started out—we have our core strengths; the key for Juniper is to take those three core strengths, but then ultimately provide them as an end-to-end coherent solution that helps a customer not see them as disparate entities. So I kind of talk about the glue. There’s a couple pieces or a couple aspects to this. The first is the acquisitions. So Juniper’s done two really big acquisitions in the last couple of years that I think has helped propel us into being leaders in the DC and cloud space. The first one is Contrail, which is our SDN offering. And the second one is WANDL, which now comes in the form of NorthStar, which is our SDN inside the WAN. The other thing is this technology alliances. So, we know that going about this alone is not the way, or is not the right approach in today’s day and age. So having strong partnerships with industry leaders like VMware and IBM and OpenStack and a bunch of other industry leading vendors is extremely important and a big focus for us. And then lastly are all these enhancements in software. When you’re a tech company like Juniper, a lot of the perception in the industry is always about the hardware—it’s just been ingrained—especially in most network people—to stay focused on the speeds and feeds, how big your box is, how fast it performs, how well it competes and stacks up against the typical competitors. But more and more, as we get into more modern, cloud-like architectures, the software is becoming just as important, if not more important, from a features and capabilities perspective. So things like Junos Space and Network Director, our Universal SDN Gateway that helps us bridge our network virtualization and SDN overlays with the non-overlay world, the APIs that we’re providing and enhancing to make sure that we’re compatible and can integrate with other third party software out there, our Cloud Analytics Engine which helps us extract the telemetry and the analytics data from the network equipment and correlate that data to help provide intelligent statistics and views back to the operators, providing virtualization of the SRX and the MX—so offering two form factors—one in a hardware based form factor, the other one in an x86 software based form factor—so that you can run them in more of an agile, on-demand way. And then our Overlay Visibility providing good operational statistics around our overlays. So these things are sort of what take the underlying routing, security, and switching infrastructure—it starts to tie it together and helps it become an end-to-end solution for our customers.

METAFABRIC: THE BEST OVERLAY FOR ANY UNDERLAY,
THE BEST UNDERLAY FOR ANY OVERLAY INTEGRATED MANAGEMENT SECURITY DIRECTOR Apache Thrift B/OSS, ITSMs, DevOps, Platforms & Apps SERVICE VIRTUALIZATION vSRX vMX Service Insertion and Chaining VNF Partners (Security, ADC, NAT…) Being a network guy, I think a lot of us like to look at things in layers. And so, for us, in order to achieve a lot of what we talked about in the last couple sections of this deck—in order to get from what was on the left hand side of the screen to the right hand side of the screen—comes in a way of—we hope that it comes in a way that we can provide this in a very modular fashion to be integrated—but modularly integrated—and I’ll explain as we go on. So, for us, a couple important things around foundational technologies—so, having a multi-silicon strategy—where we use merchant silicon in some devices and we use custom silicon in other devices. A good example of this is being able to provide—take the same MX that our customers have had for many years and, with software upgrades, being able to provide—Universal SDN gateway, which is essentially our on-ramp/off-ramp between every combination of SDN controller and technology that exists on the market today—just via a software program. And a lot of times—one of the things that we’ve alluded to and often comes up in a lot of customer conversations is around this concept of investment protection and I don’t know what I don’t know and I don’t have a crystal ball. And we believe that our programmable silicon is really the best thing out there when it comes to being able to adapt and provide investment protection. If you even take the expense aside, and you forget about how expensive some of these systems are, the work that is often entailed in replacing some of the core routers or the DC aggregation boxes could far outweigh any price tag that you could put on the box. Combine those two together—this is where we really see the value and the necessity in order to provide an ongoing programmability aspect so that we can adapt to all of the new technologies that are coming down the pipe. We have a lot of innovation in what we’ve done with our optics and the how we’re building our fabrics—and certainly Junos is really the key to providing a lot of these capabilities. From inside MetaFabric (and sort of what I alluded to earlier), MetaFabric is not a replacement for the QFX or for Virtual Chassis Fabric or, for that matter, for any of our switching or hardware infrastructures. As a matter of fact, they’re really just a piece or an element of the overall end-to-end architecture. So for us, a combination of everything that we’ve done with our FWs and with our switches, and with our routing devices, and how we’ve turned them into a multitude of DC architectures that focus on a set of common building blocks. These are really the foundational elements in order to be able to provide a lot of these other integrations and features that we’re about to talk about. So certainly, network overlays, commonly known as SDN in the DC—there’s really three offerings that we provide to our customers. So the first is this distributed VXLAN overlay. Sometimes this will be referred to as a controller-less SDN, where there is actually no SDN controller, but we’ll use a routing protocol like EVPN, combined with a data overlay like VXLAN, to provide network virtualization capabilities in the DC. And then certainly we have a very strong partnership with VMware and NSX. And then we also offer Contrail. So, for Juniper, it’s not really positioning any one of these against the other. It’s being able to offer them side-by-side that we find to be a very powerful and compelling offering for our customers. Then we look at service virtualization. So one of the other big trends that we’re seeing inside most DCs today is to move away from the concept of having physical appliances for every service that gets offered in a DC, but being able to spin them up more on-demand on traditional X86 hardware. So we have virtualized both our MX and our SRX. So we offer a virtual SRX and virtual MX. And we certainly focus on those integrations within the DC to provide more flexibility and be compatible with a lot of the automation techniques that we’re seeing our customers want to take advantage of today. And then lastly is all of the integrated management. So, whether it be Juniper tools, like Network Director and Security Director, or the plethora of third party tools that we’re seeing a lot of customers gravitate to—so the big ones like OpenStack and VMware. And then there’s a lot of the OSS integrations that are coming out of Amdocs and the likes of VMC and IBM. So all of these for Juniper are important players in this space. And our focus is to not dictate to our customers what tools they should be using, but trying to be as flexible as possible, rely on open standards so that we can integrate with the tools and the platforms and the applications that we’re finding our customers are using in their environments. So, for Juniper, it’s all about having a completely integrated solution by using open technologies and being able to look at each one of these layers in a very modular fashion that can be replaced and interchanged based on our customers’ needs. OVERLAY ARCHITECTURE MH Distributed VXLAN Overlay COMPLETELY INTEGRATED SOLUTION WITH OPEN TECHNOLOGIES ENABLING TRANSITIONS: Each layer can be updated independently, without replacing other layers or building blocks QFX Series Switching SRX Series Security EX & MX Series Universal SDN Gateway UNDERLAY ARCHITECTURE Flexible Architectures Industry Standard Optics Multi-Silicon Strategy Innovative Systems Integration Innovative Software FOUNDATION TECHNOLOGIES ANY HYPERVISOR, ANY SERVERS, ANY STORAGE

MetaFabric: End-to-End Networking
Multi-data center, multi-cloud, one network Hosted/ Managed And so, to kind of sum that all up and put it into a more holistic perspective, MetaFabric is not intended to solve a problem just inside the DC. When we talk about MetaFabric, when we think about MetaFabric internally, when we use it to help drive the roadmap and the strategy for our products and our solutions, it’s really about the end-to-end management, deployment, and operational model that’s associated with maintaining multiple DCs, multiple pods within a DC, the connectivity across the WAN, out to our campus and branch, and then the integrations with all of the hosted and publicly hosted and managed cloud services that are being offered by the likes of Amazon or all the Infrastructure as a Service (IaaS) players out there today. And so, for us, this is all about delivering to our customers an easy to manage, easy to deploy, end-to-end solution that is adaptable, agile, elastic, and allows them to really stay focused on what the needs of their business are without getting bogged down by a lot of the traditional bottlenecks and deployment scenarios that we talked about earlier on. Internet P Public Cloud (Hybrid) Campus & Branch WAN MX MX Virtual & Physical Security Virtual & Physical Security QFX Series, EX Series and QFabic Switching QFX Series, EX Series and QFabic Switching Private Cloud Private Cloud

MetaFabric: End-to-End Support and Service
Beyond just the tools and the hardware, MetaFabric extends itself to things like having validated design. So one of the things that we’ve taken a lot of feedback from our customers on is that they want something—they want a guide; they want someone to show them what works, what doesn’t work—to show them that it’s been validated, that it’s been tested, what the deployments scenarios have been. Because one of the things that we’re seeing today is that you can’t just go out and read a book on how to go build a DC. 10, 15, 20 years ago, it was easy to go pick up a book and say—a Cisco Press book and say, “Hey, this is how I’m going to build the modern, or build my next-gen, DC. But now the technologies have gotten so much broader and so much more intertwined. And it’s not that we’re talking about just building a network—we’re talking about how do we integrate the compute resources, how do we integrate the storage resources, what automation techniques are we going to use, what management tools are we going to look at? And so customers are overwhelmed by information and opinions that are just floating around on the Internet. And so, with that, we believe that it’s our job to help our customers to really take the time to understand their business model, their challenges, and determine—of all of the options that are out there—what are really the best suited to help them? And so, as we move into this next bullet (I talk about assessment services) we really believe and have focused on enhancing our professional services offerings so that we can help our customers look at what transformations would look like to go from a legacy IT DC to a next-gen MetaFabric cloud-enabled DC. And then lastly—a lot of partners—we have a lot of channel partners out there; we have things like our Ingenious Champion program, our Managed Elite program—that helps us identify partners that are capable of delivering these end-to-end solutions to our customers and working with them and our customers to develop these solutions. Validated Designs VMware NSX Juniper Contrail SDN Controller Assessment Services MetaFabric Transformation Assessment Risk Mitigation Assessment Channel Partners Managed Elite Ingenious Champions Program

Juniper MetaFabric Customers
Service Provider Enterprise Conglomerate Global Financial User Defined Cloud Global Data Center refresh Global Data Center refresh AT&T - Nike - UBS –

The Juniper MetaFabric Journey

MetaFabric Journey to Cloud
Legacy IT Data Center Elastic, Flexible & On-Demand Fully automated and self-provisioned cloud And so, when we talk about our MetaFabric journey to the cloud, there’s really four pieces that I think it’s important that, as a customer, you stay focused on. So, on the left hand side, along the top, we talk about the legacy IT DC—and ultimately we’re trying to get to this elastic, flexible, on-demand, cloud-like type DC. And so there’s really four things that you have to keep in mind when you’re evaluating solutions and technologies. The first one is the whole modernization of the network topology. So, if you remember in the beginning of this presentation, we started to talk about how applications are changing and how the network needs to change with it—they need to become flatter, they need to become faster, they need to become more open. So I encourage you to spend some time looking at what Juniper’s strategy has been to help achieve this. The second is around the broad set of orchestration and automation tools that are out there. I think, from a customer perspective, there’s a lot of decisions to be made. And they don’t necessarily have to be made all up front, but they should at least be in consideration of: “Am I going to deploy OpenStack? Am I looking at more traditional automation tools like Puppet? Where do tools like Junos Space, Network Director fit in to help complement?” And then, which tools are you going to evaluate and are they the right tools that will help you achieve what your goals are? The third piece—and I think this is really important—is around the analytics and telemetry capability. And this kind of ties back into that smart pillar we were talking about when we evaluated the guidelines. So how am I going to extract the right analytic and telemetry data from my network in order to provide the right correlation of events and be more proactive in the way that we failover, and things of that nature? And then the fourth piece is how am I going to integrate SDN and NFV into my DC? Do I have the right infrastructure that provides the right on-ramp and the right integrations so that I can have a successful SDN deployment? And then certainly, throughout all of this, you need to be thinking about how security is integrated and deployed. So with that, I encourage you to talk to your Juniper account teams and explore a little bit further around these four specific areas. Thank you for your time. Modernized network topologies – flatter, faster & open Broad set of orchestration and automation tools Deep analytics and telemetry capabilities & correlation Simplified integration with SDN & NFV Cloud Analytics Engine Distributed VXLAN Overlay A single, coherent network

Legacy IT Data Center Elastic, Flexible & On-Demand Fully automated and self-provisioned cloud Modernized network topologies – flatter, faster & open Broad set of orchestration and automation tools Deep analytics and telemetry capabilities & correlation Simplified integration with SDN & NFV Cloud Analytics Engine Distributed VXLAN Overlay A single, coherent network

Flatter Topology 3-Tier Approach Spine-Leaf 2-Tier
WAN Internet 3-Tier Approach Spine-Leaf 2-Tier Ñ Ñ Ñ Ñ Leafs residing at the top of each rack All leafs and their associated hosts are equidistant Consistent east-to-west performance

Introducing QFX10000 Switches
FIXED & MODULAR 10GbE / 40GbE / 100GbE SPINE / CORE SWITCHES Powered by Juniper custom silicon Meet rapid and continuing data growth MOST SCALABLE Accelerate innovation OPEN Invest for today and tomorrow FUTURE PROOF

Cloud Switching Portfolio
How to Fit into Spine-Leaf Solution NEW MODULAR EX9200 QFX10000 Up to 480 X 100 GbE Ports NEW SPINE SCALE UP ARCHITECTURE FIXED QFX Q QFX10002 QFX5100 QFX Q-AA QFX-PFA-4Q NEW OCX1100 EX4300 LEAF GIGABIT ETHERNET OCP NETWORKING 10 GIGABIT ETHERNET APPLICATION INTEGRATED SWITCHING

What Makes The QFX10K Different
Density 4x the 100GE port density. Slide – How They Are Different Density – 2X the 100GE port density Scale - 3x the total system scale Performance – 5X – 100x the buffer size – increased application performance. Flexibility – Complete architectural flexibility – numerous L2 & Fabrics using same building blocks Openness - Ability to write custom applications on Junos Industry leading scale: up to 96Tbps at launch, scalable to over 200 Tbps in the future Highest density: QFX1002: up to G interfaces (or G) in a 2RU form factor QFX1008/16: up to 240x 100G for 8 slot; 480 for 16 slot Single building block to serve multiple deployment scenarios preserves flexibility and choice Multidimensional performance eliminates performance trade-offs across physical, logical and overlay networks Unique satellite device capability solves elephant and mice problem by moving buffering to spine switch Precision timing synchronization enhances accuracy of Cloud Analytics Engine Architectural flexibility allows deployment in multiple different network designs (L3 spine-leaf; L3 Clos, etc); can be configured on per-port basis Enhanced adaptive load balancing improves efficiency and link utilization Deep buffers enabled by high-performance, custom silicon ensure quality of service Open architecture prevents vendor lock-in Future proof design enables seamless transition from 10, 40, 100 and eventually 400G Scale 2x the total system scale. Flexibility Wide range of architectural choices. Automation Automation, zero touch provisioning & SDN. Openness No vendor lock-in; software customizable.

What Makes The QFX Different: Custom ASICs
First to market with 100GE switch. Challenges are not about scale. Juniper Designed and Built ASIC First Juniper silicon to push 500Gbps 3x power efficiency gains over previous generation 4x performance over predecessor chip 3D Memory architecture 400G ready No compromise performance Q5 Chipset

Place for Both: Merchant and Juniper Silicon
Merchant Silicon Juniper Silicon Embedded logic and processing power for analytics and automation Seamless migration from 10GE and 40GE to 100GE and 400GE Highest scale offering for flexibility in overlay topologies QFX10000 Series With Q5 ASIC QFX5100 Series Fixed configurations Low logical scale & buffers Leaf and small spine applications Optimized for high-density 10/40GE Medium density 40/100GE

Cloud Networking Architectures
Multi-tier MC-LAG MX L2/L3 L2 VLAN anywhere MAC mobility Operational simplicity Ethernet Fabric L2/L3 L2 and L3 agnostic Centralized management Plug & Play provisioning Integrated monitoring IP Fabric Layer 3 Routing ECMP for load balancing No Layer 2 sprawl Extremely high scale L3 IP Fabric with Overlay Virtual Network L3 IP underlay fabric VXLAN, EVPN, etc overlay Isolated data plane Emerging technologies

Coherent Data Center Fabric Architecture
Q: When a bear fights a shark, who wins? A: It depends on whether the fight was on the beach or in the water. We should pick the location where we choose to invest our energy fighting. Coherent Data Center Fabric Architecture Business Critical IT & Private Cloud SaaS, Web Services Ethernet Fabric Multi-tier MC-LAG IP Fabric VCF QFabric Junos Fusion Virtual Network … <4,260Servers < 1,500 Servers 10,000+ <6,000 Servers JUNOS: one common operating system for all fabrics

Automation ≠ Orchestration
Speeding up “IT” Workflows at scale while eliminating errors Automation “Crushing Grapes” Orchestration “Making Wine” Automation helps eliminate repeatable manual tasks through scripts or other software tools Orchestration is an extension of automation that groups automated tasks into coordinated workflows.

IT Infrastructure Lifecycle
Phase 1: Test & Certify Design Validation New product introductions Feature certifications Phase 4: Audit & Troubleshoot Compliance & Regulatory Fault remediation Proactive escalation Phase 2: Build & Deploy Configuration creation Infrastructure instantiation Validation testing Phase 3: Operate & Maintain Inventory management Moves/Adds/Changes Change impact assessment

Juniper Automation Portfolio
Contrail SDN NorthStar Network Director Security Director JUNOS Space JUNOS SDK API BASED Ansible Puppet Chef OFF BOX TOOLS Juniper Openstack Plug-in ZTP Juniper Cloudstack Plug-in OpenClos Ruby-EZ SLAX PROGRAMMING PY-EZ NETCONF JUNOS SDK OPEN PLATFORM One JUNOS Software Virtual Chassis Fabric

Cloud Analytics Engine
Application-centric view of intelligent network NDA NDA NDA DLE Network Director Spine NDA Leaf Correlate end-to-end network performance with application requirements Transparency into physical and virtual layers for simpler operations Improve co-ordination between teams for better application delivery and experience Benefits VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM Hypervisor CA CA CA CA Server Bare Metal

Junos Space Network Director Single Pane of Glass to …
Visualize analyze control VISUALIZE Holistic and correlated view Data center and campus topologies Correlated overlay and underlay networks visibility Physical and virtualized connectivity Polish Analyze Smarter and Proactive Networks Built-in collection and correlation engine Heat map and root cause analysis Network telemetry for overlay & underlay networks CONTROL Lifecycle and Workflow Automation Fabric automation and management Scalable and resilient multi-site management Data center fabric management

Juniper SDN in the Data Center
Powered by two SDN technologies NSX Juniper routing, switching and security solutions support either: Contrail or VMware NSX Contrail SDN overlay supports any hardware: Juniper or 3rd party vendor Juniper MetaFabric architecture supports an end-to-end solution for both Juniper Contrail and VMware NSX SDN deployments.

Network Devices in the Data Center
USG (Universal SDN Gateway) Network Devices in the Data Center Databases HPC Legacy Apps Non x86 IP Storage Bare Metal Servers ESX ESXi KVM XEN Virtualized Servers L4 – 7 Appliances Firewalls Load Balancers NAT Intrusion Detection VPN Concentrator NSX-vSphere ESXi NSX-MH ESXi NSX-MH KVM NSX-MH XEN SDN Servers

All the Devices Need to Communicate
USG (Universal SDN Gateway) All the Devices Need to Communicate Four Primary Use Cases Provide SDN-to-non-SDN translation, same IP subnet SDN to IP (Layer 2) Layer2 Provide SDN-to-non-SDN translation, different IP subnet SDN to IP (Layer 3) Layer3 Provide SDN-to-SDN translation, same or different IP subnet, same or different overlay SDN to SDN SDN Provide SDN-to-WAN translation, same or different IP subnet, same or different encapsulation SDN to WAN Remote Data Center Branch Offices Internet WAN

Universal SDN Gateway (USG)
Two Gateway Options Layer 2 Gateway Universal SDN Gateway (USG) QFX5100 series 1 of 4 use cases Standalone – VC – VCF Relatively low cost MX Series, EX9200 & QFX10000 4 of 4 use cases Custom silicon = future proof Higher cost, larger footprint

Universal Gateway Solutions
USG (Universal SDN Gateway) Universal Gateway Solutions DATA CENTER 1 Native IP L2 Native IP L2 VxLAN VxLAN Native IP L3 Native IP L2 Native IP L2 Native IP L2 Native IP L2 Native IP L2 Native IP L2 Native IP L3 Layer2 USG VxLAN VxLAN VxLAN VxLAN VxLAN VxLAN Native IP L3 Native IP L3 Native IP L3 Native IP L3 Native IP L3 Native IP L3 VxLAN VxLAN VxLAN VxLAN MPLSover VxLAN VxLAN Native IP L2 MPLSoverGRE MPLSoverGRE MPLSoverGRE NSX SDN Pod 1 VxLAN VxLAN VxLAN VxLAN VxLAN Native IP L3 Native IP L2 Native IP L2 Native IP L2 Native IP L2 Native IP L3 Native IP L3 Native IP L3 Native IP L3 Legacy Pods GRE GRE EVPN EVPN Layer3 USG Native IP L3 LSoverGRE MPLSoverGRE MPLS NSX SDN Pod 2 EVPN EVPN EVPN VxLAN VxLAN VxLAN VxLAN VxLAN Native IP L2 Native IP L2 Native IP GRE GRE GRE Native IP L3 Native IP L3 Native IP VxLAN Internet Native IP L3 Native IP GRE GRE VxLAN MPLSover SDN USG Native IP L2 GRE GRE GRE GRE GRE GRE GRE VxLAN VxLAN Native IP L3 L2 Native IP L2 Native VxLAN VxLAN VxLAN L3 Native IP L3 Native NSX SDN Pod 2 Contrail Pod 1 L4–7 Services BRANCH OFFICES DATA CENTER 2 WAN USG

Thank you

MetaFabric Architecture

Similar presentations

Presentation on theme: "MetaFabric Architecture"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

MetaFabric Architecture

Similar presentations

Presentation on theme: "MetaFabric Architecture"— Presentation transcript:

Similar presentations

About project

Feedback