Re: [j-nsp] BPDU Question
Hi Paul,
We've faced the same problem in the past and we created a firewall filter which
does what you want:
{master:0}[edit firewall family ethernet-switching filter BPDU_FILTER]
term 1 {
from {
destination-mac-address {
01:80:c2:00:00:00;
}
}
then {
discard;
count BPDU_FILTER;
}
}
term 2 {
then accept;
}
This is applied to the interface input filter.
Additionally, we disable the port in MSTP like 'prototocols mstp interface XXX
disable' so it does not send BPDU's to the customer.
I think with the newer JunOS versions there might be a better/smarter option
though.. :)
Regards,
Niels
-Oorspronkelijk bericht-
Van: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] Namens Paul Stewart
Verzonden: dinsdag 23 maart 2010 15:21
Aan: juniper-nsp@puck.nether.net
Onderwerp: [j-nsp] BPDU Question
Hi folks .. thanks to those who replied offline to my last question
(speed/duplex) - the answer was sitting right in front of me the whole time
lol
I have a new problem ... with our EX4200's we face many customer switches
and I need to filter BPDU's out. In the Cisco world we would setup a port
just like this:
interface GigabitEthernet3/2
description xxx
switchport
switchport access vlan 66
switchport mode access
switchport nonegotiate
no ip address
no cdp enable
no mop enabled
spanning-tree bpdufilter enable
What is the equivalent to this in Juniper? I tried setting up bpdu
protect one some interfaces but when it does see a BPDU packet it shuts the
port down - we can't have that occur ... we just want to filter out
BPDU's...
Thanks ;)
Paul
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
Please consider the environment before printing this e-mail.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper EX - Notification on STP topology change?
Hi All, We sometimes have STP toplogy changes and I would like to have some kind of notification for this. I've already tried doing this with SNMP traps and syslog, but both options didnt work. It can be logged to a file via ethernet-switching-options trace-options; it shows up in the logs then like this: Dec 31 05:46:52.324543 TCSM: Port ge-0/1/3.0: Inst 0: RCVDTC has been set, taking action.. Dec 31 05:46:52.999892 Port ge-0/1/0.0: Inst 0: Topology Change Machine Called with Event: RCVD_TC, State: INACTIVE Dec 31 05:46:53.325361 Port ge-0/1/3.0: Inst 0: Topology Change Machine Called with Event: RCVD_TC, State: ACTIVE Do you guys know a smart way to get these messages onto an external server so I can generate alerts etc? Thanks, Niels Tenzij schriftelijk anders is overeengekomen, zijn op al onze rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze zijn middels deze directe link http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk van de hand gewezen. Nederlands recht is exclusief van toepassing. De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden E-mail, noch voor tijdige ontvangst daarvan. Please consider the environment before printing this e-mail. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper EX - Notification on STP topology change?
I'm running 9.5R2.7 and I have the same SNMP options, but no trap is generated
on a STP change. It might be a new feature in JunOS 10.0..
We are now working with JunoScript to poll this periodically, this seems to go
well.
Thanks,
Niels
-Original Message-
From: Ben Dale [mailto:bd...@comlinx.com.au]
Sent: dinsdag 5 januari 2010 14:39
To: Niels Ardts
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Juniper EX - Notification on STP topology change?
Hi Niels
We sometimes have STP toplogy changes and I would like to have some kind of
notification for this.
I've already tried doing this with SNMP traps and syslog, but both options
didnt work. It can be logged to a file via ethernet-switching-options
trace-options; it shows up in the logs then like this:
SNMP Traps should work, however I just ran a quick test with JUNOS 10.0R1 and
according to Wireshark, the EX is sending SNMP Trap OID:
1.3.6.1.2.1.17.0.2 instead of:
1.3.6.1.2.1.17.2 which is the correct topology change notification.
My config is just:
root# show snmp
community public {
authorization read-only;
}
trap-group laptop {
categories {
chassis;
link;
remote-operations;
routing;
rmon-alarm;
services;
}
targets {
172.16.10.23;
}
}
Can anyone else confirm this? It's a bit late here and I may be losing it ; )
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
Please consider the environment before printing this e-mail.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Q-in-Q
Hi,
Actually, we have this working on 9.5R2.7... :)
You need to do the following:
Under ethernet-switching-options:
dot1q-tunneling {
ether-type 0x8100;
}
And then create the QinQ vlan:
{master:1}[edit vlans QinQvlan]
vlan-id 504;
interface {
ge-1/0/8.0; -- customer interface
xe-1/1/0.0; -- trunk interface
}
dot1q-tunneling;
You can show that it is operational:
run show vlans XXX extensive
VLAN: , Created at: Thu Dec 17 10:46:54 2009
802.1Q Tag: 504, Internal index: 39, Admin State: Enabled, Origin: Static
Dot1q Tunneling Status: Enabled
Protocol: Port Mode
Number of interfaces: Tagged 1 (Active = 1), Untagged 1 (Active = 1)
xe-1/1/0.0*, tagged, trunk
ge-1/0/8.0*, untagged, access
And in our case, xe-1/1/0 is having a lot of non QinQ vlans, so this is what
you are looking for I guess!
Best regards,
Niels
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth
Sent: maandag 28 december 2009 22:37
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX4200 Q-in-Q
This is not possible until 10.0 on the EX.
From: Kevin Wormington kw...@sofnet.com
To: juniper-nsp@puck.nether.net
Sent: Mon, December 28, 2009 2:29:15 PM
Subject: [j-nsp] EX4200 Q-in-Q
Hi All,
I'm fairly new to EX4200s and am running 9.6R1.13 on a three member stack.
Unfortunately, I already have live traffic on this so it somewhat limits my
ability to test. I would like to be able to configure a trunk port to have
some vlan members that are single-tagged and some that are double-tagged
(q-in-q). I was wondering if anyone has successfully done this?
Thanks,
Kevin
___
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
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
Please consider the environment before printing this e-mail.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrrp groups
Until now we've always used a seperate vrrp groupid for each vlan.
But after reading this message I decided to give it a try, since I totally
agree that it adds some complexity.
If I understand the post correct something like this should work:
n...@xx# show
vlan-id 241;
family inet {
filter {
input netflow;
output netflow;
}
address xx/27 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
address yy/28 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
}
However, an error is returned:
edit interfaces ae1 unit 241 family inet address yy]
'vrrp-group 241'
Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and
address:
error: configuration check-out failed
[edit interfaces ae1 unit 241]
We're running JunOS 8.0R2.8 on a M7i.
Any ideas?
Thanks!
Regards,
Niels
-Oorspronkelijk bericht-
Van: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski
Verzonden: dinsdag 29 september 2009 1:52
Aan: juniper-nsp@puck.nether.net
Onderwerp: Re: [j-nsp] vrrp groups
On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote:
Note that while you can assign the same group number to multiple ifls
on the same IFD best practice is not to as this can cause some issues
with learning bridges as noted below, each group shares the same v-mac.
I have to say -- this is a recommendation from Juniper that I've never
understood. We've used group 1 exclusively for years (with hundreds of
VLANs per interface in some cases) without issue. Using separate group IDs
seems overly complex and unnecessary. As long as your switches aren't
bleeding VLANs together there's no conceivable harm. (And if they do, having
the same group ID ensures you'll discover the problem quickly. :-)
To clarify for the original poster: there's no *hard limit* which will
prevent you from configuring 300 VRRP groups (with non-unique group IDs) on
one physical interface. (Even though the documentation said otherwise up
until 9.6.) I would expect things to generally be okay with default timers
but I've never tried group counts in the hundreds with anything smaller than
an m40e.
-Terry
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
Please consider the environment before printing this e-mail.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrrp groups
No, it is a different virtual address and also a completely different subnet!
-Oorspronkelijk bericht-
Van: Jonathan Brashear [mailto:jonathan.brash...@hq.speakeasy.net]
Verzonden: vrijdag 30 oktober 2009 17:11
Aan: Niels Ardts; 'Terry Baranski'; juniper-nsp@puck.nether.net
Onderwerp: RE: [j-nsp] vrrp groups
Just to verify, the /28 isn't a sub-set of the /27 is it? Junipers tend not to
like setting up multiple netblocks(like a /28 that's inside a
previously-configured /27) within the same interface, especially if you attempt
to set them both using the same virtual-address.
Network Engineer, JNCIS-M
214-981-1954 (office)
214-642-4075 (cell)
jbrash...@hq.speakeasy.net
http://www.speakeasy.net
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Niels Ardts
Sent: Friday, October 30, 2009 10:02 AM
To: 'Terry Baranski'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] vrrp groups
Until now we've always used a seperate vrrp groupid for each vlan.
But after reading this message I decided to give it a try, since I totally
agree that it adds some complexity.
If I understand the post correct something like this should work:
n...@xx# show
vlan-id 241;
family inet {
filter {
input netflow;
output netflow;
}
address xx/27 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
address yy/28 {
vrrp-group 241 {
virtual-address ;
priority 250;
advertise-interval 2;
accept-data;
}
}
}
However, an error is returned:
edit interfaces ae1 unit 241 family inet address yy]
'vrrp-group 241'
Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and
address:
error: configuration check-out failed
[edit interfaces ae1 unit 241]
We're running JunOS 8.0R2.8 on a M7i.
Any ideas?
Thanks!
Regards,
Niels
-Oorspronkelijk bericht-
Van: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski
Verzonden: dinsdag 29 september 2009 1:52
Aan: juniper-nsp@puck.nether.net
Onderwerp: Re: [j-nsp] vrrp groups
On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote:
Note that while you can assign the same group number to multiple ifls
on the same IFD best practice is not to as this can cause some issues
with learning bridges as noted below, each group shares the same v-mac.
I have to say -- this is a recommendation from Juniper that I've never
understood. We've used group 1 exclusively for years (with hundreds of
VLANs per interface in some cases) without issue. Using separate group IDs
seems overly complex and unnecessary. As long as your switches aren't
bleeding VLANs together there's no conceivable harm. (And if they do, having
the same group ID ensures you'll discover the problem quickly. :-)
To clarify for the original poster: there's no *hard limit* which will
prevent you from configuring 300 VRRP groups (with non-unique group IDs) on
one physical interface. (Even though the documentation said otherwise up
until 9.6.) I would expect things to generally be okay with default timers
but I've never tried group counts in the hundreds with anything smaller than
an m40e.
-Terry
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
Please consider the environment before printing this e-mail.
___
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] vrrp groups
Ah, yes that makes sense! Thanks for your explanation. -Niels Op 30 okt 2009 om 17:44 heeft Terry Baranski tbaran...@mail.com het volgende geschreven:\ On Fri, Oct 30, 2009 at 11:02AM, Niels Ardts wrote: However, an error is returned: edit interfaces ae1 unit 241 family inet address yy] 'vrrp-group 241' Duplicate interface: ae1 unit: 241 vrrp-group: 241 for address: and address: error: configuration check-out failed [edit interfaces ae1 unit 241] We're running JunOS 8.0R2.8 on a M7i. Any ideas? You're trying to use a given VRRP group ID twice on the same VLAN/subinterface. I'm not surprised that this doesn't commit -- the VRRP protocol itself probably doesn't support such a configuration. What will work is using the same group ID multiple times on different VLAN/subinterfaces within the same physical interface. -Terry -Oorspronkelijk bericht- Van: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] Namens Terry Baranski Verzonden: dinsdag 29 september 2009 1:52 Aan: juniper-nsp@puck.nether.net Onderwerp: Re: [j-nsp] vrrp groups On Mon, Sep 28, 2009 at 19:10:59, Harry Reynolds wrote: Note that while you can assign the same group number to multiple ifls on the same IFD best practice is not to as this can cause some issues with learning bridges as noted below, each group shares the same v- mac. I have to say -- this is a recommendation from Juniper that I've never understood. We've used group 1 exclusively for years (with hundreds of VLANs per interface in some cases) without issue. Using separate group IDs seems overly complex and unnecessary. As long as your switches aren't bleeding VLANs together there's no conceivable harm. (And if they do, having the same group ID ensures you'll discover the problem quickly. :-) To clarify for the original poster: there's no *hard limit* which will prevent you from configuring 300 VRRP groups (with non-unique group IDs) on one physical interface. (Even though the documentation said otherwise up until 9.6.) I would expect things to generally be okay with default timers but I've never tried group counts in the hundreds with anything smaller than an m40e. -Terry ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Tenzij schriftelijk anders is overeengekomen, zijn op al onze rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze zijn middels deze directe link http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/ of kunnen op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk van de hand gewezen. Nederlands recht is exclusief van toepassing. De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden E-mail, noch voor tijdige ontvangst daarvan. Please consider the environment before printing this e-mail. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200
I can remember we've had such an issue on 9.3R2, but at the end that turned out to be an hardware issue on one of the members of the VC. We're running 9.5R2.7 for about 6 weeks now and did not observe any issues anymore. The switches are used for 'simple' L2 forwarding with MSTP, no L3. We have come a long way with major bugs and issues (we started with 9.1R1!) but since 9.5 the platform is completely stable. BR, Niels -Oorspronkelijk bericht- Van: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] Namens Ross Vandegrift Verzonden: donderdag 20 augustus 2009 22:14 Aan: Brendan Mannella CC: juniper-nsp@puck.nether.net Onderwerp: Re: [j-nsp] EX4200 On Thu, Aug 20, 2009 at 08:15:57AM -0400, Brendan Mannella wrote: I have just went to 9.3r4.4 and it fixed most issues Seems very stable so far. Have you reported this issue to JTAC? Is it documented in a PR? This has huge potential impact for system I'll be turning live in the coming months, so the report makes for very good information. I'd like to see that addressed. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ 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
