Mailing List Archive

VPLS q-in-q
Hello

I am trying to enable transport of q-in-q double tagged frames over VPLS
through our MX204. The remote end is a switch of another brand (ZTE) and
it has some limitations. The outer vlan tag is not transported so I need
the MX204 to add it back before processing. However I can not figure out
how to do this.

My test configuration:

baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
    vpls {
        ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
        encapsulation-type ethernet-vlan;
        ## 'no-control-word' was inherited from group 'POI-VPLS'
        no-control-word;
        ## 'mac-statistics' was inherited from group 'POI-VPLS'
        mac-statistics;
        mesh-group 1 {
            vpls-id 424;
            neighbor 10.9.124.0;
        }
    }
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
vlan-id 424;
interface xe-0/1/7.424;

baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
    encapsulation vlan-vpls;
    vlan-id 424;
}

I have a client injecting some traffic on the remote switch using outer
vlan 424 and inner vlan 201. Remember outer vlan is not transported, so
the L2VPN would only receive single tagged frames with vlan 201. I need
the MX204 to add outer vlan 424 and transmit packets with outer vlan 424
and inner vlan on interface xe-0/1/7. But instead I get this:

11:10:02.303264 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300

This is a tcpdump on a Linux server. Vlan 424 is not added and we just
get singled tagged vlan 201 packets :-(.

I have tried all sort of combinations including input and
output-vlan-map but with no success. Anyone have some pointers on how to
accomplish this?

Thanks,

Baldur

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
I would add input-vlan-map pop and output-vlan-map push on your interface
unit and remove vlan-id from the VPLS instance.

You can see what it’s doing by showing the interface in operational mode
also.

Where maybe it’s not so explicit is when you put vlan-id on the VPLS
instance which configures input VLAN swaps that you can see on the
interface in operational output.

On Wed, 20 May 2020 at 21:18, Baldur Norddahl <baldur@gigabit.dk> wrote:

> Hello
>
> I am trying to enable transport of q-in-q double tagged frames over VPLS
> through our MX204. The remote end is a switch of another brand (ZTE) and
> it has some limitations. The outer vlan tag is not transported so I need
> the MX204 to add it back before processing. However I can not figure out
> how to do this.
>
> My test configuration:
>
> baldur@formervangen-edge1# show routing-instances poi-formervangen |
> display inheritance brief
> protocols {
> vpls {
> ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
> encapsulation-type ethernet-vlan;
> ## 'no-control-word' was inherited from group 'POI-VPLS'
> no-control-word;
> ## 'mac-statistics' was inherited from group 'POI-VPLS'
> mac-statistics;
> mesh-group 1 {
> vpls-id 424;
> neighbor 10.9.124.0;
> }
> }
> }
> ## 'vpls' was inherited from group 'POI-VPLS'
> instance-type vpls;
> vlan-id 424;
> interface xe-0/1/7.424;
>
> baldur@formervangen-edge1# show interfaces xe-0/1/7
> flexible-vlan-tagging;
> native-vlan-id 424;
> encapsulation flexible-ethernet-services;
> unit 424 {
> encapsulation vlan-vpls;
> vlan-id 424;
> }
>
> I have a client injecting some traffic on the remote switch using outer
> vlan 424 and inner vlan 201. Remember outer vlan is not transported, so
> the L2VPN would only receive single tagged frames with vlan 201. I need
> the MX204 to add outer vlan 424 and transmit packets with outer vlan 424
> and inner vlan on interface xe-0/1/7. But instead I get this:
>
> 11:10:02.303264 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> (0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
> 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
>
> This is a tcpdump on a Linux server. Vlan 424 is not added and we just
> get singled tagged vlan 201 packets :-(.
>
> I have tried all sort of combinations including input and
> output-vlan-map but with no success. Anyone have some pointers on how to
> accomplish this?
>
> Thanks,
>
> Baldur
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Regards,

Mark Tees
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
Hi,

On Wed, May 20, 2020 at 01:16:12PM +0200, Baldur Norddahl wrote:
> I have a client injecting some traffic on the remote switch using outer vlan
> 424 and inner vlan 201. Remember outer vlan is not transported, so the L2VPN
> would only receive single tagged frames with vlan 201. I need the MX204 to
> add outer vlan 424 and transmit packets with outer vlan 424 and inner vlan
> on interface xe-0/1/7. But instead I get this:
>
> 11:10:02.303264 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> (0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
> 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
>
> This is a tcpdump on a Linux server. Vlan 424 is not added and we just get
> singled tagged vlan 201 packets :-(.
>
> I have tried all sort of combinations including input and output-vlan-map
> but with no success. Anyone have some pointers on how to accomplish this?

The vlan-id/vlan-tags statements are used to normalise tagging inside
the routing instance. You can't set use vlan-maps with them (I didn't
think it would commit).

As you cannot use the proper tagging here (that would be vlan-tags outer
424 inner 201) because of your ZTE device, I believe the best course of
action would be to set vlan-id to `all` and push/pull vlan-id 424. Of
course if you have multiple vlans in your VPLS instance they are also
going to be transmitted with outer-vlan 424.

Cheers,
Benjamin
--
Benjamin Collet
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
Hello

I am trying the suggestion received so far and now have this configuration:

baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
    encapsulation vlan-vpls;
    vlan-tags outer 424;
    input-vlan-map {
        push;
        vlan-id 424;
    }
    output-vlan-map pop;
}

baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
    vpls {
        ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
        encapsulation-type ethernet-vlan;
        ## 'no-control-word' was inherited from group 'POI-VPLS'
        no-control-word;
        ## 'mac-statistics' was inherited from group 'POI-VPLS'
        mac-statistics;
        mesh-group 1 {
            vpls-id 424;
            neighbor 10.9.124.0;
        }
    }
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
## 'inner-all' was inherited from group 'POI-VPLS'
vlan-id inner-all;
interface xe-0/1/7.424;

baldur@formervangen-edge1# run show interfaces xe-0/1/7
Physical interface: xe-0/1/7, Enabled, Physical link is Up
  Interface index: 176, SNMP ifIndex: 541
  Link-level type: Flexible-Ethernet, MTU: 1522, MRU: 1530, LAN-PHY
mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None,
MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled,
  Flow control: Enabled, Speed Configuration: Auto
  Pad to minimum frame size: Disabled
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  CoS queues     : 8 supported, 8 maximum usable queues
  Schedulers     : 0
  Current address: e4:5d:37:8f:dc:7a, Hardware address: e4:5d:37:8f:dc:7a
  Last flapped   : 2020-05-20 11:14:05 CEST (02:54:05 ago)
  Input rate     : 0 bps (0 pps)
  Output rate    : 1384 bps (0 pps)
  Active alarms  : None
  Active defects : None
  PCS statistics                      Seconds
    Bit errors                             3
    Errored blocks                         3
  Interface transmit statistics: Disabled

  Logical interface xe-0/1/7.424 (Index 82) (SNMP ifIndex 607)
    Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.424 ] Native-vlan-id:
424 In(push .424) Out(pop)  Encapsulation: VLAN-VPLS
    Input packets : 14
    Output packets: 66
    Protocol vpls, MTU: 1522
      Flags: Is-Primary

  Logical interface xe-0/1/7.32767 (Index 111) (SNMP ifIndex 605)
    Flags: Up SNMP-Traps 0x4004000 VLAN-Tag [ 0x0000.0 ] Encapsulation:
ENET2
    Input packets : 426
    Output packets: 456
    Protocol multiservice, MTU: Unlimited
      Flags: None



However the behaviour did not change. I am stilling receiving only
single tagged frames:

12:11:09.996863 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300

It appears the vlan map is completely ignored.

Regards,

Baldur



_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
You need to get rid of the vlan-id off the routing-instance.

End result I think should be similar to this:

Logical interface ge-1/0/6.888 (Index 650) (SNMP ifIndex 830)
Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.888 ] In(pop) Out(push
0x8100.888) Encapsulation: VLAN-VPLS

Yours is pushing 424 on ingress. Unless, you want to be matching on
both tags all you need is this:

set routing-instances VPLS instance-type vpls
set routing-instances VPLS interface ge-1/0/6.888
</snip>

set interfaces ge-1/0/6 unit 888 encapsulation vlan-vpls
set interfaces ge-1/0/6 unit 888 vlan-id 888
set interfaces ge-1/0/6 unit 888 input-vlan-map pop
set interfaces ge-1/0/6 unit 888 output-vlan-map push

You don't need to say anything about inner tags unless you are wanting
to do an operation on them? It sound like your remote side/ZTE does
the same as what I have mentioned above.

On Wed, 20 May 2020 at 22:13, Baldur Norddahl <baldur@gigabit.dk> wrote:
>
> Hello
>
> I am trying the suggestion received so far and now have this configuration:
>
> baldur@formervangen-edge1# show interfaces xe-0/1/7
> flexible-vlan-tagging;
> native-vlan-id 424;
> encapsulation flexible-ethernet-services;
> unit 424 {
> encapsulation vlan-vpls;
> vlan-tags outer 424;
> input-vlan-map {
> push;
> vlan-id 424;
> }
> output-vlan-map pop;
> }
>
> baldur@formervangen-edge1# show routing-instances poi-formervangen |
> display inheritance brief
> protocols {
> vpls {
> ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
> encapsulation-type ethernet-vlan;
> ## 'no-control-word' was inherited from group 'POI-VPLS'
> no-control-word;
> ## 'mac-statistics' was inherited from group 'POI-VPLS'
> mac-statistics;
> mesh-group 1 {
> vpls-id 424;
> neighbor 10.9.124.0;
> }
> }
> }
> ## 'vpls' was inherited from group 'POI-VPLS'
> instance-type vpls;
> ## 'inner-all' was inherited from group 'POI-VPLS'
> vlan-id inner-all;
> interface xe-0/1/7.424;
>
> baldur@formervangen-edge1# run show interfaces xe-0/1/7
> Physical interface: xe-0/1/7, Enabled, Physical link is Up
> Interface index: 176, SNMP ifIndex: 541
> Link-level type: Flexible-Ethernet, MTU: 1522, MRU: 1530, LAN-PHY
> mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None,
> MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled,
> Flow control: Enabled, Speed Configuration: Auto
> Pad to minimum frame size: Disabled
> Device flags : Present Running
> Interface flags: SNMP-Traps Internal: 0x4000
> CoS queues : 8 supported, 8 maximum usable queues
> Schedulers : 0
> Current address: e4:5d:37:8f:dc:7a, Hardware address: e4:5d:37:8f:dc:7a
> Last flapped : 2020-05-20 11:14:05 CEST (02:54:05 ago)
> Input rate : 0 bps (0 pps)
> Output rate : 1384 bps (0 pps)
> Active alarms : None
> Active defects : None
> PCS statistics Seconds
> Bit errors 3
> Errored blocks 3
> Interface transmit statistics: Disabled
>
> Logical interface xe-0/1/7.424 (Index 82) (SNMP ifIndex 607)
> Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.424 ] Native-vlan-id:
> 424 In(push .424) Out(pop) Encapsulation: VLAN-VPLS
> Input packets : 14
> Output packets: 66
> Protocol vpls, MTU: 1522
> Flags: Is-Primary
>
> Logical interface xe-0/1/7.32767 (Index 111) (SNMP ifIndex 605)
> Flags: Up SNMP-Traps 0x4004000 VLAN-Tag [ 0x0000.0 ] Encapsulation:
> ENET2
> Input packets : 426
> Output packets: 456
> Protocol multiservice, MTU: Unlimited
> Flags: None
>
>
>
> However the behaviour did not change. I am stilling receiving only
> single tagged frames:
>
> 12:11:09.996863 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> (0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
> 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
>
> It appears the vlan map is completely ignored.
>
> Regards,
>
> Baldur
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



--
Regards,

Mark Tees
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
To append, you could get more specific and match the inner VLAN ID
also on the interface unit but the input pop 1 tag/output push 1 tag
would stay the same.

On Wed, 20 May 2020 at 22:25, Mark Tees <marktees@gmail.com> wrote:
>
> You need to get rid of the vlan-id off the routing-instance.
>
> End result I think should be similar to this:
>
> Logical interface ge-1/0/6.888 (Index 650) (SNMP ifIndex 830)
> Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.888 ] In(pop) Out(push
> 0x8100.888) Encapsulation: VLAN-VPLS
>
> Yours is pushing 424 on ingress. Unless, you want to be matching on
> both tags all you need is this:
>
> set routing-instances VPLS instance-type vpls
> set routing-instances VPLS interface ge-1/0/6.888
> </snip>
>
> set interfaces ge-1/0/6 unit 888 encapsulation vlan-vpls
> set interfaces ge-1/0/6 unit 888 vlan-id 888
> set interfaces ge-1/0/6 unit 888 input-vlan-map pop
> set interfaces ge-1/0/6 unit 888 output-vlan-map push
>
> You don't need to say anything about inner tags unless you are wanting
> to do an operation on them? It sound like your remote side/ZTE does
> the same as what I have mentioned above.
>
> On Wed, 20 May 2020 at 22:13, Baldur Norddahl <baldur@gigabit.dk> wrote:
> >
> > Hello
> >
> > I am trying the suggestion received so far and now have this configuration:
> >
> > baldur@formervangen-edge1# show interfaces xe-0/1/7
> > flexible-vlan-tagging;
> > native-vlan-id 424;
> > encapsulation flexible-ethernet-services;
> > unit 424 {
> > encapsulation vlan-vpls;
> > vlan-tags outer 424;
> > input-vlan-map {
> > push;
> > vlan-id 424;
> > }
> > output-vlan-map pop;
> > }
> >
> > baldur@formervangen-edge1# show routing-instances poi-formervangen |
> > display inheritance brief
> > protocols {
> > vpls {
> > ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
> > encapsulation-type ethernet-vlan;
> > ## 'no-control-word' was inherited from group 'POI-VPLS'
> > no-control-word;
> > ## 'mac-statistics' was inherited from group 'POI-VPLS'
> > mac-statistics;
> > mesh-group 1 {
> > vpls-id 424;
> > neighbor 10.9.124.0;
> > }
> > }
> > }
> > ## 'vpls' was inherited from group 'POI-VPLS'
> > instance-type vpls;
> > ## 'inner-all' was inherited from group 'POI-VPLS'
> > vlan-id inner-all;
> > interface xe-0/1/7.424;
> >
> > baldur@formervangen-edge1# run show interfaces xe-0/1/7
> > Physical interface: xe-0/1/7, Enabled, Physical link is Up
> > Interface index: 176, SNMP ifIndex: 541
> > Link-level type: Flexible-Ethernet, MTU: 1522, MRU: 1530, LAN-PHY
> > mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None,
> > MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled,
> > Flow control: Enabled, Speed Configuration: Auto
> > Pad to minimum frame size: Disabled
> > Device flags : Present Running
> > Interface flags: SNMP-Traps Internal: 0x4000
> > CoS queues : 8 supported, 8 maximum usable queues
> > Schedulers : 0
> > Current address: e4:5d:37:8f:dc:7a, Hardware address: e4:5d:37:8f:dc:7a
> > Last flapped : 2020-05-20 11:14:05 CEST (02:54:05 ago)
> > Input rate : 0 bps (0 pps)
> > Output rate : 1384 bps (0 pps)
> > Active alarms : None
> > Active defects : None
> > PCS statistics Seconds
> > Bit errors 3
> > Errored blocks 3
> > Interface transmit statistics: Disabled
> >
> > Logical interface xe-0/1/7.424 (Index 82) (SNMP ifIndex 607)
> > Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.424 ] Native-vlan-id:
> > 424 In(push .424) Out(pop) Encapsulation: VLAN-VPLS
> > Input packets : 14
> > Output packets: 66
> > Protocol vpls, MTU: 1522
> > Flags: Is-Primary
> >
> > Logical interface xe-0/1/7.32767 (Index 111) (SNMP ifIndex 605)
> > Flags: Up SNMP-Traps 0x4004000 VLAN-Tag [ 0x0000.0 ] Encapsulation:
> > ENET2
> > Input packets : 426
> > Output packets: 456
> > Protocol multiservice, MTU: Unlimited
> > Flags: None
> >
> >
> >
> > However the behaviour did not change. I am stilling receiving only
> > single tagged frames:
> >
> > 12:11:09.996863 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> > (0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
> > 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
> >
> > It appears the vlan map is completely ignored.
> >
> > Regards,
> >
> > Baldur
> >
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> Regards,
>
> Mark Tees



--
Regards,

Mark Tees
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
I tried this and we got closer but it is replacing both inner and outer
tags now:

12:48:27.320821 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 350: vlan 424, p 0, ethertype 802.1Q, vlan 424, p 0,
ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
from 00:22:07:4d:7b:0d, length 300

That should have been outer 424 inner 201.

The config:

baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
    encapsulation vlan-vpls;
    vlan-id 424;
    input-vlan-map pop;
    output-vlan-map push;
}

