Extended VLAN Bridge

up2thetime

Hey...

Another question on configuring bridging.

Take a look at this code please:

interfaces {
xe-0/0/0 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 100 {
vlan-id 100;
}
unit 200 {
vlan-id 200;
}
}


Okay…

So according to Reynolds...

vlan-tagging:
This option modifies the IFD to operate in IEEE 802.1Q mode, also known as a trunk interface.

extended-vlan-bridge:
This encapsulation is applied to the IFD to enable bridging on all IFLs.

According to Juniper's website, extended-vlan-bridge is used to:
Use extended VLAN bridge encapsulation on Ethernet interfaces that have IEEE 802.1Q VLAN tagging and bridging enabled and that must accept packets carrying TPID 0x8100 or a user-defined TPID.

These commands seem redundant to me. The command vlan-tagging modifies the physical interface to operate it 802.1Q mode, and the command extended-vlan-bridge is, according to Juniper's definition, used on interfaces that must accept packets carrying TPID 0x8100.

If enabling vlan-tagging modifies the interface to operate in 802.1Q mode, then doesn't that imply that the interface should accept 802.1Q packets since that what VLAN Tagging is? Why is a second command of extended-vlan-bridge needed?

This is very confusing...

tomtom1

vlan-tagging sets the physical interface in dot1q trunking mode (so, to accept frames entering with dot1q tags) and encapsulation extended-vlan-bridge (or encapsulation vlan-bridge) sets the logical interfaces under the physical interfaces to accept dot1q frames. So with this configuration, you can create subunits 100 and 200 and use vlan-id 200 to identify match the subunits to a given dot1q tag in the frame.

Cisco doesn't have this type of logic (in the other topic you mentioned you're from a Cisco world) applied to there configuration, but in JunOS there is a separation between a physical and a logical interface. For example, this is something you can easily configure with an MX:

# show interfaces xe-2/0/2                                           
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 200 {
    family bridge {
        ##
        ## Warning: interface-mode access is allowed only for untagged interfaces
        ##
        interface-mode access;
        vlan-id 200;
    }
}
unit 300 {
    vlan-id 300;
    family inet {
        address 3.3.3.3/32;
    }
}
unit 400 {
    encapsulation vlan-vpls;
    vlan-id 400;
}

So under one physical interface, we have a VPLS access port(encapsulation vlan-vpls), a routed port (family inet) and a L2 port (family bridge). Because the physical and logical interfaces are decoupled in JunOS, this allows for greater flexibility, but it can appear like things need to be configured double, while some parts of the configuration (flexible-vlan-tagging) apply to the physical interface, others apply to the logical interface.

up2thetime

tomtom1 wrote: »

So with this configuration, you can create subunits 100 and 200 and use vlan-id 200 to identify match the subunits to a given dot1q tag in the frame.

Thanks so much for the explanation. I think it's starting to make a bit more sense. Could you explain a bit more in regards to the quote above please? Specifically why would you want to create subunits on a trunk interface? Does this mean that when a frame enters with Tag 100, it will be processed by the IFL subunit?

tomtom1 wrote: »

So under one physical interface, we have a VPLS access port(encapsulation vlan-vpls), a routed port (family inet) and a L2 port (family bridge). Because the physical and logical interfaces are decoupled in JunOS, this allows for greater flexibility, but it can appear like things need to be configured double, while some parts of the configuration (flexible-vlan-tagging) apply to the physical interface, others apply to the logical interface.

Does this mean that you can have one interface functioning as a layer 3 routing interface and as a trunk? If so, this is a totally new concept to me. With Cisco switches you don't divide your trunk up into sub-interfaces. As I'm sure you know, you create the trunk, define the VLANs on it, and if you need routing capabilities, you create an SVI. I think this is where my problem is. I'm trying to relate sub-interfaces from Cisco to Units in Juniper.

tomtom1

up2thetime wrote: »

Thanks so much for the explanation. I think it's starting to make a bit more sense. Could you explain a bit more in regards to the quote above please? Specifically why would you want to create subunits on a trunk interface? Does this mean that when a frame enters with Tag 100, it will be processed by the IFL subunit?

Correct. If you use the flexible-ethernet-services encapsulation on a physical interface, you can create subunits and associate each subunit with a different family / encapsulation. Take a look at the config I posted. Under 1 physical interface, we can create IFL's that route traffic (family inet), bridge traffic (family bridge) and use MPLS applications (encapsulation vlan-vpls) uniquely identified by a vlan tag on a IFL.

up2thetime wrote: »

Does this mean that you can have one interface functioning as a layer 3 routing interface and as a trunk? If so, this is a totally new concept to me. With Cisco switches you don't divide your trunk up into sub-interfaces. As I'm sure you know, you create the trunk, define the VLANs on it, and if you need routing capabilities, you create an SVI. I think this is where my problem is. I'm trying to relate sub-interfaces from Cisco to Units in Juniper.

If by trunk you mean bridge then yes. The MX series also support the concept of an SVI with an IRB, which you configure in a bridge domain, but an IFL on which family inet is enable is a routed port (in Cisco terms, no switchport). JunOS and especially one of their most versatile platforms, the MX, takes some time to get used too, but it offers much more flexibility than any Cisco I've seen. Don't know if the ASR can do such things, as far as I know they can't.

up2thetime

tomtom1 wrote: »

If by trunk you mean bridge then yes.

Is there a difference? I don't understand what the difference would be in this case. Could you please explain?


In my other post, you said this:

tomtom1 wrote: »

The way I understand it is that a bridge domain is basically a set of ports that share the same flooding and learning capabilities. If you configure multiple VLANs (so not VLAN all) for a bridge domain, a separate bridge and learning domain is actually created per VLAN.

So in this example, a bridge domain is a set of IFLs that share the same flooding domain and MAC database. If we configure multiple VLANs, then a separate bridge domain is created for every VLAN. Here is what I don't understand… You say we are creating separate bridge domains per VLAN. How is the bridge domain different from the VLAN itself? A VLAN is a group of ports that share the same flooding and learning capabilities. Based on your above definition, a bridge domain is also a set of ports that share the same learning and flooding capabilities. See my confusion between understanding how bridge domains and VLANs are different?


Second question...

You also said that:

tomtom1 wrote: »

If you create a bridge domain with VLAN all (1-4094) and traffic enters via a logical interface on VLAN 100, it is bridged to all interfaces in the bridge domain, where the ingress port could discard it if it does not have a logical interface for VLAN 100. Not a very effective way to bridge traffic.

I'm having a very hard time understanding this. Are you saying that we create one bridge domain and put VLANs 1 to 4094 inside this one bridge domain? Are you also saying that all VLANs within this single bridge domain can communicate with each other? For example, if Host A sends a broadcast in VLAN1, will that broadcast be received on all other VLANs within the bridge domain (VLANs 2-4094)? This is my understanding of it, however this seems to be the opposite of what a VLAN should do. It sounds like traffic in one of these VLANs is able to reach ports in other VLANs, which is what VLANs were created to prevent.

Any clarification would be appreciated. Thanks again for your help! Keep in mind I'm stuck in the Cisco world and these concepts are a bit difficult to relate. Maybe you could also point me to a diagram?

Thanks!