[j-nsp] Junos EX - mcsnoopd high cpu
Hi all, I have an issue with ex3200 devices on which mcsnoopd consumes a lot of cpu. I'm searching for mcsnoopd info everywhere, but it looks like there is not much about this, except message logs. The ex switches run the latest 10.4 release, and if you have a look at the releases notes there are already some fixes relates to mcsnoopd. question 1 : (maybe silly, but I ask anyway) Is it possible to stop the mcsnoopd on a device, if there is no multicast at all on the network ? (ie the switches are used as regular layer 2 switches with vlans). question 2 : is it possible to debug mcsnoopd ? thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos EX - mcsnoopd high cpu
Answer 1: edit set system processes multicast-snooping disable commit HTH Rgds Alex - Original Message - From: pkc mls pkc_...@yahoo.fr To: juniper-nsp@puck.nether.net Sent: Thursday, December 22, 2011 8:27 AM Subject: [j-nsp] Junos EX - mcsnoopd high cpu Hi all, I have an issue with ex3200 devices on which mcsnoopd consumes a lot of cpu. I'm searching for mcsnoopd info everywhere, but it looks like there is not much about this, except message logs. The ex switches run the latest 10.4 release, and if you have a look at the releases notes there are already some fixes relates to mcsnoopd. question 1 : (maybe silly, but I ask anyway) Is it possible to stop the mcsnoopd on a device, if there is no multicast at all on the network ? (ie the switches are used as regular layer 2 switches with vlans). question 2 : is it possible to debug mcsnoopd ? thanks. ___ 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: [j-nsp] Junos EX - mcsnoopd high cpu
I think you can check the multicast counters under all interfaces and see if they are increasing. Maybe someone is sending multicast traffic and you don't know. Thanks On 12/22/11, pkc mls pkc_...@yahoo.fr wrote: Hi all, I have an issue with ex3200 devices on which mcsnoopd consumes a lot of cpu. I'm searching for mcsnoopd info everywhere, but it looks like there is not much about this, except message logs. The ex switches run the latest 10.4 release, and if you have a look at the releases notes there are already some fixes relates to mcsnoopd. question 1 : (maybe silly, but I ask anyway) Is it possible to stop the mcsnoopd on a device, if there is no multicast at all on the network ? (ie the switches are used as regular layer 2 switches with vlans). question 2 : is it possible to debug mcsnoopd ? thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Sent from my mobile device ./diogo -montagner ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX VPLS Trunk with VLAN rewriting
Hi,
I'm trying to setup a VLPS Trunk (many VLANs - one VPLS instance) on
MX960 (Trio MPC) where each site has different local VLAN-IDs which
should be bridged over VPLS.
Example:
Site 1 VPLS Site 2
LAN1: vl100 vl10vl200
LAN2: vl301 vl11vl201
I did the following config:
Site1:
interfaces {
ae2 {
unit 100 {
encapsulation vlan-vpls;
vlan-id 100;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 301 {
encapsulation vlan-vpls;
vlan-id 301;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.100;
interface ae2.301;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 1;
interface ae2.100;
interface ae2.301;
}
mac-flush {
any-interface;
}
}
}
}
}
Site2:
interfaces {
ae2 {
unit 200 {
encapsulation vlan-vpls;
vlan-id 200;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 201 {
encapsulation vlan-vpls;
vlan-id 201;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.200;
interface ae2.201;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 2;
interface ae2.200;
interface ae2.201;
}
mac-flush {
any-interface;
}
}
}
}
}
When I try to commit this config I get an error:
[edit routing-instances test-service interface]
'ae2.100'
interface with input/output vlan-maps cannot be added to a routing-instance
with a vlan-id/vlan-tags configured
JunOS version is 11.2R4
When I remove vlan-id all from the VPLS instance the config commits
but no bridge is formed, the clients on each site cannot reach each
other.
Any idea what to do? Our Juniper consultant said it would be possible
to do this.
Regards
Sebastian
--
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 11.2R4.3 on MX
* Jeff Richmond jeff.richm...@gmail.com [2011-12-21 21:39]: Yes, doing a lab eval on it and it has a nasty mibd leak bug. Running a daily 11.2 build at the moment that fixes it (precursor to R5 coming out in January). So, I would wait for R5 if you plan on doing any SNMP work at all on the box. Same goes for VPLS, wait for 11.2R5, there is a bug which breaks VPLS when you change your config. Regards Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX VPLS Trunk with VLAN rewriting
I don't have the answer immediately for you, so I apologize.
But I wanted to chime in with a THIS IS WHAT I'M TALKING ABOUT comment. The
MX is super flexible and has loads of features with respect to
VLANs/BRIDGING/VPLS/PBB etc, but its confusing as shit and the documentation is
not the greatest.
There really ought to be an entire book *just* about this topic. Written in a
tutorial fashion. Covering Q-in-Q, VPLS, PBB, VLAN tag manipulation, bridging
features, etc. All on the MX specifically. It needs to cover the various
encapsulation types, family bridge, etc.
The MX solution guide isn't making it happen.
Still, I heart the MX immensely. Especially now that we are finally seeing
quality code on it... or better quality code anyway.
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://packetpushers.net/author/dwinkworth/
From: Sebastian Wiesinger juniper-...@ml.karotte.org
To: Juniper NSP juniper-nsp@puck.nether.net
Sent: Thursday, December 22, 2011 8:34 AM
Subject: [j-nsp] MX VPLS Trunk with VLAN rewriting
Hi,
I'm trying to setup a VLPS Trunk (many VLANs - one VPLS instance) on
MX960 (Trio MPC) where each site has different local VLAN-IDs which
should be bridged over VPLS.
Example:
Site 1 VPLS Site 2
LAN1: vl100 vl10 vl200
LAN2: vl301 vl11 vl201
I did the following config:
Site1:
interfaces {
ae2 {
unit 100 {
encapsulation vlan-vpls;
vlan-id 100;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 301 {
encapsulation vlan-vpls;
vlan-id 301;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.100;
interface ae2.301;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 1;
interface ae2.100;
interface ae2.301;
}
mac-flush {
any-interface;
}
}
}
}
}
Site2:
interfaces {
ae2 {
unit 200 {
encapsulation vlan-vpls;
vlan-id 200;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 201 {
encapsulation vlan-vpls;
vlan-id 201;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.200;
interface ae2.201;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 2;
interface ae2.200;
interface ae2.201;
}
mac-flush {
any-interface;
}
}
}
}
}
When I try to commit this config I get an error:
[edit routing-instances test-service interface]
'ae2.100'
interface with input/output vlan-maps cannot be added to a routing-instance
with a vlan-id/vlan-tags configured
JunOS version is 11.2R4
When I remove vlan-id all from the VPLS instance the config commits
but no bridge is formed, the clients on each site cannot reach each
other.
Any idea what to do? Our Juniper consultant said it would be possible
to do this.
Regards
Sebastian
--
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
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: [j-nsp] MX VPLS Trunk with VLAN rewriting
Hello,
Have you tried building this up from a very simple setup that works and adding
complexity as you go? I've done something like this with the vlan-id all
before but not with the VLAN tag manipulations at the same time.
The first thing that looks odd to me is the input-vlan map. Why do you need it?
Swap on egress should be enough. Another thing I'm not sure about is both
sub-interfaces in the same site. I'd put them in separate sites.
Try making this work by using the same VLAN on both ends, then add the VLAN
manipulation. I've got something that looks almost exactly the same as this in
my lab and it works:
interfaces {
ae2 {
unit 100 {
encapsulation vlan-vpls;
vlan-id 100;
}
unit 301 {
encapsulation vlan-vpls;
vlan-id 301;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.100;
interface ae2.301;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site vlan100 {
site-identifier 1;
interface ae2.100;
}
site vlan301 {
site-identifier 2;
interface ae2.301;
}
}
}
}
}
Use the same config on both ends, update the site-IDs to make all 4 unique.
If you get this working, start adding the egress swap. I am having trouble
reasoning how it will work. The box needs a way to know what traffic to
associate to which sub-interface. I don't think it can do that in this case.
I hope that helps.
Serge
From: Sebastian Wiesinger juniper-...@ml.karotte.org
To: Juniper NSP juniper-nsp@puck.nether.net
Sent: Thursday, December 22, 2011 10:34:43 AM
Subject: [j-nsp] MX VPLS Trunk with VLAN rewriting
Hi,
I'm trying to setup a VLPS Trunk (many VLANs - one VPLS instance) on
MX960 (Trio MPC) where each site has different local VLAN-IDs which
should be bridged over VPLS.
Example:
Site 1 VPLS Site 2
LAN1: vl100 vl10 vl200
LAN2: vl301 vl11 vl201
I did the following config:
Site1:
interfaces {
ae2 {
unit 100 {
encapsulation vlan-vpls;
vlan-id 100;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 301 {
encapsulation vlan-vpls;
vlan-id 301;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.100;
interface ae2.301;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 1;
interface ae2.100;
interface ae2.301;
}
mac-flush {
any-interface;
}
}
}
}
}
Site2:
interfaces {
ae2 {
unit 200 {
encapsulation vlan-vpls;
vlan-id 200;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 201 {
encapsulation vlan-vpls;
vlan-id 201;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.200;
interface ae2.201;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 2;
interface ae2.200;
interface ae2.201;
}
mac-flush {
any-interface;
}
}
}
}
}
When I try to commit this config I get an error:
[edit routing-instances test-service interface]
'ae2.100'
interface with input/output vlan-maps cannot be added to a routing-instance
with a vlan-id/vlan-tags configured
JunOS version is 11.2R4
When I remove vlan-id all from the VPLS instance the config commits
but no bridge is formed, the clients on each site cannot reach each
other.
Any idea what to do? Our Juniper consultant said it would be possible
to do this.
Regards
Sebastian
--
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
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: [j-nsp] MX VPLS Trunk with VLAN rewriting
* Serge Vautour sergevaut...@yahoo.ca [2011-12-22 17:28]: Hello, Have you tried building this up from a very simple setup that works and adding complexity as you go? I've done something like this with the vlan-id all before but not with the VLAN tag manipulations at the same time. Hi, yes I begun with a simple setup where I just connected two sites with one vlan on each site and vlan-id none. The VLAN manipulation is the only thing that doesn't seem to work. The first thing that looks odd to me is the input-vlan map. Why do you need it? Swap on egress should be enough. Another thing I'm not sure about is both sub-interfaces in the same site. I'd put them in separate sites. I need the input-vlan-map to rewrite the vlan tag so that it is the same in the vpls instance on both sites. The subinterfaces are on the same L2 switch, why should I put them in different sites? What if I have 100 subinterfaces, I can't (or don't want to) make 100 sites for that on every PE. Try making this work by using the same VLAN on both ends, then add the VLAN manipulation. I've got something that looks almost exactly the same as this in my lab and it works: If I have the same VLAN on both sites it works, but I don't have that in the production setup so that's not an option. :( Regards Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Unit ID's and q-in-q
I am wondering if any of you have suggestions for allocating unit numbers for q-in-q interfaces on the MX platform. For plain VLAN's it is quite easy; just use the VLAN as the unit ID. That does not work for q-in-q because unit numbers are integers. The obvious solution 1017 for outer 1010 inner 7 does not work either, as the unit ID seems to be limited to be at most 16384. Just adding them sequentially is a possibility, but with several hundred subinterfaces per physical interface it becomes challenging for operators to find the correct unit ID for a particular VLAN. Perhaps I will have to add a per-interface unit ID database to our provisioning system. Ideas are welcome! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Just do it sequentially and then write an op script that takes the vlan(s) as an argument to show you the interface info you are looking for... Sent from Yahoo! Mail on Android ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Policy based (firewall filter) VLAN Tag Manipulation on EX
Hey j-nsp Folks,
I'm pretty much at wit's end trying to get policy-based VLAN Tag Manipulation
working on an EX in a nice/non-convoluted way.
As per JNPR's docs, you can do 1:1 swapping by using the mapping statement
against an interface in the vlan declaration, in conjunction with declaring
your interface as access. This works because it dovetails in with the Q-in-Q
abilities on the EX. ( kb.juniper.net/InfoCenter/index?page=contentid=KB16755
). Note, you can also 'push' an outer VLAN tag onto an incoming VLAN as well,
thus making it effectively QinQ; although there's easier ways of accomplishing
this.
i.e.:
interfaces {
ge-0/0/0 {
mtu 9192;
unit 0 {
family ethernet-switching {
port-mode access;
}
}
}
}
vlans {
customer {
vlan-id 100;
interface {
ge-0/0/0.0 {
mapping {
30 {
swap;
}
}
}
}
}
}
This successfully makes ge-0/0/0 a trunk port, looking for incoming VLAN 30,
and translates to VLAN 100 and dumps the frame into my customer VLAN. (and
vice versa for egress traffic.. it gets re-written as VLAN 30 on egress).
(Note: you don't actually need to declare 'dot1q-tunneling' in the VLAN
definition stanza for this to work.. as it's just a straightforward 'swap' as
per JNPR's own docs).
Caveat:
You need to declare a mapping for every VLAN you want to use on that port
(since it's basically an access port now).
- You cannot declare the port as being 'trunk', lets say, to allow some
non-translcated tags to pass, and selectively translate others.
- i.e. I have 200 VLANs on that trunk, and only need to swap one of them, I
actually have to swap all 200 of them, albeit most of then just 'swap' to the
same VLAN ID.
- result: Nasty convoluted config to handle 1 vlan translation as an exception.
_
Better way:
So, the JNPR docs mention the ability to do policy-based (i.e. 'firewall
filter based') translation instead (Of course, no examples given that I could
see).
(
http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/qinq-tunneling-ex-series.html
) - See the section on Firewall filters allow you to map an interface to a
VLAN based on a policy, which requires use of firewall filter to map to a
VLAN, the vlan option has to be configured as part of the firewall filter and
the mapping policy option must be specified in the interface configuration for
each logical interface using the filter.
Which works like this:
interfaces {
ge-0/0/0 {
mtu 9192;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ ];
}
filter {
input vlan-translations;
}
}
}
}
firewall {
family ethernet-switching {
filter vlan-translations {
term map {
from {
dot1q-tag 30;
}
then {
accept;
vlan customer; // you could also say 'vlan 100' here..
either works.
}
}
term accept-all-else {
then {
accept; // Unless you like black-holing traffic... =)
}
}
}
}
}
vlans {
customer {
vlan-id 100;
interface {
ge-0/0/0.0 {
mapping {
policy;
}
}
dot1q-tunneling; // this time you need to include it, or it doesn't
work
}
}
}
So, this method allows you to use, say, vlan and as 'normal' trunked
VLANs, and if the port ever sees VLAN 30 come in, it'll translate it to VLAN
100. This makes the configuration nice (as you can use a standard trunk port
now, and just call the input filter to translate the 'exceptions' you need).
This actually works, but alas, it seems to work only in one direction
Result:
- Incoming Tag 30 gets translated to Tag 100.
- Outgoing Tag 100 stays as Tag 100. (I though the whole point of declaring
'mapping policy' was to make the EX 'aware' that you needed bi-directional
translation)
- I assume I'm doing something Just Plain Wrong[tm]... i.e. the EX was never
meant to do bi-directional translation this way.
tcpdump:
Incoming: Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 30, p 0,
ethertype ARP, arp who-has 10.102.255.3 tell 10.102.255.1
Outgoing: ethertype 802.1Q (0x8100), length 60: vlan 100, p 0, ethertype ARP,
arp reply 10.102.255.3 is-at 50:c5:8d:a0:5d:15
Incoming: Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 30, p 0,
ethertype ARP, arp who-has 10.102.255.3 tell 10.102.255.1
Outgoing:
