Service Provider Bridging Concepts

0:05Let's kick this playlist off with something big right out of the gate, something that's really relevant to service provider networks, and that is provider bridging. What really is provider bridging at the end of the day? Well, that's really what this entire skill is all about. We're going to be exploring how service providers can actually extend Layer 2 connectivity from one customer site all the way across their provider backbone into another customer site. We're even going to talk about what happens when more than one service provider comes into the mix. But here's the real kicker. I really wanted to start out with this topic right now, the service provider bridging, because lots of people feel like this is one of the hardest things to wrap their head around.

0:43So we need to tackle the big hard, thing first and get a major win under our belt as we progress through the service provider journey. So by the end of this skill, we'll fully understand what service provider bridging really does for us at the end of the day. What did the 802.1ad standard bring to the table? And how does a frame at a customer site make its way across a service provider's network all the way to the customer's other site? That's what this skill is going to uncover for us. So let's get going.

0:05Now here's a little story. When I first made my way into the service provider world, I actually started exploring service provider technologies thanks to Juniper and Juniper Certification Track. But coming from the Enterprise world, the service provider world really caught me off guard. And there were some of the topics that I found really, really blown away about how deep and how much planning and how much design actually goes into manipulating all of these protocols. And the one thing that really caught me off guard the most that I found most challenging to wrap my head around was actually service provider bridging.

0:36You ready for the big spoiler at the end of the day, one of the things that you need to keep in mind as you journey through service provider bridging and that will really help you get through this? It's just dot 1Q trunking at the end of the day. So in this skill, what we're going to do is we're going to take a look at what the dot 1Q protocol really brought to the table and where some of the limitations where challenges came in for a service provider's network when they wanted to extend layer 2 services to their customers. So let's recap what dot 1Q really does, how it processes a frame and tags traffic as it goes over a trunk port, and then take a look at what a service provider may think about this type of traffic as it arrives on their devices.

1:10Let's get going. So I guess we need to launch right into this and settle the score right now. What is it that provider bridging really does at the end of the day? Take a look at this topology that I'm going to be using for the upcoming Nuggets, at least in this skill and the next skill. What we're really talking about in the blue section right here is going to be a customer network. And this pink section here is going to be their actual service provider network. Now in this blue section, we have their first site, which is obviously located in a city. Now over here, we also have the exact same customer.

1:42And they have a different site. Maybe that site is located in a different city, or different state, or maybe even in a different country. Whatever the case is, in order to get traffic moving from Site A to Site B, a service provider has to help them get there. So the point of a bridge is to actually extend a layer 2 network from one end to the other. If you kind of look at it, what does this topology actually remind you of? It kind of reminds me of a bridge. We're going from one bit of land on one side of the water to another bit of land on a different side of the water.

2:18And the bridge is what actually gets us there. So yeah, do you see it? Does it make sense that at this point, what a bridge is really going to do is it's just going to give us across a service provider network. But really more specifically, what a service provider bridge is doing is it is providing layer 2 connectivity from one end to the other. And now is the part where you go think, how do they do that? Is it just a trunk port? And that really sets up the conversation about what it is that 802.1Q does and where it kind of falls short. You see, when we try to do 902.1Q trunking from one site to the next site, we found out pretty quickly that there are limitations, at least from the service provider's point of view, to actually providing just a simple layer 2 broadcast VLAN that they could send their tag traffic into, into the service provider network.

3:06Sure, we could absolutely create a trunk port, like a classic 802.1Q trunk port between this link right here. And that way traffic that originates from, say, this host here could be trunked up. And then we could just trunk it down here, then trunk it over here, then trunk it over here. And now it makes its way out. And this would behave as if our entire service provider network is nothing but switching. That is technically a solution that could fly. But we find out there are so many variables and so many problems with 802.1Q when we start talking about this.

3:37Let's talk about one of the first major issues with 802.1Q. And that's the actual tag itself. It's hard to beat Wikipedia for getting some good information about ethernet frames. And when I was in a pinch and needed, I need somebody to send me the header of a frame real quick, let's just use Wikipedia as our source to get that done. What I'm focused on right now is this piece of an Ethernet frame right here, the 802.1Q tag. Now we see that it is comprised of four octets, or it is 32 bits. And when you think about 32 bits, how many addresses is that total?

4:09That actually means there's something like 4 billion addresses that you could actually use at that point. But if we've ever worked with VLANs before, we know, wait a minute, I've never seen a VLAN 195,000 before. No, that's because the actual 802.1Q tag and the VLAN numbers that we're allowed to do-- if I give it a click here, we can scroll into it-- we can see that the actual 802.1Q header itself, right there, has these four octets defined by 1, 2, 3, 4. But the real kicker is the first octets are reserved by the tag protocol identifier.

4:43And then we see actually down here in the tag format, that the next four bits are also reserved, leaving only 12 bits that are usable for actually setting a VLAN ID. From the service provider's point of view, this means that we can only come up with 12 bits of VLAN information for all of our customers if we were to use 802.1Q trunking. So jumping back to this diagram here, what we're saying is that this customer right here, if it wanted to use 802.1Q trunking, we could assign anything within those 12 bits and tell that customer, go ahead and trunk up to us with your data tagged with a specific VLAN.

5:23So let's pretend for a moment the customer said, that's great and all, but I actually want to send three or four VLANs across this trunk port for you. And you're like, OK, go ahead and send for VLANs. The real kicker is with these 12 bits, that means we only have 4,094 usable VLAN tags that we can use. And four of those just went to one customer. Do you already see where I'm going with this? One of the biggest issues with 801.1Q is that it isn't scalable. If we are a large service provider network-- maybe we're like a huge one like AT&T, or Vodafone, or Orange, or whatever.

5:58Maybe we're a massive service provider network. If we're only allowed 4,094 VLAN tags, obviously we're going to need some of those VLANs for our own internal network and our own trunking and VLANs that we're doing. But then all of a sudden, we are limited to the amount of VLANs that we can actually use for our customers. If we have thousands of customers, for instance, if we have more than 4,094 customers, we've just run out of VLANs, even if we gave them one VLAN each. So that's a major, major problem with 802.1Q trunking, is it even though the VLAN tag itself is a 32-bit field, only 12 of those bits make up the actual VLAN number itself.

6:38And therefore, there are only 4,094 VLANs within an actual VLAN environment. And as a service provider, if we have thousands upon thousands of customers, we simply run out of VLAN tags. And therefore, that's not going to cut it for us. But let's pretend for a moment that we didn't run out of VLAN tags. And we did sell this customer its four VLANs. What is the next issue that we're going to run into, is all of a sudden, this one VLAN-- let's pretend it's VLAN 110-- this one VLAN 110 spans to here, then here, then here, then here.

7:10And what do you know about trunk ports, and routing loops, and switch loops, and frame loops? Spanning tree protocol. All of a sudden, now we have a spanning tree protocol issue, because our spanning tree protocol for this one VLAN has to span from the customer's network across our entire provider backbone, all the way into the other customer's network. Now you're thinking here, that's only five switches. What's the big deal, Knox? But in a real service provider network, how many jumps or hops or physical devices is this frame actually going to pass through?

7:44Potentially a lot. And now all of a sudden, this spanning tree environment has to span the entire duration, the entire length of this entire topology. And that becomes another major problem, because not only do we have to have spanning tree protocol able to converge and be deployed and scalable in that nature, we also have to just coordinate that many instances of spanning tree protocol against all of the different VLANs and then keep in mind like, who's going to be root bridge? And what was this customer doing again? What kind of hardware were they using? Because they might be using Cisco, and we're using Juniper, and we use different versions of spanning tree protocol.

8:19So that becomes an administrative nightmare too. Now one of the last problems with 802.1Q is think about the very processing of how a frame goes. If this device sends a ping destined to this device, and they believe they're on the same subnet, because our layer 2 topology spans that far, what does it really begin with? It begins with an ARP request, doesn't it? So that frame is going to enter right here on our provider equipment. And unless we've already learned about this Mac address 2, what is the default behavior on just VLAN switching or ethernet switching?

8:54If we don't know the outbound interface to send this on, it's going to broadcast the frame out all interfaces that are participating in the same VLAN, except, of course, the interface that the packet was received on or the frame was received on. So the frame will come in on this interface. And it'll get broadcast out all the other interfaces here. And then it'll come in on this interface. And it'll get broadcast out all the interfaces here. And then it'll come in on this interface. And it'll make its way out. Then return traffic has to make its way back in.

9:24And the broadcasts aren't necessarily the big deal. The big thing we're setting up here is our environment now has to learn about all of our customer's Mac addresses, because if we're going to be using an 802.1Q VLAN, all of the rules of ethernet switching apply here. So now in our entire provider environment, again, thinking about the fact that there could be 4,094 VLANs for all of our customers, now we have to learn all of our customer's Mac addresses. That's right.

9:55So these are some big limitations to actually using 902.1Q, the fact that we only have 4,094 VLANs that we can play with and divvy up among our customers, the fact that spanning tree protocol is going to be in play here, and we're going to have to coordinate the deployment of spanning tree protocol for the entire VLAN, because that's going to span from one customer site all the way through a backbone into the other customer site. And then lastly, we're going to have to learn all of our customer's Mac addresses to send traffic from one site to the next site.

