Tải bản đầy đủ - 0 (trang)
Chapter 2. Bridging, VLAN Mapping, IRB, and Virtual Switches

Chapter 2. Bridging, VLAN Mapping, IRB, and Virtual Switches

Tải bản đầy đủ - 0trang

There’s no distinction between the terms “bridging” and “switching,”

and they are used interchangeably in this book.

It’s always helpful to see an illustration, so take a moment with Figure 2-1.

Figure 2-1. Traditional switch compared to the Juniper MX

On the left of Figure 2-1 is a traditional switch that simply supports a single Layer 2

network; within this Layer 2 network is support for 4,094 VLAN IDs and some IRB

interfaces. To the right is the Juniper MX. It takes the concept of a traditional switch

and virtualizes it to support multiple Layer 2 networks. This provides the ability to

provide service to multiple customers with overlapping VLAN IDs.

For example, customer Green could be assigned to the upper Layer 2 network in the

illustration, while customer Orange could be assigned to the lower Layer 2 network.

Both customers could use identical VLAN IDs and MAC addresses without any issues

using this architecture. To make it more interesting, there could be four additional

customers requiring Layer 3 network services. Each customer could have overlapping

IP addresses and wouldn’t cause an issue.

Because of the level of virtualization, each customer is unaware of other customers

within the Juniper MX. This virtualization is performed through the use of what Junos

calls a routing instance. When you create a routing instance, you also need to specify

what type of routing instance it is. For example, if you wanted to create a Layer 2 routing

instance, the type would be virtual-switch, whereas a Layer 3 routing instance would

be a virtual-router.

The final piece of virtualization is the separation of bridge domains and learning domains. A learning domain is simply a database of Layer 2 forwarding information.

72 | Chapter 2: Bridging, VLAN Mapping, IRB, and Virtual Switches


Typically, a learning domain is attached to a bridge domain in a 1:1 ratio. A traditional

switch will have a learning domain for every bridge domain. For example, VLAN ID

100 would have a single bridge domain and learning domain. The Juniper MX is able

to have multiple learning domains within a single bridge domain. This creates interesting scenarios such as creating a single bridge domain that supports a range of VLAN

IDs or simply every VLAN ID possible. It might be a bit difficult to wrap your head

around this at first, but this book will walk you through every step in the process.

Layer 2 Networking

Let’s take a step back and review what exactly a Layer 2 network is. This chapter introduces a lot of new topics related to Layer 2 switching in the MX, and it’s critical that

you have an expert understanding of the underlying protocols.

Specifically, we’ll take a look at Ethernet. A Layer 2 network, also known as the data

link layer in the seven-layer Open Systems Interconnection (OSI) model, is simply a

means to transfer data between two adjacent network nodes. The feature we’re most

interested in is virtual local area networks (VLANs) and how they’re processed.

A bridge domain is simply a set of interfaces that share the same flooding, filtering, and

forwarding characteristics. A bridge domain and broadcast domain are synonymous in

definition and can be used interchangeably with each other.

Ethernet II

By default, an Ethernet frame isn’t aware of which VLAN it’s in as there’s no key to

unique identify this information. As the frame is flooded, filtered, or forwarded, it’s

done so within the default bridge domain of the interface. Let’s take a look at the format

of a vanilla Ethernet II frame.

Figure 2-2. Ethernet II frame format

There are seven fields in an Ethernet II frame: preamble, start frame delimiter (SFD),

destination address (DA), source address (SA), type, data, and frame check sequence

(FCS). Let’s take a closer look at each.


This eight-octet field is used by hardware to be able to easily identify the start of a

new frame. If you take a closer look, it’s actually two fields: preamble and SFD.

The preamble is seven octets of alternating 0s and 1s. The SFD is a single octet of

1010 1011 to signal the end of the preamble, and the next bit is immediately followed by the destination MAC address.

Layer 2 Networking | 73


Destination Address

The destination MAC address is six octets in length and specifies where the Ethernet frame is to be forwarded.

Source Address

The source MAC address is six octets in length and specifies the MAC address from

which the Ethernet frame was originally sent.


