[j-nsp] Q-in-Q of Untagged Frames Transport

[Ben Dale]

On 27/03/2013, at 9:58 AM, Giuliano Medalha <giuliano at wztech.com.br> wrote:

> People,
> 
> Is it possible to transport untagged ethernet frames using Q-in-Q in EX2200
> switches ?

Yes

> 
> The client port is ever untagged ... but we would like to transport
> untagged frames, like a direct computer frames from one side to other side
> (access client port)
> 
> Is it possible to do it using EX2200 ?

Yes

> Does anyone have used   customer native vlan-id  ?
> 
> Any example of configuration ?


Seems to work just fine - just be aware that on EX2200 dot1q tunnelling requires an Extended Feature License - I seem to recall it flat out doesn't work without this (won't commit).

bdale at core-lb# show vlans  
v30-Q-Tunnel {
    vlan-id 30;
    dot1q-tunneling {
        customer-vlans native;
    }
}

Customer-facing port:

[edit]
bdale at core-lb# show interfaces ge-0/0/20    
unit 0 {
    family ethernet-switching {
        vlan {
            members v30-Q-Tunnel;
        }
    }
}

Uplink port:

[edit]
bdale at core-lb# show interfaces ge-0/0/21    
unit 0 {
    family ethernet-switching {
        port-mode trunk;
        vlan {
            members v30-Q-Tunnel;
        }
    }
}

Just watch your default ether-types if you're uplinking from EX to MX together - spent a lot of time banging my head against the wall until I realised EX seem to use 0x9100 by default, whereas MX80 seems to expect 0x8100.  Anyway, this will do the trick:

ethernet-switching-options {
    dot1q-tunneling {
        ether-type 0x8100;              
    }
    storm-control {
        interface all;
    }
}

Cheers,

Ben

> 
> 
> 
> Thanks a lot,
> 
> Giuliano
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>