10:25So that sets up kind of the problems with 802.1Q. Let's talk about how service providers overcame this in such a fascinatingly simple way in the next Nugget. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] For all of the awesome things that 802.1Q did for the enterprise world, allowing us to segment broadcast domains into multiple VLANs and then still be able to carry those VLANs across a trunk port by tagging it, we found out that there is a scale problem when it comes to service provider networks. They weren't able to extend layer 2 technologies all the way from one customer site to another customer site unless we had a very small number of customers actually demanding this.

0:31The issue is that that VLAN tag field is only a 12-bit field and therefore, only has 4,094 usable VLAN tags that we could actually use to help with our customers. Beyond that, we would have to coordinate things, like, MAC address table usage, as well as Spanning Tree Protocol usage across an entire infrastructure between both customers and with the service provider backbone itself. So enter 802.1ad, or what's also known as Q-in-Q technology. We're going to be talking about how 802.1ad addressed almost all of these issues, not quite all of them, but most of these issues, and is now one of the preferred ways that a service provider network can offer an EVC or an ethernet virtual connection from one customer site to another customer site.

1:15Let's get going, talking about 802.1ad. So are you ready to have your mind blown to see how service providers were able to overcome this limitation of 802.1Q? Think about this previous example that we set up here. We had our customer at this site sending in a frame. And we wanted it to make its way over to this site as if they were on the exact same layer 2 Ethernet segment. Let's pretend for a moment that this customer wanted to use the VLAN of 110. So it sends a tagged frame into our provider network, tagged with a VLAN of 110.

1:50What, then, do we do with this to make this so scalable and so simple that it actually works? We just add our own tag to it on the outside of that tag. We'll say we give this customer a tag ID of VLAN 200. That's right. That's exactly what's going to happen. And that's what the 802.1ad standard did is it created what is called Q-in-Q tunneling. That's right because it's 802.1Q tags inside of 802.1Q tags.

2:20Now, this concept may feel a little fuzzy right now. So don't worry. What we're going to do in this Nugget is now talk about how does 802.1ad really work. So in this scenario, what we as the service provider are saying is that our customer comes to us and they say they want layer 2 connectivity from this site here all the way to this site here. But they also don't want to be limited in the number of VLANs that they can actually use. So what they want to do is they really want to have the world open to them.

2:51They want to be able to use VLAN 1 through VLAN 4,094. So if we have an 802.1Q trunk right here between this link, between their customer equipment and our service provider equipment, we know that they're going to be tagging traffic as it goes up here. And it could be tagged with a VLAN of anywhere between one and 94. Let's go ahead and be really clever and call this tag the customer tag or C tag for short. And let's pretend for a moment that this device right here lives on VLAN 110.

3:26So it's going to be sending traffic in to this device and it gets tagged as it goes up to our equipment with a C tag of 110. We as a service provider do not want to have to worry about how many VLANs they want to use, nor do we want to worry about coordinating a Spanning Tree Protocol instance between them. So what we decide to do is we decide to assign this entire customer their own VLAN tag. Pretend for a moment that we say that this customer has a VLAN tag of 200. So in the Ethernet frame itself, they have sent us a frame that has a C tag of 110.

4:01And we're going to put a little tag on the outside of it. This is called the service tag or S tag for short And we're going to label it with an S tag of 200. So as the frame arrives on this device, we add the S tag of 200. And then forward it via a trunk port down to our next device. This device that sits dead center of it receives the frame and only looks at the S tag. It doesn't care about the C tag. It's only looking at the S tag.

4:31And it knows, oh, for S tag traffic, that's VLAN 200. And here are the ports that I can send VLAN 200 out of. So it sends VLAN 200 out some additional ports. And again, these devices receive the frame and see that it has an S tag of 200. But because it's also configured to know what customers it attaches to, these devices see that they are the end of the road for VLAN 200. And it removes the S tag, leaving only the customer tag.

5:03And it forwards the tagged traffic back down to this customer. So now think about it as if there were multiple hosts living off of this device. And maybe they were sending frames in on VLAN ID 113 or 493. They would all be tagged with a C tag. And then we would just drop our one S tag on the front of it. Traffic would then be forwarded via the S tag until it makes its way to the final destination, where the S tag is removed and then this device, the other customer device, inspects the C tag and sends the traffic on towards its next destination.