[edit]
baldur@formervangen-edge1# commit
commit complete

[edit]
baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
    vpls {
        ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
        encapsulation-type ethernet-vlan;
        ## 'no-control-word' was inherited from group 'POI-VPLS'
        no-control-word;
        ## 'mac-statistics' was inherited from group 'POI-VPLS'
        mac-statistics;
        mesh-group 1 {
            vpls-id 424;
            neighbor 10.9.124.0;
        }
    }
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
interface xe-0/1/7.424;

Regards,

Baldur

On 20.05.2020 14.25, Mark Tees wrote:
> You need to get rid of the vlan-id off the routing-instance.
>
> End result I think should be similar to this:
>
> Logical interface ge-1/0/6.888 (Index 650) (SNMP ifIndex 830)
> Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.888 ] In(pop) Out(push
> 0x8100.888) Encapsulation: VLAN-VPLS
>
> Yours is pushing 424 on ingress. Unless, you want to be matching on
> both tags all you need is this:
>
> set routing-instances VPLS instance-type vpls
> set routing-instances VPLS interface ge-1/0/6.888
> </snip>
>
> set interfaces ge-1/0/6 unit 888 encapsulation vlan-vpls
> set interfaces ge-1/0/6 unit 888 vlan-id 888
> set interfaces ge-1/0/6 unit 888 input-vlan-map pop
> set interfaces ge-1/0/6 unit 888 output-vlan-map push
>
> You don't need to say anything about inner tags unless you are wanting
> to do an operation on them? It sound like your remote side/ZTE does
> the same as what I have mentioned above.
>
> On Wed, 20 May 2020 at 22:13, Baldur Norddahl <baldur@gigabit.dk> wrote:
>> Hello
>>
>> I am trying the suggestion received so far and now have this configuration:
>>
>> baldur@formervangen-edge1# show interfaces xe-0/1/7
>> flexible-vlan-tagging;
>> native-vlan-id 424;
>> encapsulation flexible-ethernet-services;
>> unit 424 {
>> encapsulation vlan-vpls;
>> vlan-tags outer 424;
>> input-vlan-map {
>> push;
>> vlan-id 424;
>> }
>> output-vlan-map pop;
>> }
>>
>> baldur@formervangen-edge1# show routing-instances poi-formervangen |
>> display inheritance brief
>> protocols {
>> vpls {
>> ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
>> encapsulation-type ethernet-vlan;
>> ## 'no-control-word' was inherited from group 'POI-VPLS'
>> no-control-word;
>> ## 'mac-statistics' was inherited from group 'POI-VPLS'
>> mac-statistics;
>> mesh-group 1 {
>> vpls-id 424;
>> neighbor 10.9.124.0;
>> }
>> }
>> }
>> ## 'vpls' was inherited from group 'POI-VPLS'
>> instance-type vpls;
>> ## 'inner-all' was inherited from group 'POI-VPLS'
>> vlan-id inner-all;
>> interface xe-0/1/7.424;
>>
>> baldur@formervangen-edge1# run show interfaces xe-0/1/7
>> Physical interface: xe-0/1/7, Enabled, Physical link is Up
>> Interface index: 176, SNMP ifIndex: 541
>> Link-level type: Flexible-Ethernet, MTU: 1522, MRU: 1530, LAN-PHY
>> mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None,
>> MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled,
>> Flow control: Enabled, Speed Configuration: Auto
>> Pad to minimum frame size: Disabled
>> Device flags : Present Running
>> Interface flags: SNMP-Traps Internal: 0x4000
>> CoS queues : 8 supported, 8 maximum usable queues
>> Schedulers : 0
>> Current address: e4:5d:37:8f:dc:7a, Hardware address: e4:5d:37:8f:dc:7a
>> Last flapped : 2020-05-20 11:14:05 CEST (02:54:05 ago)
>> Input rate : 0 bps (0 pps)
>> Output rate : 1384 bps (0 pps)
>> Active alarms : None
>> Active defects : None
>> PCS statistics Seconds
>> Bit errors 3
>> Errored blocks 3
>> Interface transmit statistics: Disabled
>>
>> Logical interface xe-0/1/7.424 (Index 82) (SNMP ifIndex 607)
>> Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.424 ] Native-vlan-id:
>> 424 In(push .424) Out(pop) Encapsulation: VLAN-VPLS
>> Input packets : 14
>> Output packets: 66
>> Protocol vpls, MTU: 1522
>> Flags: Is-Primary
>>
>> Logical interface xe-0/1/7.32767 (Index 111) (SNMP ifIndex 605)
>> Flags: Up SNMP-Traps 0x4004000 VLAN-Tag [ 0x0000.0 ] Encapsulation:
>> ENET2
>> Input packets : 426
>> Output packets: 456
>> Protocol multiservice, MTU: Unlimited
>> Flags: None
>>
>>
>>
>> However the behaviour did not change. I am stilling receiving only
>> single tagged frames:
>>
>> 12:11:09.996863 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
>> (0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
>> 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
>>
>> It appears the vlan map is completely ignored.
>>
>> Regards,
>>
>> Baldur
>>
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
Assuming 00:22:07:4d:7b:0d is the MAC behind the Juniper and the PCAP
is on NIC of the host connected to the ZTE.

At a guess the ZTE doing something different on ingress than what I am
thinking here.

If you can verify by PCAP on MPLS interface it would be handy to see
what each side is doing in each direction. Juniper MX operations in
this regards have usually been pretty explicit.





On Wed, 20 May 2020 at 22:49, Baldur Norddahl <baldur@gigabit.dk> wrote:
>
> I tried this and we got closer but it is replacing both inner and outer
> tags now:
>
> 12:48:27.320821 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> (0x8100), length 350: vlan 424, p 0, ethertype 802.1Q, vlan 424, p 0,
> ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
> from 00:22:07:4d:7b:0d, length 300
>
> That should have been outer 424 inner 201.
>
> The config:
>
> baldur@formervangen-edge1# show interfaces xe-0/1/7
> flexible-vlan-tagging;
> native-vlan-id 424;
> encapsulation flexible-ethernet-services;
> unit 424 {
> encapsulation vlan-vpls;
> vlan-id 424;
> input-vlan-map pop;
> output-vlan-map push;
> }
>
> [edit]
> baldur@formervangen-edge1# commit
> commit complete
>
> [edit]
> baldur@formervangen-edge1# show routing-instances poi-formervangen |
> display inheritance brief
> protocols {
> vpls {
> ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
> encapsulation-type ethernet-vlan;
> ## 'no-control-word' was inherited from group 'POI-VPLS'
> no-control-word;
> ## 'mac-statistics' was inherited from group 'POI-VPLS'
> mac-statistics;
> mesh-group 1 {
> vpls-id 424;
> neighbor 10.9.124.0;
> }
> }
> }
> ## 'vpls' was inherited from group 'POI-VPLS'
> instance-type vpls;
> interface xe-0/1/7.424;
>
> Regards,
>
> Baldur
>
> On 20.05.2020 14.25, Mark Tees wrote:
> > You need to get rid of the vlan-id off the routing-instance.
> >
> > End result I think should be similar to this:
> >
> > Logical interface ge-1/0/6.888 (Index 650) (SNMP ifIndex 830)
> > Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.888 ] In(pop) Out(push
> > 0x8100.888) Encapsulation: VLAN-VPLS
> >
> > Yours is pushing 424 on ingress. Unless, you want to be matching on
> > both tags all you need is this:
> >
> > set routing-instances VPLS instance-type vpls
> > set routing-instances VPLS interface ge-1/0/6.888
> > </snip>
> >
> > set interfaces ge-1/0/6 unit 888 encapsulation vlan-vpls
> > set interfaces ge-1/0/6 unit 888 vlan-id 888
> > set interfaces ge-1/0/6 unit 888 input-vlan-map pop
> > set interfaces ge-1/0/6 unit 888 output-vlan-map push
> >
> > You don't need to say anything about inner tags unless you are wanting
> > to do an operation on them? It sound like your remote side/ZTE does
> > the same as what I have mentioned above.
> >
> > On Wed, 20 May 2020 at 22:13, Baldur Norddahl <baldur@gigabit.dk> wrote:
> >> Hello
> >>
> >> I am trying the suggestion received so far and now have this configuration:
> >>
> >> baldur@formervangen-edge1# show interfaces xe-0/1/7
> >> flexible-vlan-tagging;
> >> native-vlan-id 424;
> >> encapsulation flexible-ethernet-services;
> >> unit 424 {
> >> encapsulation vlan-vpls;
> >> vlan-tags outer 424;
> >> input-vlan-map {
> >> push;
> >> vlan-id 424;
> >> }
> >> output-vlan-map pop;
> >> }
> >>
> >> baldur@formervangen-edge1# show routing-instances poi-formervangen |
> >> display inheritance brief
> >> protocols {
> >> vpls {
> >> ## 'ethernet-vlan' was inherited from group 'POI-VPLS'
> >> encapsulation-type ethernet-vlan;
> >> ## 'no-control-word' was inherited from group 'POI-VPLS'
> >> no-control-word;
> >> ## 'mac-statistics' was inherited from group 'POI-VPLS'
> >> mac-statistics;
> >> mesh-group 1 {
> >> vpls-id 424;
> >> neighbor 10.9.124.0;
> >> }
> >> }
> >> }
> >> ## 'vpls' was inherited from group 'POI-VPLS'
> >> instance-type vpls;
> >> ## 'inner-all' was inherited from group 'POI-VPLS'
> >> vlan-id inner-all;
> >> interface xe-0/1/7.424;
> >>
> >> baldur@formervangen-edge1# run show interfaces xe-0/1/7
> >> Physical interface: xe-0/1/7, Enabled, Physical link is Up
> >> Interface index: 176, SNMP ifIndex: 541
> >> Link-level type: Flexible-Ethernet, MTU: 1522, MRU: 1530, LAN-PHY
> >> mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None,
> >> MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled,
> >> Flow control: Enabled, Speed Configuration: Auto
> >> Pad to minimum frame size: Disabled
> >> Device flags : Present Running
> >> Interface flags: SNMP-Traps Internal: 0x4000
> >> CoS queues : 8 supported, 8 maximum usable queues
> >> Schedulers : 0
> >> Current address: e4:5d:37:8f:dc:7a, Hardware address: e4:5d:37:8f:dc:7a
> >> Last flapped : 2020-05-20 11:14:05 CEST (02:54:05 ago)
> >> Input rate : 0 bps (0 pps)
> >> Output rate : 1384 bps (0 pps)
> >> Active alarms : None
> >> Active defects : None
> >> PCS statistics Seconds
> >> Bit errors 3
> >> Errored blocks 3
> >> Interface transmit statistics: Disabled
> >>
> >> Logical interface xe-0/1/7.424 (Index 82) (SNMP ifIndex 607)
> >> Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.424 ] Native-vlan-id:
> >> 424 In(push .424) Out(pop) Encapsulation: VLAN-VPLS
> >> Input packets : 14
> >> Output packets: 66
> >> Protocol vpls, MTU: 1522
> >> Flags: Is-Primary
> >>
> >> Logical interface xe-0/1/7.32767 (Index 111) (SNMP ifIndex 605)
> >> Flags: Up SNMP-Traps 0x4004000 VLAN-Tag [ 0x0000.0 ] Encapsulation:
> >> ENET2
> >> Input packets : 426
> >> Output packets: 456
> >> Protocol multiservice, MTU: Unlimited
> >> Flags: None
> >>
> >>
> >>
> >> However the behaviour did not change. I am stilling receiving only
> >> single tagged frames:
> >>
> >> 12:11:09.996863 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
> >> (0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
> >> 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
> >>
> >> It appears the vlan map is completely ignored.
> >>
> >> Regards,
> >>
> >> Baldur
> >>
> >>
> >>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
>


--
Regards,

Mark Tees
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
On 20.05.2020 15.04, Mark Tees wrote:
> Assuming 00:22:07:4d:7b:0d is the MAC behind the Juniper and the PCAP
> is on NIC of the host connected to the ZTE.
>
> At a guess the ZTE doing something different on ingress than what I am
> thinking here.
>
> If you can verify by PCAP on MPLS interface it would be handy to see
> what each side is doing in each direction. Juniper MX operations in
> this regards have usually been pretty explicit.
>

Not so easy to interpret but here is a capture of the MPLS packet sent
by the ZTE device. The capture device (a Linux box with bridge) is
sitting in between those the ZTE switch and the Juniper MX204. They
would not usually be directly connected like this, but I am in the lab.

Frame 60: 368 bytes on wire (2944 bits), 368 bytes captured (2944 bits)
Ethernet II, Src: Zte_ba:ef:84 (0c:12:62:ba:ef:84), Dst:
JuniperN_8f:dc:73 (e4:5d:37:8f:dc:73)
MultiProtocol Label Switching Header, Label: 238, Exp: 0, S: 1, TTL: 255
    0000 0000 0000 1110 1110 .... .... .... = MPLS Label: 238
    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0
    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1
    .... .... .... .... .... .... 1111 1111 = MPLS TTL: 255
Data (350 bytes)
    Data: ffffffffffff0022074d7b0d810001a8810000c908004500...
    [Length: 350]

0000   ff ff ff ff ff ff 00 22 07 4d 7b 0d 81 00 01 a8 ÿÿÿÿÿÿ.".M{....¨
0010   81 00 00 c9 08 00 45 00 01 48 00 00 00 00 40 11 ...É..E..H....@.
0020   79 a6 00 00 00 00 ff ff ff ff 00 44 00 43 01 34 y¦....ÿÿÿÿ.D.C.4
0030   be 52 01 01 06 00 79 b3 e8 65 2b 95 00 00 00 00 ¾R....y³èe+.....
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 ..............."
0050   07 4d 7b 0d 00 00 00 00 00 00 00 00 00 00 00 00 .M{.............
0060   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00e0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110   00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82 ..............c.
0120   53 63 35 01 01 39 02 02 40 37 0e 01 03 06 0c 0f Sc5..9..@7......
0130   1c 2a 2b 42 43 80 84 85 d4 3c 15 45 47 33 30 30 .*+BC...Ô<.EG300
0140   41 2d 57 55 32 31 55 41 43 2d 49 4e 54 45 4e 4f A-WU21UAC-INTENO
0150   0c 0b 49 6e 74 65 6e 6f 5f 37 42 30 41 ff ..Inteno_7B0Aÿ

I pasted that stuff into the packet decoder at https://hpd.gasmi.net/
and surprisingly found out that both outer and inner vlan is present. I
thought it would not transmit the outer vlan. Still does not explain why
I am having trouble then.

I need to go home now but I clearly need to investigate more.


Regards,

Baldur



_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
Hello

I got this working by changing VPLS encapsulation from tagged to raw and
this config:

baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
    vpls {
        encapsulation-type ethernet;
        ## 'no-control-word' was inherited from group 'POI-VPLS'
        no-control-word;
        ## 'mac-statistics' was inherited from group 'POI-VPLS'
        mac-statistics;
        mesh-group 1 {
            vpls-id 424;
            neighbor 10.9.124.0;
        }
    }
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
vlan-id all;
interface xe-0/1/7.424;
interface ps1.0;
interface ps1.424; ## 'ps1.424' is not defined

[edit]
baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
    encapsulation vlan-vpls;
    vlan-tags outer 424 inner-range 1-4000;
}


I now get double tagged frames out on interface xe-0/1/7:

10:29:34.667573 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 350: vlan 424, p 0, ethertype 802.1Q, vlan 201, p 0,
ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
from 00:22:07:4d:7b:0d, length 300

However I also need this on a 'ps' interface to support auto
configuration with subscriber management. I tried replicating the
configuration from xe-0/1/7.424 on ps1.424 and that configuration is
accepted by the router but does nothing. Auto configuration does query
the radius server. I then tried ethernet-vpls on ps1.0 which works but
now I am missing the outer vlan tag.

baldur@formervangen-edge1# show interfaces ps1
apply-groups AUTO-PS;
encapsulation flexible-ethernet-services;
unit 0 {
    encapsulation ethernet-vpls;
}
inactive: unit 424 {
    encapsulation vlan-vpls;
    vlan-tags outer 424 inner-range 1-4000;
}

Packet counters on ps1.424 is counting output packages but
auto-configure is not triggered.

Is there a trick to get the full q-in-q double tagged headers back in
this case?

Thanks,

Baldur


Full config of ps1:

baldur@formervangen-edge1# show interfaces ps1 | display inheritance brief
## 'anchor-point' was inherited from group 'AUTO-PS'
anchor-point {
    ## 'lt-0/0/0' was inherited from group 'AUTO-PS'
    lt-0/0/0;
}
## 'flexible-vlan-tagging' was inherited from group 'AUTO-PS'
flexible-vlan-tagging;
## 'auto-configure' was inherited from group 'AUTO-PS'
auto-configure {
    ## 'stacked-vlan-ranges' was inherited from group 'AUTO-PS'
    stacked-vlan-ranges {
        ## 'USER-ACCESS-TEST' was inherited from group 'AUTO-PS'
        dynamic-profile USER-ACCESS-TEST {
            ## 'any' was inherited from group 'AUTO-PS'
            accept any;
            ranges {
                ## 'any,any' was inherited from group 'AUTO-PS'
                any,any;
            }
        }
        ## 'authentication' was inherited from group 'AUTO-PS'
        authentication {
            ## 'any' was inherited from group 'AUTO-PS'
            packet-types any;
            ## '$ABC123' was inherited from group 'AUTO-PS'
            password "$ABC123";
            ## 'username-include' was inherited from group 'AUTO-PS'
            username-include {
                ## 'qqvlan' was inherited from group 'AUTO-PS'
                user-prefix qqvlan;
                ## 'vlan-tags' was inherited from group 'AUTO-PS'
                vlan-tags;
            }
        }
        ## 'access-profile' was inherited from group 'AUTO-PS'
        ## 'rad' was inherited from group 'AUTO-PS'
        access-profile rad;
    }
    ## 'vlan-ranges' was inherited from group 'AUTO-PS'
    vlan-ranges {
        ## 'USER-ACCESS-TEST' was inherited from group 'AUTO-PS'
        dynamic-profile USER-ACCESS-TEST {
            ## 'any' was inherited from group 'AUTO-PS'
            accept any;
            ranges {
                ## 'any' was inherited from group 'AUTO-PS'
                any;
            }
        }
        ## 'authentication' was inherited from group 'AUTO-PS'
        authentication {
            ## 'any' was inherited from group 'AUTO-PS'
            packet-types any;
            ## '$ABC123' was inherited from group 'AUTO-PS'
            password "$ABC123";
            ## 'username-include' was inherited from group 'AUTO-PS'
            username-include {
                ## 'qvlan' was inherited from group 'AUTO-PS'
                user-prefix qvlan;
                ## 'vlan-tags' was inherited from group 'AUTO-PS'
                vlan-tags;
            }
        }
        ## 'access-profile' was inherited from group 'AUTO-PS'
        ## 'rad' was inherited from group 'AUTO-PS'
        access-profile rad;
    }
}
encapsulation flexible-ethernet-services;
unit 0 {
    encapsulation ethernet-vpls;
}


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: VPLS q-in-q [ In reply to ]
On 22.05.2020 12.42, Baldur Norddahl wrote:
>
>
> However I also need this on a 'ps' interface to support auto
> configuration with subscriber management. I tried replicating the
> configuration from xe-0/1/7.424 on ps1.424 and that configuration is
> accepted by the router but does nothing. Auto configuration does query
> the radius server. I then tried ethernet-vpls on ps1.0 which works but
> now I am missing the outer vlan tag.
>

The above should read "Auto configuration does NOT query the radius
server". Sorry.

Regards,

Baldur

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp