Re: [j-nsp] any way to do group inheritence only if parent exists?
Hey Chuck > set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600 > set interfaces apply-groups ND6 > > then all irb interfaces get a "family inet6" with link-local > addressing created and the nd6-state-time setting applied. How do I > inherit the nd6-stale-time setting only if there is already a > configured "family inet6" so I don't get IPv6 link-locals on IRBs > where I only want IPv4? As far as I know, you can't. I'm sure if you push this at JNPR they are able to support it via 'family '. However as it is today, only works for user input, not for parameters or keywords, which I suspect is not actually that huge change in parser. So if this would in in parser: set family ? Interface protocol family Then you could do 'family ' and it would only apply when that family exists. However, now as it's not user-input, it doesn't work and I don't think there is a way. Having said that, configuration groups in junos are really great tool, while usually people use them to avoid repating themselves, I think perhaps even better use-case is to use them as namespaces, for example, put all your standard static config in 'template' namespace. So you you can programmatically do this: edit groups template delete load merge relative https://nms/junos.template commit and-quit Leaving all device-specific config intact, while normalising all generic config. And further, don't use configuration groups, at all :) Do it all on NMS side, so that you are less reliant on vendor tools and limitations. Then you have as much flexibility on them as you wish and it works for all your vendors. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] any way to do group inheritence only if parent exists?
Sorry I misread that :/ What you are wanting is more complex in second pass. On Thu, 21 May 2020 at 12:18, Mark Tees wrote: > Yes, change the group to be applied from the root of the config. > > On Thu, 21 May 2020 at 11:53, Chuck Anderson wrote: > >> Is there any way to inherit a configuration group setting, but only if >> the parent object already exists? For example, if I apply this: >> >> set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600 >> set interfaces apply-groups ND6 >> >> then all irb interfaces get a "family inet6" with link-local >> addressing created and the nd6-state-time setting applied. How do I >> inherit the nd6-stale-time setting only if there is already a >> configured "family inet6" so I don't get IPv6 link-locals on IRBs >> where I only want IPv4? >> ___ >> 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: [j-nsp] any way to do group inheritence only if parent exists?
Yes, change the group to be applied from the root of the config. On Thu, 21 May 2020 at 11:53, Chuck Anderson wrote: > Is there any way to inherit a configuration group setting, but only if > the parent object already exists? For example, if I apply this: > > set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600 > set interfaces apply-groups ND6 > > then all irb interfaces get a "family inet6" with link-local > addressing created and the nd6-state-time setting applied. How do I > inherit the nd6-stale-time setting only if there is already a > configured "family inet6" so I don't get IPv6 link-locals on IRBs > where I only want IPv4? > ___ > 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
[j-nsp] any way to do group inheritence only if parent exists?
Is there any way to inherit a configuration group setting, but only if the parent object already exists? For example, if I apply this: set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600 set interfaces apply-groups ND6 then all irb interfaces get a "family inet6" with link-local addressing created and the nd6-state-time setting applied. How do I inherit the nd6-stale-time setting only if there is already a configured "family inet6" so I don't get IPv6 link-locals on IRBs where I only want IPv4? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS q-in-q
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
1110 1110 = MPLS Label: 238
000. = MPLS Experimental Bits: 0
...1 = MPLS Bottom Of Label Stack: 1
= MPLS TTL: 255
Data (350 bytes)
Data: 0022074d7b0d810001a881c908004500...
[Length: 350]
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 ¾Ry³è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: [j-nsp] VPLS q-in-q
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 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
> >
> >
> > 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 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-
[j-nsp] Advertisement of VRRP IP in an EVPN with IRB setup
Hello,
i'm trying to setup a multihomed EVPN with IRB and VRRP (see
configuration below). I know, that i could omit VRRP configuration and
use the same IP on irb interfaces of the participating PE routers for
next-hop redundancy. But from an operational perspective, i find it
useful to have a possibility to ping the local IPs with knowing who
reponds to my ICMP requests. The local IP/MAC addresses are advertised
with the default gateway extended community as expected and are
pingable, but unfortunatly the VRRP IP isn't. Is there a knob to
activate this ?
EVPN_DHCP {
instance-type virtual-switch;
route-distinguisher :1001;
vrf-target target:1001:1001;
protocols {
evpn {
extended-vlan-list [ 122 132 ];
}
}
bridge-domains {
VLAN-122 {
vlan-id 122;
no-arp-suppression;
interface ae10.122;
routing-interface irb.122;
}
VLAN-132 {
vlan-id 132;
no-arp-suppression;
interface ae10.132;
routing-interface irb.132;
}
}
}
irb {
unit 122 {
description dhcp-2-fttx-lan2;
family inet {
address 192.168.202.53/29 {
vrrp-group 122 {
virtual-address 192.168.202.54;
priority 200;
fast-interval 200;
accept-data;
authentication-type md5;
authentication-key "$9$L2N7w2oJDH.5BI"; ## SECRET-DATA
}
}
}
}
unit 132 {
description dhcp-3-fttx-lan2;
family inet {
address 192.168.202.61/29 {
vrrp-group 132 {
virtual-address 192.168.202.62;
priority 200;
fast-interval 200;
accept-data;
authentication-type md5;
authentication-key "$9$L2N7w2oJDH.5BI"; ## SECRET-DATA
}
}
}
}
}
Regards,
Alex
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS q-in-q
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
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 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 [ 0x.0 ] Encapsulation:
ENET2
Input packets : 426
Output packets: 456
Protocol multiservice, MTU: Unlimited
Flags: None
Re: [j-nsp] VPLS q-in-q
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 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
>
>
> 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 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 [ 0x.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: [j-nsp] VPLS q-in-q
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
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 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 [ 0x.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: [j-nsp] VPLS q-in-q
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 [ 0x.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: [j-nsp] VPLS q-in-q
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: [j-nsp] VPLS q-in-q
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 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
[j-nsp] 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