5:38We can see why this is called Q-in-Q tunneling, can't we? Because we have an 802.1Q tag inside of an 802.1Q tag. And pulling up trusty Wikipedia one more time, we could actually scroll down and take a closer look at the frame format here. This last frame format is the one we care about because here we've got a regular Ethernet frame. Here we've got one with an 802.1Q header. And here is an 802.1ad header. We simply have the two .1Q headers.

6:08Now, the first header that pops up here, this is the S tag. This is known as the outer tag. And this tag right here is the C tag. This is known as the inner tag. Yes, these are key terms that you should commit to memory. These are the terms that you would read in a textbook or maybe even see in an exam environment. You may see these pop up as the term S tag or C tag or you may also see them as an outer tag or an inner tag. So now, on one logical switch, what I'm saying here, that's a key term, is a logical switch, I could have 4,094 customers.

6:46And we could carry out of those customers their 4,094 VLANs because I can have 4,094 S tags. And we don't care about the inner tag or C tag that's being trafficked there. Now, to be fair, you can actually configure it to care about the C tag. We can restrict which VLANs are actually allowed to traverse through a network. And that's a bigger topic that we're going to talk about as we progress through this content. But to mark it even further, if you followed along in the JNCIA-Junos content, you learned about routing instances.

7:20And that was the ability to create separate logical routing instances or virtual instances on each one of our routers. This was like a VRF, where we could separate many different routing tables and logically separate them together. Here's the real truth. On these vMX devices or many other switching platforms, we can actually perform virtual switching. So we can have separate VLAN databases and separate MAC address tables. And therefore, there's really no limit to the amount of VLANs that we could actually configure and scale throughout our entire enterprise, except, of course, within the limitations of the physical hardware itself.

7:56We only have so much processing and RAM and disk space at the end of the day. So this introduces what 802.1ad, also known as Q-in-Q, also known as provider backbone bridging-- it's going to take me forever to write backbone here-- bridging, there we go. That's right. This does kind of have three names at the end of the day. That introduces what this technology does and how we actually turned 802.1Q into a scalable protocol that helps us move layer 2 traffic from one customer site to the other.

8:28At the end of the day, before you go on any further and you get overwhelmed with this, just remember what we're really talking about is nothing more than .1Q trunking. That's really what we're doing. We've just added one more .1Q tag onto the actual frame itself. So that introduces how service provider bridging actually works. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] So it makes sense why it's called QinQ now, right? We've got an inner Q tag, and 802.1Q tag, followed by an outer 802.1Q tag. And we know that the provider network is only going to be focused on forwarding the outer 802.1Q tag. So what we're going to do now is actually perform a frame walk, where we follow how a frame would enter the provider network and how it would be processed and forwarded one hop at a time until it reaches its final destination.

0:32So let's take a look at the path a frame would walk as it enters a provider network using 802.1ad QinQ. So we talked about this a little bit in the previous Nugget. But it bears some dedicated time in its own right. It also bears repeating because this is going to really help you solidify your understanding of how provider bridging in QinQ really works. So let's talk about how a frame would move from one end of a topology to another when we've implemented QinQ tagging, especially when we have more than one customer. So I've changed the topology up just a little bit so that we can actually see what a frame walk would look like if we had multiple customers.

1:08Let's pretend for a moment that we had our blue customer. I'm going to call it customer A. And we've decided that we want customer A to have an S tag of 300. Now we've got our green customer who's also in the mix, too. Let's say that we've got customer B and we want them to have an S tag of 400. Again, keep in mind, it's important to remember what the difference between C tags and S tags really are. The C tag is going to be the customer's tag, meaning what VLAN 802.1Q tag have they applied to the Ethernet frame versus the S tag, which is what is the frame that we actually care about?

1:46We are applying it and forwarding it through our traffic, through our network. Starting with customer 1, a frame is originated in customer 1's network over here in this site. Let's call this site 1. And it gets tagged with a C tag of 110. And it arrives inbound on our network on this switch's ge-0/0/0 interface. The customers configure their outgoing interface as an 802.1Q trunk port so that it is tagged as it arrives on our interface. Now, do we really care about what it's tagged with at this point?

2:19Absolutely not. We don't look. Our device doesn't inspect that tag at all. It looks at this interface right here and says, oh, I see this is coming in on my customer A interface. And I know that customer A really belongs to VLAN 300. So after we've configured this device to associate ge-0/0/0 here with customer A, customer A can trunk whatever they want to up to us at this point. But we know that this interface is really configured to operate in VLAN 300.

2:50So this device adds the S tag of 300 onto the frame, even though there is a C tag currently existing of 110. From there, we have trunk ports going out all of our interfaces into the provider core. Our device tags the traffic with the S tag and forwards it into the provider core. And the provider core only looks at the S tag. It only looks at the outermost tag. It may know that there is a C tag in operation because the actual tag field itself, the TPID indicates that it is an 802.1ad frame instead of an 802.1Q frame.

3:26But nonetheless, our device knows to inspect the S tag itself and says, oh, this is part of VLAN 300. Let me just forward it out all of the other interfaces that are speaking on VLAN 300, or out the destination interface if I know about the destination MAC address. So in this case, the device could send it out towards this provider device or this provider device because there are redundant uplinks into this network on the other customer's remote site. So the frame gets forwarded via the S tag information of 300 that we have set on the frame as it entered our provider network.

4:00And as it begins to exit the provider network, this device knows when it has a leg in the customer's network as well. It knows to strip the S tag off of the frame and forward the original 802.1Q tagged frame towards the host device. Now, here's the real kicker. What happens when my other customer, my green customer down here where R33 is, wants to send in a frame with a C tag of 110? It configures and 802.1Q trunk on this interface.

4:31And it sends in the tagged frame with the C tag of 110. And it receives on ge-0/0/3. Again, I can't stress this enough. This device isn't going to inspect the C tag. But rather it's going to look at how this interface is configured. ge-0/0/3 would be configured to know, oh, OK, I belong to customer B's network. And we're going to apply the S tag of 400 on this frame. So it applies the S tag of 400 to the frame and then forwards it out the exact same trunk port towards the provider core.

5:03The provider core is going to inspect that S tag of 400. And it sees, ah, I need to send this out of my interfaces that are also participating in VLAN 400. Unless, of course, it knows, again, the exact destination MAC address and the interface it should forward traffic out of that way. The whole time this is going on, all of these devices are also learning about the source MAC addresses and logging them in their MAC address table. That's right. 802.1Q solved a bunch of problems, but didn't solve every problem. The one problem that it didn't really solve is we still have to learn our customers MAC addresses.

5:37But we as service providers tend to overcome this problem by, well, billing them for that. We could charge them for a maximum number of MAC addresses. And if they go over it, we could charge them an additional amount. This is why you oftentimes see enterprises create their own dedicated VLAN specifically for traversing this backbone. And then they actually perform some form of NAT before the traffic goes outbound into this provider backbone. Nonetheless, this is a way that we can still maintain our resources at a reasonable level and not overwhelm our MAC address tables is we simply just bill for the number of MAC addresses that the customer sent in into our network.

6:14So as traffic is originated and sent into the network, our devices are going to learn about the source MAC addresses. And when it doesn't know about the destination MAC address, it performs the exact same flooding that you would expect before. It's just flooded based on the S tag's VLAN. Of course, as return traffic is sent back, all of our devices are learning about that destination MAC address or that source MAC address as well. And that way it keeps these MAC addresses in their MAC address tables. And then next time we have to forward traffic between sites, it will go much quicker because we're not having to wait for ARP replies and such like that.

6:47So this is covering the actual frame walk of an 802.1ad or QinQ environment. The big thing to keep in mind is that the interfaces themselves are what the provider network device knows to inspect and look at the configuration of in order to actually set the S tag. It doesn't care about the C tag unless we explicitly configure it to only allow specific certain C tags. And there are some use cases for that that we'll eventually get into. For now, that is 802.1ad end-to-end. I hope this has been informative for you. And I'd like to thank you for viewing.

0:05Now here's the next thing that really catches newcomers to the service provider world off guard. We already thought we've learned every networking acronym there is to know because we came from the enterprise world, and what you find out very quickly is you haven't. The service provider world is an entirely different world, and there is plenty of alphabet soup out there for you to learn. Provider bridging is not an exception to that. There are some key terms and some key acronyms that you will absolutely need to commit to memory because this is what you'll read in textbooks. This is what you'll see on exams, and this is what you'll hear me say throughout the upcoming Nuggets that we have within this skill and many other skills that are centered around service provider networking.

0:42So let's keep going talking about some of the key terms and acronyms that you will encounter when you talk about provider bridging in the real world. Let's get going. Yep. There's no escaping it. We have some key terms that we have to learn about some jargon, some service provider world usages that you'll see. Whenever you join a service provider network for the first time, you will be overwhelmed with the number of acronyms and crazy things that they actually do. So this is where we're going to get started learning about our first service provider key terms. What we're looking at here is an ethernet virtual connection, or EVC.

