Please take a look at this and see if helps. Read all of the comments,
access interfaces required in pvlan
https://forums.juniper.net/t5/Ethernet-Switching/no-local-switching-for-private-vlan/td-p/193325
Please take a look at this and see if helps. Read all of the comments,
access interfaces required in pvlan
https://forums.juniper.net/t5/Ethernet-Switching/no-local-switching-for-private-vlan/td-p/193325
It does seem like it is. Maybe the feature will be supported later on EX3400 BTW what version are you running?
That post is about whether to set or not this option.
The thing is that there is no such option in my ex3400
root@ex3400-testowy1# run show version | match 15.1X Junos: 15.1X53-D51
hi Bartek,
see Getting Started with Enhanced Layer 2 Software
Search for no-local-switching ----> Statement is removed
jtb
root@ex3400-testowy1# run show version | match 15.1X Junos: 15.1X53-D51
You probably right.
Strange, that this feature is only on massive and expensive ex8200 and on rather cheap ex3400. Nothing between
Just to add to this... You will need to add the default vlan to each port on any switch that is not the master. My commands from adding them on the 24 port switch:
set interfaces ge-1/0/17 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/16 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/15 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/14 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/13 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/12 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/11 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/10 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/9 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/8 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/7 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/6 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/5 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/4 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/3 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/2 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/1 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/0 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/18 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/19 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/20 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/21 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/22 unit 0 family ethernet-switching vlan members default
set interfaces ge-1/0/23 unit 0 family ethernet-switching vlan members default
Hi all,
Thanks for thinking with me on this case.
We have solved the problem by deactivating & activating the mBGP sessions between the devices. After the sessions reestablished the EVPN functionality was working again.
We did not find anything during diagnosing. Resetting the BGP session was just guessing and trying everything.
We think we hit a bug during the updating and switching the active/inactive RE.
We are using 14.2R7.5 on MX960 with 32x10G and 2x100/8x10G linecards.
Allthough we have not tried to reproduce the issue (yet), i reccomend everything running EVPN features to upgrades thier devices by fully rebooting both RE's and not use features like Routing Engine Redundancy, Gracefull Routing Engine failover or similar functions. Better to go through the dark for a few minutes.
Hello,
We have exactly the same "issue" with 15.1R5.5 EX3300 VC (5 members)
2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:24, peer_index:4, vskid:0, seqno:87647, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:24, peer_index:1, vskid:0, seqno:86868, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:24, peer_index:2, vskid:0, seqno:86111, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:23, peer_index:2, vskid:0, seqno:85700, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:24, peer_index:3, vskid:0, seqno:85374, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:23, peer_index:3, vskid:0, seqno:84971, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:24, peer_index:0, vskid:0, seqno:148068, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:7, peer_index:0, vskid:0, seqno:11971, flag:2, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:25, peer_index:0, vskid:0, seqno:155650, flag:9, 2017-02-19T14:10:45+00:00 scua-1133 /kernel: rts_commit_proposalmput op: 2, peer_type:23, peer_index:0, vskid:0, seqno:147746, flag:9,
Thanks!
Just in case anyone hasn't happened to hear this news. It was difficult to find an official article by Juniper on this earlier this week but something finally was just published 2/17/2017.
hello all!
I have architecture related question - in our env we use evpn on simple 2 -stage close network with qfx5100 - leafs, qfx10k as spines and mx480s for l3 interconnections. We are SP and our DC is going to scale out up to 80k servers.
We found very limited mapping posiibility - in case of uniqe tenant vni to vlan-id on leaf we need to use many vlan-id tags to prevent overlapping. Thus we need to keep up a mapping list of all translation on all devices, and our customers are forced to possibly use diferent tags on each server.
Is there a way (using any of flexible vlan mapping or vlan normalization) to keep up possibility to map vlan-tags on ports to diferent vni's ?
for example :
ge-0/0/1.10 with tag 10 mapped to vni 10010
ge-0/0/2.10 with tag 10 mapped to vni 10020
?
Same here on an EX4200-VC (two members, one 48T, one 24T).
Commit random change, reboot didn't resolve the issue.
Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:7, peer_index:1, vskid:0, seqno:63785, flag:2, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:23, peer_index:0, vskid:0, seqno:98517, flag:9, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:23, peer_index:1, vskid:0, seqno:98561, flag:10, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:25, peer_index:0, vskid:0, seqno:106184, flag:10, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:25, peer_index:1, vskid:0, seqno:105981, flag:10, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:7, peer_index:1, vskid:0, seqno:63786, flag:2, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:23, peer_index:1, vskid:0, seqno:98561, flag:9, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:25, peer_index:0, vskid:0, seqno:106184, flag:9, Feb 20 08:37:17 net-mer-srx-ds01 /kernel: rts_commit_proposalmput op: 2, peer_type:25, peer_index:1, vskid:0, seqno:105981, flag:9,
Still trying I just test it in my lab. I can add L3 interface to PVLAN. When i try to ping from the switch to hosts, arp broadcast go to all community vlans. This is good
But there is no accepted reply from hosts:/
Please help.
root@ex3400-testowy1# show interfaces ge-0/0/0 { unit 0 { family ethernet-switching { interface-mode trunk; inter-switch-link; vlan { members 100; } } } } ge-0/0/1 { unit 0 { family ethernet-switching { vlan { members 101; } } } } ge-0/0/2 { unit 0 { family ethernet-switching { vlan { members 102; } } } } irb { unit 100 { proxy-arp unrestricted; family inet { address 192.168.0.1/24; } } }
klient1 { vlan-id 101; private-vlan community; } klient2 { vlan-id 102; private-vlan community; } pv100 { vlan-id 100; l3-interface irb.100; community-vlans [ klient1 klient2 ]; }
root@ex3400-testowy1# run show ethernet-switching table MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC) Ethernet switching table : 2 entries, 2 learned Routing instance : default-switch Vlan MAC MAC Age Logical NH RTR name address flags interface Index ID pv100 00:21:70:bb:e1:98 D - ge-0/0/2.0 0 0 pv100 00:21:70:c0:c9:cf D - ge-0/0/1.0 0 0
root@ex3400-testowy1# run show vlans extensive Routing instance: default-switch VLAN Name: default State: Active Tag: 1 Internal index: 2, Generation Index: 2, Origin: Static MAC aging time: 300 seconds VXLAN Enabled : No Number of interfaces: Tagged 0 , Untagged 0 Total MAC count: 0 Routing instance: default-switch VLAN Name: klient1 State: Active Tag: 101 PVLAN type : Community Internal index: 6, Generation Index: 6, Origin: Static MAC aging time: 300 seconds VXLAN Enabled : No Interfaces: ge-0/0/0.0,tagged,trunk,Inter-switch-link ge-0/0/1.0*,untagged,access Number of interfaces: Tagged 1 , Untagged 1 Total MAC count: 0 Routing instance: default-switch VLAN Name: klient2 State: Active Tag: 102 PVLAN type : Community Internal index: 7, Generation Index: 7, Origin: Static MAC aging time: 300 seconds VXLAN Enabled : No Interfaces: ge-0/0/0.0,tagged,trunk,Inter-switch-link ge-0/0/2.0*,untagged,access Number of interfaces: Tagged 1 , Untagged 1 Total MAC count: 0 Routing instance: default-switch VLAN Name: pv100 State: Active Tag: 100 PVLAN type : Primary Community VLAN : vlan-id : 101 vlan name : klient1 vlan-id : 102 vlan name : klient2 Internal index: 5, Generation Index: 5, Origin: Static MAC aging time: 300 seconds Layer 3 interface: irb.100 VXLAN Enabled : No Interfaces: ge-0/0/0.0,tagged,trunk,Inter-switch-link ge-0/0/1.0*,untagged,access ge-0/0/2.0*,untagged,access Number of interfaces: Tagged 1 , Untagged 2 Total MAC count: 2
Good find, thanks for the head's up.
Assuming that pv100 is your Primary vlan, I dont see these two statements which are required for pvlan to create and isolate the traffic
set vlans pv100 no-local-switching
You have to nest the community vlans under the primary vlan
set vlans klient1 primary-vlan pv100
set vlans klient2 primary-vlan pv100
Your output "show vlans extensive" does not show the pvlan_pvlan<#>_<interface>
The mode should show teh commuty vlan ALONG with
Community, Primary VLAN: pv100
the primary vlan
Those statements has been removed.
Ahh! Thats why it will not work. I just don't understand why remove the feature???!! I mean of what benefit is it remove that feature??
I think that just pvlan is configured in different way, but i still cant get it working.
in show vlans extensive i got:
Routing instance: default-switch VLAN Name: pv100 State: Active Tag: 100 PVLAN type : Primary Community VLAN : vlan-id : 101 vlan name : klient1 vlan-id : 102 vlan name : klient2
Yes you are correct. After reading more I realied the configuration you have is how it is done on els. This note maybe what is causing the issue:
If your PVLAN includes multiple switches, an issue can occur if the Ethernet switching table is cleared on a switch that does not have an IRB interface. If a Layer 3 packet transits the switch before its destination MAC address is learned again, it is broadcast to all the Layer 3 hosts connected to the PVLAN. Note: Each host device that you want to connect at Layer 3 must be in the same subnet as the IRB interface and use the IP address of the IRB interface as its default gateway address.
Take a look at this artcile specifically the verification outputs and see if they compare to your system
Yes, I read about it, but just lke you said nothing officail other than what reddit had posted. Hopefully the consumers using the product get the fix before it crashes. I think Juniper should reach out to them or even pay for an ad. The cost of both efforts will be worth much less than if a major consumer's systems were bricked. That fallout would be monumental.