The EtherType is a two-octet field that describes the encapsulation used within the

payload of the frame and generally begins at 0x0800. Some of the most common

EtherTypes are listed in Table 2-1.

Table 2-1. Common EtherTypes




Internet Protocol Version 4 (IPv4)


Internet Protocol Version 6 (IPv6)


Address Resolution Protocol (ARP)


MPLS unicast


MPLS multicast


Jumbo Frames


IEEE 802.1Q (VLAN-tagging)


IEEE 802.1QinQ


This field is the only variable length field in an Ethernet frame. Valid ranges are 46

to 1500 octets, unless Jumbo Frames are being used. The actual data being transmitted is placed into this field.

Frame Check Sequence

This four-octet field is simply a checksum using the cyclic redundancy check (CRC)

algorithm. The algorithm is performed against the entire frame by the transmitting

node and appended to the Ethernet frame. The receiving node runs the same algorithm and compares it to the FCS field. If the checksum calculated by the receiving node is different than the FCS field on the Ethernet frame, this indicates an

error occurred in the transmission of the frame and it can be discarded.

IEEE 802.1Q

Now let’s take a look at how it’s possible for an Ethernet II frame to suggest which

VLAN it would like to be in because, as you will see later in this chapter, it’s possible

to configure the MX to normalize and change VLAN IDs regardless of the IEEE 802.1Q

header. The IEEE 802.1Q standard defines how VLANs are supported within an

Ethernet II frame. It’s actually an elegant solution because there’s no encapsulation

74 | Chapter 2: Bridging, VLAN Mapping, IRB, and Virtual Switches


performed and only a small four-octet shim is inserted between the Source Address and

Type fields in the original Ethernet II frame, as shown in Figure 2-3.

Figure 2-3. Ethernet II and IEEE 802.1Q frame format

This new four-octet shim is divided into two major parts: tag protocol identifier (TPID)

and tag control identifier (TCI). The elegant part about the TPID is that it actually

functions as a new EtherType field with a value of 0x8100 to indicate that the Ethernet

II frame supports IEEE 802.1Q. Notice that both the EtherType in the original Ethernet

II frame and the new TPID field in the new IEEE 802.1Q frame begin at the exact same

bit position. The TCI is subdivided into three more parts:

Priority Code Point (PCP)

These three bits describe the frame priority level. This is further defined by IEEE


Canonical Format Indicator (CFI)

This is a one-bit field that specifies which direction to read the MAC addresses. A

value of 1 indicates a noncanonical format, whereas a value of 0 indicates a canonical format. Ethernet and IEEE 802.3 always use a canonical format and the least

significant bits first, whereas Token Ring is the opposite and sends the most significant bit first. This is really just an outdated relic and the CFI will always have

a value of 0 on any modern Ethernet network.

VLAN Identifier (VID)

The VID is a 12-bit value that indicates which VLAN the Ethernet frame belongs

to. There are 4,094 possible values, as 0x000 and 0xFFF are reserved.

IEEE 802.1QinQ

The next logical progression from IEEE 802.1Q is IEEE 802.1QinQ. This standard

takes the same concept of inserting a four-octet shim and expands on it. The challenge

is, how do you allow customers to operate their own VLAN IDs inside of the Service

Provider’s network?

Layer 2 Networking | 75


The solution is just as elegant as before. IEEE 802.1QinQ inserts an additional fouroctet shim before the IEEE 802.1Q header and after the source MAC address, as shown

in Figure 2-4.

Figure 2-4. IEEE 802.1QinQ frame format

The IEEE 802.1QinQ frame now has two four-octet shims. The first four-octet shim is

known as the Service Tag (S-TAG) or outer tag. The second four-octet shim is called

the Customer Tag (C-TAG) or inner tag.

The S-TAG has an EtherType of 0x88A8 to signify the presence of an inner tag and

indicate that the frame is IEEE 802.1QinQ. The S-TAG is used to provide separation

between different customers or Ethernet services.

The C-TAG has an EtherType of 0x8100 to indicate that the frame supports IEEE

802.1Q. The C-TAG represents the original customer VLAN ID.

For example, let’s assume there are two customers: Orange and Blue. Let’s say that

each of the customers internally use the following VLAN IDs:


The Orange customer uses VLAN ID 555.


The Blue customer uses VLAN ID 1234.

Now let’s change the point of view back to the Service Provider, who needs to assign

a unique VLAN ID for each customer; say, customer Orange VLAN ID 100 and customer Blue VLAN ID 200.

What you end up with are the following frame formats:

Customer Orange

S-TAG = 100, C-TAG = 555

Customer Blue

S-TAG = 200, C-TAG = 1234

76 | Chapter 2: Bridging, VLAN Mapping, IRB, and Virtual Switches


This allows Service Providers to provide basic Layer 2 Ethernet services to customers

while maintaining the original VLAN IDs set by the customer. However, there a few


Maximum of 4,094 customers or S-TAGs

Because each customer would be mapped to an S-TAG, the maximum number of

customers supported would be the 4,094. You can calculate this scaling issue with

the following formula: customers = (2^12) – 2. Recall that the VID is 12 bits in

width and the values 0x000 and 0xFFF are reserved.

MAC learning

Because the customer destination and source MAC addresses are still present in

the IEEE 802.1QinQ frame, all of the equipment in the Service Provider network

must learn every host on every customer network. Obviously, this doesn’t scale

very well, as it could quickly reach the maximum number of MAC addresses supported on the system.

To be fair, a new standard IEEE 802.1AH (MAC-in-MAC) was created

to help alleviate the drawbacks listed previously. However, many Service Providers have opted to move straight to MPLS and provide VPLS


Junos Interfaces

Before discussing bridging, a closer look at how Junos handles interfaces is required.

Bridging on the MX is fundamentally different than on the EX due to the types of

challenges being solved. As you move into the finer points of bridging and virtualization

within the MX, it’s critical that you have a clear understanding of how interfaces are

created and applied within bridge domains, routing instances, and other features.

Let’s take a look at a single, generic interface that supports multiple units, families, and

addresses in Figure 2-5.

Junos Interfaces | 77


Figure 2-5. Junos interface hierarchy

Interface Device (IFD)

This represents the physical interface such as xe-0/0/0. This is the root of the hierarchy and all other components are defined and branched off at this point. Features such as maximum transmission unit (MTU), link speed, and IEEE 802.3ad

are configured at this level.

Interface Logical (IFL)

The IFL simply defines a unit number under the IFD such as xe-0/0/0.0 or

xe-0/0/0.1. Regardless of the configuration, at least a single unit is required. A

common example of multiple IFLs are VLAN ID when using IEEE 802.1Q.

Interface Family (IFF)

Each IFL needs an address family associated with it, as Junos supports multiple

protocols. Common examples include inet for IPv4, inet6 for IPv6, and iso when

configuring the IS-IS routing protocol.

Interface Address (IFA)

Finally, each IFF needs some sort of address depending on the type of IFF configured. For example, if the IFF was configured as inet, an address might look like, whereas if the IFF was configured as inet6, an address might look

like 2001:DB8::1/128.

Let’s piece the puzzle together and see what it looks like by configuring the interface

xe-0/0/0 with an IPv6 address 2001:DB8::1/128, shown in Figure 2-6.

78 | Chapter 2: Bridging, VLAN Mapping, IRB, and Virtual Switches


Figure 2-6. IFD, IFL, IFD, and IFA example set commands

Given the logical hierarchical structure of the interfaces within Junos, it’s easy to see

how each section is nicely laid out. This is a perfect example of taking a complex problem and breaking it down into simple building blocks.

Although the Junos interface structure is a good example, the same principles apply

throughout the entire design of Junos. It’s very natural and easy to understand because

it builds upon the good tenets of computer science: divide and conquer with a hierarchical design. For example, enabling IEEE 802.1Q on interface xe-0/0/0 and supporting two VLAN IDs with both IPv4 and IPv6 would look something like Figure 2-7.

Figure 2-7. IFD, IFL, IFF, and IFA hierarchy with IPv4 and IPv6 families

Junos Interfaces | 79


Interface Bridge Configuration

The MX supports two methods of configuring interfaces for bridging, and each method

has its own benefits and drawbacks. One method is geared for more control but requires

additional configuration, and the other method is geared toward ease of use but offers

less functionality. Both methods are covered in detail.

Service Provider Style

As mentioned previously in this chapter, Service Providers have very unique challenges in terms of providing both scale and Ethernet-based services to their customers. Such a solution requires extreme customization, flexibility, and scale. The

drawback is that when crafting advanced bridging designs, the configuration becomes large. The obvious benefit is that all bridging features are available and can

be arranged in any shape and size to provide the perfect Ethernet-based services

for customers.

Enterprise Style

Typical Enterprise users only require traditional switching requirements. This

means a single Layer 2 network with multiple bridge domains. Because the requirements are so simple and straightforward, the Juniper MX offers a simplified

and condensed method to configure Layer 2 interfaces.

Basic Comparison of Service Provider versus Enterprise Style

Let’s start with a very basic example and create two bridge domains and associate two

interfaces with each bridge domain, as shown in Figure 2-8, which would require the

interfaces to use VLAN tagging.

Figure 2-8. Two interfaces and two bridge domains

Service Provider Style

This style requires explicit configuration of each feature on the interface. Once the

interfaces are configured, each bridge domain needs to explicitly reference the interface

as well. Let’s review the interface requirements:

80 | Chapter 2: Bridging, VLAN Mapping, IRB, and Virtual Switches



This option modifies the IFD to operate in IEEE 802.1Q mode, also known as a

trunk interface.


This encapsulation is applied to the IFD to enable bridging on all IFLs.


Each VLAN ID that needs to be bridged is required to be broken out into its own

IFL. It’s common practice to name the unit number the same as the VLAN ID it’s

associated with.

Armed with this new information, let’s take a look at how to configure two interfaces

for bridging across two bridge domains:

interfaces {

xe-0/0/0 {


encapsulation extended-vlan-bridge;

unit 100 {

vlan-id 100;


unit 200 {

vlan-id 200;



xe-0/0/1 {


encapsulation extended-vlan-bridge;

unit 100 {

vlan-id 100;


unit 200 {

vlan-id 200;




bridge-domains {

VLAN-100 {

vlan-id 100;

interface xe-0/0/0.100;

interface xe-0/0/1.100;


VLAN-200 {

vlan-id 200;

interface xe-0/0/0.200;

interface xe-0/0/1.200;



As you can see, each IFD has vlan-tagging enabled as well as the proper encapsulation,

as shown in Figure 2-9. Each VLAN ID is broken out into its own IFL.

Interface Bridge Configuration | 81


The bridge domain configuration is very easy. Each bridge domain is given a name,

VLAN ID, and a list of interfaces.

Enterprise Style

This style is very straightforward and doesn’t require explicit configuration of every

feature, which reduces the amount of configuration required, but as you will see later

in this chapter, also limits the number of features this style is capable of.

Let’s review the interface requirements:


Each IFL requires family bridge to be able to bridge.


Each IFL requires the interface-mode to indicate whether the IFD should operate

as an access port (untagged) or trunk (IEEE 802.1Q).


Each IFL requires a vlan-id to specify which bridge it should be part of.

Sounds easy enough. Let’s see what this looks like compared to the previous Service

Provider style:

interfaces {

xe-0/0/0 {

unit 0 {

family bridge {


vlan-id-list [




xe-0/0/1 {

unit 0 {

family bridge {


vlan-id-list [





bridge-domains {

VLAN-100 {

vlan-id 100;


VLAN-200 {

vlan-id 200;




100 200 ];


100 200 ];

That’s a pretty big difference. There are no more options for vlan-tagging, setting the

encapsulation type, or creating an IFL for each VLAN ID. Simply set the interfacetype to either access or trunk, set a vlan-id or vlan-id-list, and you’re good to go.

82 | Chapter 2: Bridging, VLAN Mapping, IRB, and Virtual Switches


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 2. Bridging, VLAN Mapping, IRB, and Virtual Switches

Tải bản đầy đủ ngay(0 tr)