1:16This is the service that we're actually trying to provide to our customers. What they would try and say is we just want a layer two connection for one site to the next, and we would hand them a pamphlet that says what you're really talking about is an ethernet virtual connection. This is what would be on their bill. We're selling them an ethernet virtual connection, and the entire network or the entire domain that we manage here is called the provider bridge network. That's what this entire pink section is. Everything that is under our control as a service provider and participates in the service provider bridging, or the EVC, this is part of the provider bridge network.

1:54Now, the device that we're going to be connecting to, the customer's device, this is called the customer edge, and this is probably familiar to you if you've ever worked with MPLS or MPLS layer 3 VPN. The terminology doesn't change a whole lot here. All of the customer's equipment that we actually connect to is the customer's edge device because this is the edge of their network. They have a whole bunch of devices on the inside of that, but this is the actual edge, and this is as far as we go when it comes to caring about what goes on in their network.

2:24The network devices that we are providing for them to connect to, or the devices that they think they are connecting to, is oftentimes referred to as the provider edge. But specifically, when we're talking about bridging, we are talking about the provider edge bridge. So these four devices here that my customers are connecting to are provider edge bridges. And specifically, the ports that they're connecting in on-- we see we've got these ports all that I'm highlighting right here-- these are called customer ports.

2:56So we've got ge-0/0/0, ge-0/0/3, ge-0/0/0, ge-0/0/3, ge-0/0/0, ge-0/0/3, ge-0/0/0, and ge-0/0/3. All of the ge-0/0/0s and ge-0/0/3s on my PEBs are customer ports, whereas all of the devices that are interconnecting my provider bridges-- that's a connection like right here between a provider edge bridge or a connection right here between the provider edge bridge in the core-- these are simply called network ports, very simple.

3:31Now, lastly, we have in the center of our provider bridge network, we have these core devices. And if you recall, based on the frame law, these devices only care about the S-VLAN tags themselves. These devices will almost never ever, ever inspect the C tag in forward based on the C tag. These devices that are only in the center of the network and are forwarding S tag frames are oftentimes called to S-VLAN bridges because they only participate in the S-VLAN.

4:03They only care about the S tag on the ethernet frame itself. So these are some of the key terms about all of the components and moving parts that actually make up a EVC, an ethernet virtual connection, and this is all of the stuff that goes on in a PBN. We've got the PEBs. We got the provider bridges. We've got the S-VLAN bridges. We have customer ports, and we have network ports. So that's been the terms that you need to know about when you're actually talking about how to deploy Q and Q environment. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] There are some more key terms that we need to talk about but we're not going to talk about them in this Nugget. What we actually have to do in this Nugget is set up the reason that we have more key terms that I'm about to define for you. What I'm really talking about here is what happens when a service provider has to forward frames to a different service provider? Or maybe a service providers business unit has to forward frames to a different business unit in the same service provider.

0:31What we're really talking about here is what happens when we have VLAN mismatches when those S-tag as we transmit S-tag data from one service provider network to a different service provider network. Let's talk about the scenario about what to do when there are two service providers in play within a single customer's ethernet segment. Let's get going. So this example has been great up until this point because we've used it to talk about how a service provider could provide an EVC to its customers. That way, a customer who has a location here in this city and maybe has a location here in the exact same city, they could provide pretty simply layer two connectivity from one site to the next.

1:09But what happens when customers start to spread out a little more? Maybe they're not in the same city. Maybe they're not even in the same state. Maybe they're not even in the same country. What happens then when the enterprise wants to actually still provide a layer two connectivity from one side to the next but now we don't actually have autonomy in their remote site? We now have to partner with other service providers and this could come into some more coordination issues. Here's how we can actually go about making this work and setting up the next Nugget where we talk about some more key terms that actually goes with deploying Q-in-Q Now, what we're working with is that we have a scenario where we have one service provider, I'll call the service provider one.

1:49And now, in this new box, we have a service provider two. Our customer is still the same. Well, actually are both of our customers are still the same. They still have the blue customer and the green customer. And they still have one site here and one site here. And they still want layer two connectivity from this device over here to this device. But what happens now is we have this particular issue here. The good news is, is in both service provider environments. If they're willing to work together and make this happen, they're still just going to use Q-in-Q. That's right.

2:19We're still only talking about forwarding traffic based on S-tags. The coordination problem that we run into oftentimes is that service provider one may give this customer the S-tag of 300. Whereas service provider two may give that customer the S-tag of 396. Just to make something random up. So as they send in their traffic, it may come in with a C-tag one more time of 110. It'll be arriving right here on this interface where the S-tag tag of 300 is applied and forward it out of this interface.

2:55Now, what has to happen is right here on this device that sits on the edge. A translation will have to occur. And this is as simple as performing a VLAN translation. It's just like NAT for IP addresses. We would explicitly configure this device that sits in the core to inspect anything with the S-tag of 300 and dust outbound towards this network. Swap the 300 tag for 396 and vise versa.

3:26Any traffic that arrives inbound from this network with an S-tag of 396, swap it for 300 and then go about performing the forward lookup. So from here, this service provider would be receiving an S-tag of 396 because the core device that sits in the center already swapped out our S-tag of 300 for the S-tag of 396. So in this device receives the S-tag of 396, it knows to perform the VLAN forwarding based on the S-tag And in this case, it may actually strip off that S-tag and forward the 802.1Q frame on to the customer in blue.

3:58So this is actually another major talking point about Q-in-Q. Q-in-Q actually set up the functionality to allow for changing the VLAN tags themselves. That's right. We're actually pulling off VLAN tags. We're stripping them off and then replacing them as they go on the fly. And the big thing that now we want to talk about, it makes sense when we explore this as a service provider to service provider communication. I mean, we've seen it already up until this point, where we had a service provider one, maybe this was something like AT&T. And then service provider two, maybe this is something like Verizon.

4:30It makes sense that they would never or rarely assign the exact same customer the exact same S-tag. And therefore, some translation would have to happen along the way to actually make this connectivity work. But what could actually happen is that these are actually the same service provider. That could actually happen and this is one business unit. And this is a completely separate business unit. It's unlikely that a large nationwide service provider has the exact same VLAN or the exact same numbering scheme or naming scheme from one state to the next.

5:02As traffic transits across the country even within the same service provider, there's a chance that it will leave the autonomous system or an autonomous boundary and transition into a different networking team's infrastructure and a translation would still need to occur in this case. So keep in mind that when you join the service provider world, yeah, absolutely, when you have a coordination attempt between two different service providers, there's probably going to be a translation that takes place. But if you're joining a large service provider that spans multiple geographies, there's still a pretty high chance that translation needs to take place in your provider bridging solution.

5:40So a cool thing about EVCs is that customers who span from one corner of the country to the other could still possibly receive an EVC solution through the coordination of multiple service providers working together and creating VLAN translations of the S-tag as they go on the fly. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] In the previous Nugget, we introduced the concept of VLAN translation. And it makes a lot of sense-- that is one provider needs to send traffic to a different provider, but they're using two different S-VLAN tags, or S-tags. We need to coordinate the translation from one network to the next network and vise versa. So now what we're going to talk about is how does that translation actually occur, and what are the key terms that are centered around changing the actual VLAN tags themselves on these ethernet frames?

0:33Let's get going talking about the key terms centered around VLAN translation and, ultimately, how we can manipulate the actual tags themselves. Let's go. So in the previous Nugget, I made sure-- or tried really hard, at least-- not to spoil or give away any of the key terms. But it's really important that when we talk about removing or changing VLAN tags, we really need to have these key terms drilled into our memory because these are actual words that service provider network engineers speak. These are the actual words that you will see on exam environments or read in textbooks.

1:06So make sure that you learn these words and commit them to memory when you're talking about things like service provider bridging as well as MPLS. You're going to see these words pop up one more time. The three words that are really coming into play here are pop, push, and swap. Let's start off with pop. What we're really talking about here is when this host, Docker30 here, sends a frame into the network, it gets tagged, and it comes all the way up to the edge. And now it's time to remove that S-tag so that only the C-tag remains.

1:40That is a pop operation. We're popping the top off. We're popping that outer tag, the S-tag, out of the ethernet frame itself, leaving only the C-tag behind. And then, we forward it on. That is a pop operation. Commit that to memory, because it's an important one to know. But what about when we added the S-tag frame on? The frame was sent via an 802.1Q trunk port up to our device and, at the time, it only contained the C-tag. Before it left our PEB, or provider edge bridge, we had to push a tag onto the device.

2:15This is the add operation. So under pop, I'll just go ahead and put this now for cleanliness sake. We've got the remove tag operation. Under push, we've got the add tag operation. And this is where we push the S-tag. Then, lastly, we have the swap operation, and that's what occurred right here. This is where we actually did kind of a pop-push. We popped the S-tag off, and then pushed a new S-tag on. They simplify that by calling it a swap. So in this case-- we set it up in the previous example-- we had an S-tag of 300 that was pushed onto the frame as it arrived in our provider bridge network.

