Re: [j-nsp] IPv6 firewall filter for Route-Engine protection
Hello Harry and all,
Is there any update on how we can possibly match the second next-header?
As far as I know this affects all Junos products, currently only the first
header can be checked, correct?
Thank you,
George
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Harry Reynolds
Sent: Tuesday, January 24, 2012 12:26 AM
To: Alex D.; Juniper-Nsp
Subject: Re: [j-nsp] IPv6 firewall filter for Route-Engine protection
You want to use next-header keyword matches for v6. Note, you can opnly
match on one/the first next-header.
From:
http://tools.ietf.org/html/rfc6192#appendix-A.2
family inet6 {
filter protect-router-control-plane-v6 {
term fragv6 {
from {
next-header fragment;
}
then {
count frag-v6-discards;
log;
discard;
}
}
Dugal, et al. Informational[Page 21]
RFC 6192 Protect Router Control PlaneMarch 2011
term icmpv6 {
from {
next-header icmpv6;
}
then {
policer 500kbps;
accept;
}
}
term ospfv3 {
from {
source-address {
FE80::/10;
}
next-header ospf;
}
then accept;
}
term ibgpv6-connect {
from {
source-prefix-list {
IBGPv6-NEIGHBORS;
}
next-header tcp;
destination-port bgp;
}
then accept;
}
term ibgpv6-reply {
from {
source-prefix-list {
IBGPv6-NEIGHBORS;
}
next-header tcp;
port bgp;
}
then accept;
}
term ebgpv6-connect {
from {
source-prefix-list {
EBGPv6-NEIGHBORS;
}
next-header tcp;
destination-port bgp;
}
then accept;
}
HTHs
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Alex D.
Sent: Monday, January 23, 2012 2:22 PM
To: Juniper-Nsp
Subject: [j-nsp] IPv6 firewall filter for Route-Engine protection
Hello guys,
i try to build a basic inet6 firewall filter for Route-Engine protection
on Juniper MX80 running JUNOS 10.4R8.5.
It seems that there is no support for protocol match in from statement.
Is there actually no possibility for protocol match (e.g. tcp, udp,
ospf3) or do i forget something ?
Can someone give me a hint for a basic filter ?
Regards,
Alex
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
On Fri, 17 Aug 2012, Jensen Tyler wrote: Quick google for VPLS Multihoming found me this: http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/feature-guide/vpls-multihoming-bgp-signaling-solutions.html Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC Jensen, VPLS multihoming assumes you are intentionally building out a loop-free VPLS domain. My situation is when you have a downstream customer who unintentionally introduces a loop in their Layer2 domain that causes MAC learning table thrashing back inside your VPLS instance. Thanks for the pointer though. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
Quick google for VPLS Multihoming found me this: http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/feature-guide/vpls-multihoming-bgp-signaling-solutions.html Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Clarke Morledge Sent: Friday, August 17, 2012 10:09 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations? We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ 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] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
On Fri, Aug 17, 2012 at 8:08 AM, Clarke Morledge chm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. This is probably not the answer you're looking for, but the best solution is to not bridge to your access switches. Everything in the EX series is capable of routing, so why not take advantage of that functionality? Barring that, your options are: storm control, MAC limiting, and MAC move limiting. I've never found storm control to be that useful. It reduces the volume of frames but usually not enough to cancel out all of the negative effects. MAC limiting with a reasonable MAC limit on a port can cause the port to be disabled if too many addresses are seen coming from said port. MAC move limiting is configured per VLAN. It can detect a layer 2 loop with a smaller number of MAC addresses than MAC limiting would, but my concern has always been that (as far as I can tell) there's no way to determine which interface would end up being disabled - it would be bad to have it pick a trunk between your core switches instead of the trunk to the IDF. None of these will ever be as effective as routing. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I believe there was a thread on here within the last month about an event script for the MX platform that would do just that. Going back to the first section, though, you should think thrice before doing VPLS - Ivan PepeInjak has some good articles about the hazards of L2 across your wan on his blog. HTH :w ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
Hi, ...on Fri, Aug 17, 2012 at 11:08:53AM -0400, Clarke Morledge wrote: switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. Not that I've used it myself yet, but the aptly named MAC Move Limiting might help here, though usefulness might depend on the actual topology:: http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/port-security-mac-limiting-and-mac-move-limiting.html Alex. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
What about TRILL? Not sure if Juniper has jumped on the TRILL bandwagon yet. -- Regards, Ge Moua Univ of Minn Alumnus -- On 08/17/2012 11:06 AM, Wayne Tucker wrote: On Fri, Aug 17, 2012 at 8:08 AM, Clarke Morledgechm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. This is probably not the answer you're looking for, but the best solution is to not bridge to your access switches. Everything in the EX series is capable of routing, so why not take advantage of that functionality? Barring that, your options are: storm control, MAC limiting, and MAC move limiting. I've never found storm control to be that useful. It reduces the volume of frames but usually not enough to cancel out all of the negative effects. MAC limiting with a reasonable MAC limit on a port can cause the port to be disabled if too many addresses are seen coming from said port. MAC move limiting is configured per VLAN. It can detect a layer 2 loop with a smaller number of MAC addresses than MAC limiting would, but my concern has always been that (as far as I can tell) there's no way to determine which interface would end up being disabled - it would be bad to have it pick a trunk between your core switches instead of the trunk to the IDF. None of these will ever be as effective as routing. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I believe there was a thread on here within the last month about an event script for the MX platform that would do just that. Going back to the first section, though, you should think thrice before doing VPLS - Ivan PepeInjak has some good articles about the hazards of L2 across your wan on his blog. HTH :w ___ 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] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
Hi Clarke, We pass through BPDUs through VPLS the MX'es- but yes, miscreant users / switches will always be a problem. We do the following to every customer-facing VPLS instance, but only #3 would help you here: 1. Mac Limiting per VPLS Interface (100) (i.e per 'site') 2. Mac Limiting per VPLS (500) 3. Limit Broadcast/Unknown Unicast/Multicast Traffic (5 Mbit) into the VPLS You can put on an input firewall filter which calls a 5 Mbit policer at [routing instances vpls-name forwarding-options family vpls ] to start limiting this type of traffic into the 'bridge domain' at any time. - CK. On 18/08/2012, at 1:08 AM, Clarke Morledge chm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ 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
[j-nsp] QFX3500 LLDP service crash
Hi! (platform:QFX3500, junos:12.2X50-D10.3) Have a problem with LLDP service on QFX3500 Service never starts on boot without any log-lines. When i try to restart it manually have that crash-report: serj@qfx3500-p2a restart lldpd-service error: Link Layer Discovery Protocol is not running Link Layer Discovery Protocol started, pid 90798 serj@qfx3500-p2a show log messages Aug 18 03:50:04 qfx3500-p2a mgd[41086]: UI_RESTART_EVENT: User 'serj' restarting daemon 'Link Layer Discovery Protocol' Aug 18 03:50:04 qfx3500-p2a init: lldpd-service (PID 90798) started Aug 18 03:50:04 qfx3500-p2a /kernel: cpuid = 0 Aug 18 03:50:04 qfx3500-p2a /kernel: BAD_PAGE_FAULT: pid 90798 (lldpd), uid 0: pc 0x57bca4 got a read fault at 0x4 Aug 18 03:50:04 qfx3500-p2a /kernel: Trapframe Register Dump: Aug 18 03:50:04 qfx3500-p2a /kernel: zero: at: 0001 v0: 0004v1: 0189 Aug 18 03:50:04 qfx3500-p2a /kernel: a0: 0004a1: 0005 a2: 00a22190a3: 0001 Aug 18 03:50:04 qfx3500-p2a /kernel: t0: 002bt1: 77feb62d t2: 77feb62dt3: Aug 18 03:50:04 qfx3500-p2a /kernel: t4: ff00t5: t6: t7: 001c Aug 18 03:50:04 qfx3500-p2a /kernel: t8: 00fft9: 0057bc50 s0: 0004s1: 0001 Aug 18 03:50:04 qfx3500-p2a /kernel: s2: 0001s3: s4: 00a09c00s5: Aug 18 03:50:04 qfx3500-p2a /kernel: s6: 00a0c000s7: 0001 k0: k1: Aug 18 03:50:04 qfx3500-p2a /kernel: gp: 00979120sp: 77feaf00 s8: 77feaf00ra: 0057bc34 Aug 18 03:50:04 qfx3500-p2a /kernel: sr: 50809813badvaddr: 0004 Aug 18 03:50:04 qfx3500-p2a /kernel: mullo: 000c mulhi: Aug 18 03:50:04 qfx3500-p2a /kernel: cause: 0008 pc: 0057bca4 Aug 18 03:50:04 qfx3500-p2a /kernel: Page table info for pc address 0x57bca4: pde = 0x87d6b000, pte = 0x4109271a Aug 18 03:50:04 qfx3500-p2a /kernel: Dumping 4 words starting at pc address 0x57bca4: Aug 18 03:50:04 qfx3500-p2a /kernel: 8c42 afc20020 8fc20020 1444 Aug 18 03:50:05 qfx3500-p2a init: lldpd-service (PID 90798) terminated by signal number 11. Core dumped! Aug 18 03:50:22 qfx3500-p2a init: lldpd-service is thrashing, not restarted Somebody have any ideas? -- Sergey Tkachenko +38-050-3266737 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 LLDP service crash
On Fri, Aug 17, 2012 at 5:56 PM, Sergey T pu...@puhis.net wrote: Hi! (platform:QFX3500, junos:12.2X50-D10.3) Have a problem with LLDP service on QFX3500 Service never starts on boot without any log-lines. When i try to restart it manually have that crash-report: serj@qfx3500-p2a restart lldpd-service error: Link Layer Discovery Protocol is not running Link Layer Discovery Protocol started, pid 90798 serj@qfx3500-p2a show log messages Aug 18 03:50:04 qfx3500-p2a mgd[41086]: UI_RESTART_EVENT: User 'serj' restarting daemon 'Link Layer Discovery Protocol' Aug 18 03:50:04 qfx3500-p2a init: lldpd-service (PID 90798) started Aug 18 03:50:04 qfx3500-p2a /kernel: cpuid = 0 Aug 18 03:50:04 qfx3500-p2a /kernel: BAD_PAGE_FAULT: pid 90798 (lldpd), uid 0: pc 0x57bca4 got a read fault at 0x4 Aug 18 03:50:04 qfx3500-p2a /kernel: Trapframe Register Dump: Aug 18 03:50:04 qfx3500-p2a /kernel: zero: at: 0001 v0: 0004v1: 0189 Aug 18 03:50:04 qfx3500-p2a /kernel: a0: 0004a1: 0005 a2: 00a22190a3: 0001 Aug 18 03:50:04 qfx3500-p2a /kernel: t0: 002bt1: 77feb62d t2: 77feb62dt3: Aug 18 03:50:04 qfx3500-p2a /kernel: t4: ff00t5: t6: t7: 001c Aug 18 03:50:04 qfx3500-p2a /kernel: t8: 00fft9: 0057bc50 s0: 0004s1: 0001 Aug 18 03:50:04 qfx3500-p2a /kernel: s2: 0001s3: s4: 00a09c00s5: Aug 18 03:50:04 qfx3500-p2a /kernel: s6: 00a0c000s7: 0001 k0: k1: Aug 18 03:50:04 qfx3500-p2a /kernel: gp: 00979120sp: 77feaf00 s8: 77feaf00ra: 0057bc34 Aug 18 03:50:04 qfx3500-p2a /kernel: sr: 50809813badvaddr: 0004 Aug 18 03:50:04 qfx3500-p2a /kernel: mullo: 000c mulhi: Aug 18 03:50:04 qfx3500-p2a /kernel: cause: 0008 pc: 0057bca4 Aug 18 03:50:04 qfx3500-p2a /kernel: Page table info for pc address 0x57bca4: pde = 0x87d6b000, pte = 0x4109271a Aug 18 03:50:04 qfx3500-p2a /kernel: Dumping 4 words starting at pc address 0x57bca4: Aug 18 03:50:04 qfx3500-p2a /kernel: 8c42 afc20020 8fc20020 1444 Aug 18 03:50:05 qfx3500-p2a init: lldpd-service (PID 90798) terminated by signal number 11. Core dumped! Aug 18 03:50:22 qfx3500-p2a init: lldpd-service is thrashing, not restarted Somebody have any ideas? -- Sergey Tkachenko +38-050-3266737 __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp I would stick with recommended releases (11.3R5.5 afaik). I run 11.3R5.3 right now without any problems (besides some 3rd party optics still locked out by Juniper). If you follow every release, you will be hurting. -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