2:54We forwarded the frame based on VLAN 300 information. The S-VLAN bridge received it, and it knows, based on the configuration, that it's time to swap the frame. So it performs the swap operation, which under the hood, is popping 300 and pushing-- we pushed 396 in the previous example. And then, the 396 frame moves forward into the new provider network. The provider edge bridge, or PEB, device in the new provider edge network performs the penultimate pop operation, leaving only the C-tag, and then forwards it into the customer's network.

3:29And that sets up the three different types of operations that you will encounter in the service provider bridging technologies. But here's the real kicker, now it's time to talk about it even a little bit more. We can take these three technologies and perform combo moves, so to speak. And you will also encounter these in the real world. So there is such a thing as pop-pop. This is where we remove the outer tag and also remove the inner tag. There is also pop-swap. This is where we remove the outer tag and swap the inner tag.

4:04There is a swap-swap. This is where we swap the outer tag as well as swap the inner tag. Now, I'll let you figure out what is a push-push. Go ahead and pause the video and take a moment to think about it. [MIMICKING "JEOPARDY" THEME] This is where we add both an inner tag and an outer tag to an Ethernet frame. So this is covering the key terms that you need to know about when it actually comes time to translate a VLAN S-tag or C-tag. We have the ability to control all of the information as it traverses through our entire network.

4:39So we can not only pop the S-tag and swap the S-tag or push as S-tag, we can also manipulate the C-tag if we actually have a use case for doing that. And these are the three key terms that you really need to commit to memory when it comes time to talk about VLAN translation. I hope this has been informative for you, and I'd like to thank you for viewing.

0:05Now, this last Nugget is a little bit of lagniappe for you. It's nothing much more than good-to-know information there's not a whole lot that you really need to dig too deep into this. But the big thing that I wanted to set you up for is really what happens when you go out there in the real world and start working in service provider networks, or you go beyond the JNCIS and you go towards the JNCIP or the JNCIE. One of the things that you'll find out really quick is that 802.1ad and QinQ is not the most widely deployed service provider-bridging technology that's out there.

0:36What you actually may run into is something called VPLS. Let's talk a little bit more about what VPLS does for us at the end of the day in a service provider network. Let's go. Now, the last thing I wanted to talk about here was VPLS, because it is true that in the actual service provider world, this is becoming the more prominent way to provide Layer 2 private VPN technologies to our customers. We're talking about a different way to perform EVCs, or Ethernet Virtual Connections. What really goes on here is that we have a logical infrastructure here that provides a backbone that looks something like this.

1:10To our customers, they only see this as a Layer 2 broadcast segment, not really any differently than QinQ technologies. But what really goes on here, is we're not eating up all of our VLAN space. We're not actually performing QinQ tunneling. What we're really doing here is leveraging functionalities of MPLS, as well as the IGPs themselves, like OSPF and ISIS. In order to actually deploy VPLS, well, you're really starting to break into not only JNCIP technologies and topics, we're actually talking more into JNCIE technologies and topics, because it is heavy, heavy, heavy, on MPLS and traffic engineering the correct label switched paths.

1:54We haven't talked about all those yet. We will talk a lot about the MPLS, label switch paths, and traffic engineering using the RSVP protocol, as well as variations of these IGPs, ultimately resulting in CSPF. Don't worry about this too much. We're going to talk all about it. And it will set you up for success when you start to get into VPLS, should your studies actually take you that far. Just know that VPLS is an alternative to 802.1ad and QinQ, and it relies heavily on MPLS.

2:24But from the customer's point of view, it still looks the exact same. It's like one gigantic ethernet broadcast network, where they can see all of their different sites and VLANs and connect to each other through Layer 2 technologies as a flat network. That's just a brief primer on what VPLS does. It really just leverages MPLS in order to provide the exact same EVC as QinQ. I hope this has been informative, for you and I'd like to thank you for viewing.

0:05I know you're dying to see configurations right now, because you're like, oh, oh, let's see it in action. Let's make some packets flow. And I am too. Deploying these configurations on a Juniper device is kind of a big thing. There's a lot of stuff that's going on here. And that's why we've got an entire skill dedicated to the deployment of service provider bridging coming up next in this playlist. For now, we needed to introduce all of these core concepts and really lay the foundation for the fact that the service provider world is totally different. We're now looking at networking from an entirely different lens than we may have been when we were in the enterprise world.

0:39So we've introduced the core concepts of what provider bridging does. What problems did it really solve with 802.1Q? And then we talked about, how is the 802.1ad system really deployed throughout this enterprise, how does a frame flow from one hop to the next, and then even talked about some things like, what do we do when there's multiple service providers in the mix here. And we talked about then we could do things like VLAN translation. So this sets up the foundations for service provider networking and service provider bridging. I hope this has been informative for you, and I'd like to thank you for viewing.