Re: [j-nsp] Missing SNMP trapping
Hello!
What JUNOS version are you running?
I a while ago performed tests on a M120 running JUNOS 8.5. SNMP and
trapping was not the main objective, but I could see that trapping for
routing worked.
And of course your objects in SNMPc have the trap community SNMPc set?
(sorry for asking this stupid question).
Cheers
Patrik
--
>Has anyone here had problems setting up their Juniper router m120 to
report proper SNMP traps, specifically relating to routing protocols?
We're looking to receive SNMP trap notifications on BGP session
up/down states, and OSPF up/down states. We have setup the router
with the full compliment of categories but only receive up to this
point PIC power on/off states traps and SONET related traps.
We have the following configured;
snmp {
community 123456;
trap-options {
source-address x.x.x.x;
}
trap-group SNMPc {
version v2;
categories {
authentication;
chassis;
link;
remote-operations;
routing;
startup;
rmon-alarm;
vrrp-events;
configuration;
services;
sonet-alarms;
}
targets {
x.x.x.x;
}
}
}
Thanks,
Michael
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
BEGIN:VCARD
VERSION:2.1
N:Olsson;Patrik
FN:Patrik Olsson
ORG:;EMEA Tech Dev
TEL;WORK;VOICE:+46-733927834
TEL;CELL;VOICE:+46-733927834
ADR;WORK:;Stockholm;Arstaangsvagen 1A, bv;Stockholm;;S11743;Sweden
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Stockholm=0D=0AArstaangsvagen 1A, bv=0D=0AStockholm S11743=0D=0ASweden
EMAIL;PREF;INTERNET:pols...@juniper.net
REV:20070904T103433Z
END:VCARD
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Missing SNMP trapping
On Thu, 2009-02-12 at 10:35 -0800, Michael Phung wrote:
> Hello,
>
> Has anyone here had problems setting up their Juniper router m120 to
> report proper SNMP traps, specifically relating to routing protocols?
> We're looking to receive SNMP trap notifications on BGP session
> up/down states, and OSPF up/down states. We have setup the router
> with the full compliment of categories but only receive up to this
> point PIC power on/off states traps and SONET related traps.
>
OSPF and BGP traps work just fine on our M120's with this config:
trap-group mygroup {
version v2;
categories {
authentication;
chassis;
link;
remote-operations;
routing;
startup;
rmon-alarm;
vrrp-events;
configuration;
}
targets {
172.17.0.8;
}
}
Our snmptrapper (which was written based on trap-listener from
libsnmp-session-perl) logs these changes just fine:
BGP Change: Peer 195.69.144.223 (ams-ix.luna.nl, AS12902) went
Established (old state: Connect) on router jun1.galilei
The only thing Junipers don't trap, is BGP state changes for IPv6
peers :(
Regards,
Teun
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I wont speak for EX, since I am not sure. But for M/MX/T/TX the SNMP index for interfaces (used for graphing for instance) should not change due to reboot. I have not seen that in my small lab at least. What JUNOS version do you see this in? Cheer Patrik -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tore Anderson Sent: den 13 februari 2009 08:51 To: Malte von dem Hagen Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SNMP interface index change after upgrade to 9.2 * Malte von dem Hagen > we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a > while ago, and got the response from JTAC that this is expected behaviour. Unbelievable. This provokes me! I really hope that the idiot(s) that made this design desicion are no longer working at Juniper. Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting hours of my to clear up the mess this has caused, you're sadly mistaken! Not only is it fscking annoying - I use the data in my graphs for accounting too (and I think that's pretty common to do), so now valuable data used for invoicing customers is lost forever. And this was only for the MXes! My EXes have 100s of graphs... I don't want to even think about the hassle it would be to fix all of those manually. > Public interfaces get snmp ifIndex numbers *after* private interfaces, > so every time the private interfaces (whatever they exactly are) change, > the index numbers of public interfaces will change as well. And yes, > that is big PITA and very lame. Jesus. So reserve some room for the private interfaces and enumerate public ones staring from ifIndex 100 or 1000 or whatever, then. That wasn't too hard now was it? Juniper: to simpy say that this is just is COMPLETELY UNACCEPTABLE, it's a DEFECT, and it NEEDS to be FIXED. *fumes* -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp BEGIN:VCARD VERSION:2.1 N:Olsson;Patrik FN:Patrik Olsson ORG:;EMEA Tech Dev TEL;WORK;VOICE:+46-733927834 TEL;CELL;VOICE:+46-733927834 ADR;WORK:;Stockholm;Arstaangsvagen 1A, bv;Stockholm;;S11743;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Stockholm=0D=0AArstaangsvagen 1A, bv=0D=0AStockholm S11743=0D=0ASweden EMAIL;PREF;INTERNET:pols...@juniper.net REV:20070904T103433Z END:VCARD ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hi Patrik, * Patrik Olsson > I wont speak for EX, since I am not sure. But for M/MX/T/TX the SNMP > index for interfaces (used for graphing for instance) should not change > due to reboot. I have not seen that in my small lab at least. > > What JUNOS version do you see this in? It doesn't happen due to reboots, but due to JUNOS upgrades. Like I wrote in my original e-mail, after upgrading from 9.3R1.7 to 9.4R1.8 all of my graphs stopped working. (The original poster reported it happened going from 9.1R1.8 to 9.2R2.15.) The «you'll just have to live with it» answer Malte got from JTAC is unacceptable coming from a high-end vendor like Juniper. From a cheap no-name vendor it would be understandable, but I pay a premium for my Juniper gear and therefore I expect better. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hej, Tore Anderson wrote: It doesn't happen due to reboots, but due to JUNOS upgrades. Like I wrote in my original e-mail, after upgrading from 9.3R1.7 to 9.4R1.8 all of my graphs stopped working. (The original poster reported it happened going from 9.1R1.8 to 9.2R2.15.) The «you'll just have to live with it» answer Malte got from JTAC is unacceptable coming from a high-end vendor like Juniper. From a cheap no-name vendor it would be understandable, but I pay a premium for my Juniper gear and therefore I expect better. it does not happen due to *every* JunOS upgrade, but only if private interfaces snmp infrastructure changes between releases (said JTAC). Not that this relieves the pain... rgds, Malte ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Tore, Did you see this in your MX240s aswell? Patrik Sean Clarke> I believe this to be fixed in 9.4R1 , it's PR 408714, although the release notes don't mention it - perhaps it was a "confidential" PR hence not Sean Clarke> published in the release notes of 9.4 Sean Clarke> It was only affecting EX-series, not M/T/MX etc Sean Clarke> Sean Clarke> Hope this helps (a bit) BEGIN:VCARD VERSION:2.1 N:Olsson;Patrik FN:Patrik Olsson ORG:;EMEA Tech Dev TEL;WORK;VOICE:+46-733927834 TEL;CELL;VOICE:+46-733927834 ADR;WORK:;Stockholm;Arstaangsvagen 1A, bv;Stockholm;;S11743;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Stockholm=0D=0AArstaangsvagen 1A, bv=0D=0AStockholm S11743=0D=0ASweden EMAIL;PREF;INTERNET:pols...@juniper.net REV:20070904T103433Z END:VCARD ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
* Patrik Olsson > Did you see this in your MX240s aswell? Yes. I'll repeat myself: > An upgrade of two of my MX 240ies today, going from 9.3R1.7 to > 9.4R1.8, resulted in all of my graphs becoming hosed. Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
On 13/02/2009, at 6:21 PM, Tore Anderson wrote: Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting hours of my to clear up the mess this «feature» has caused, If using MRTG, and particularly if you use cfgmaker, you could always specify the "-ifref=descr" option. This will cause interface names rather than interface indexes to be placed in the generated config. This way if the ifIndex changes your graphs dont break. However, this would require at least one more SNMP operation each time MRTG runs to associate ifNames with ifIndexes (I am unsure if MRTG will do one walk to get a list of all ifNames and associated ifIndexes, or if it does it per interface). But at least you wont have to suffer the agony of updating all of your MRTG configs to accomodate changed ifIndexes. I too got over doing this, and now dont generate any MRTG configs using cfgmaker without the above option. Example from one of my MRTG configs, though its from a Cisco: Target[myrouter_FastEthernet0_0.2]: \FastEthernet0/0.2:pub...@myrouter: Give it a try. Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hi Tom, * Tom Storey > If using MRTG, and particularly if you use cfgmaker, you could always > specify the "-ifref=descr" option. I'm using Munin (http://munin.sf.net/). Unfortunately, its SNMP collectors relies on the ifIndex to remain constant, so I am out of luck. I appreciate you taking the time to send me the tip, though. Thank you! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Tore Anderson said: > Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting > hours of my to clear up the mess this «feature» has caused, you're sadly > mistaken! Not only is it fscking annoying - I use the data in my graphs > for accounting too (and I think that's pretty common to do), so now > valuable data used for invoicing customers is lost forever. Um, how about using modern software that doesn't assume static interface IDs? Interface IDs are never guaranteed to be static, so proper SNMP software should handle them changing. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I use Cacti (it is free), have not seen this issue (yet). I think I will poke around in it a bit, but I am with Chris and Tom in the spirit. Cheers Patrik BEGIN:VCARD VERSION:2.1 N:Olsson;Patrik FN:Patrik Olsson ORG:;EMEA Tech Dev TEL;WORK;VOICE:+46-733927834 TEL;CELL;VOICE:+46-733927834 ADR;WORK:;Stockholm;Arstaangsvagen 1A, bv;Stockholm;;S11743;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Stockholm=0D=0AArstaangsvagen 1A, bv=0D=0AStockholm S11743=0D=0ASweden EMAIL;PREF;INTERNET:pols...@juniper.net REV:20070904T103433Z END:VCARD ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Hej, Am 13.02.2009 13:15 Uhr, Chris Adams schrieb: > Um, how about using modern software that doesn't assume static interface > IDs? Interface IDs are never guaranteed to be static, so proper SNMP > software should handle them changing. what, if not ifIndex, should be a reasonable index for Interfaces? Neither ifName nor interface descriptions possibly stored in vendor specific MIBs are suitable values for constant reference. It is the ifIndex by design. Its main purpose IS referencing interfaces, and a simple update of the OS must not change them. I consider this as broken, like Tore does. rgds, Malte signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Malte von dem Hagen said: > Am 13.02.2009 13:15 Uhr, Chris Adams schrieb: > > Um, how about using modern software that doesn't assume static > > interface > > IDs? Interface IDs are never guaranteed to be static, so proper > > SNMP > > software should handle them changing. > > what, if not ifIndex, should be a reasonable index for Interfaces? > Neither ifName nor interface descriptions possibly stored in vendor > specific MIBs are suitable values for constant reference. Why do you consider ifDescr or ifName to be unsuitable? How do you configure your routers/switches, if not with interface names? > It is the ifIndex by design. Its main purpose IS referencing > interfaces, > and a simple update of the OS must not change them. I consider this as > broken, like Tore does. The purpose if ifIndex is to index the ifEntry list, nothing more. It is only specified to be constant as long as the system is not rebooted. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Once upon a time, Tore Anderson said: > It has been pointed out that not even MRTG, which I assume is the most > used traffic graphing suite, handles ifIndex changing (by default). > Keying off something else, like ifName, adds unnecessary overhead on the > polling station. I switched from MRTG to Cricket almost 10 years ago, in part because of this. Cricket can map on basically anything; it is very useful for all kinds of monitoring (not just router interface names). It keeps the overhead down by storing the index with the data. When it requests new data, it asks for the data and map field (e.g. ifDescr), and only if the map field no longer matches does it walk the whole tree to update the map (and when it walks the tree, it remembers it for mapping other interfaces). > I found that RFC 2863 says the following about ifIndex: > > The value for each interface must remain constant at least from one > re-initialization of the entity's network management system to the > next re-initialization. > > I'm not exactly sure what «re-initialization of the entity's network > management» means, but I guess a JUNOS upgrade probably qualifies. > Anyway, the «at least» part implies to me that it's even better if it's > constant across those re-initializations too. Any reboot (or even a daemon restart) is a re-initialization of the network management system. This was an issue when the first modular routers came out; it was years before router vendors offered any option to keep (or at least try to keep) static ifIndex values. Software has had a very long time to adapt, but I guess it hasn't all caught up yet. What if your router/switch fails, and you replace with a spare? The ifIndex values will all change then as well, since the stored ifIndex values are not in the regular config. It is much better to have software that handles that for you than to depend on static ifIndex values. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper SONET OC48/192
I'm just looking information about juniper 'PC-1OC192-SON-XFP, XFP-10G-L-OC192-SR1'. For this we need to have SDH or we can directly terminate into DWDM network. What will be the coloring scheme? How do you consider dB losses when interconnecting router optical interface to SDH which contains two to three ODFs on the path? What if I'm expecting -5 dBm -6 dBm losses, the above card will work or not. I'm looking the same thing for 'PC-4OC48-SON-SFP'.? Is there any document contacting deep details of such parameters for these modules. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SONET OC48/192
Hi many thanks for your email. Yea we are looking for OTN type equipment that insets colored laser directly into the DWDM system. Can you please give us some insights in detail on it. Second how much dB losses from transponder to PC-1OC192-SON-XFP PIC are supported. It will work with -6 or -7 dBm or not. It would be nice if you can describe this. Once again thanks for your quick response. -Original Message- From: Patrik Olsson [mailto:pols...@juniper.net] Sent: Friday, February 13, 2009 6:38 PM To: Andrew Jimmy Subject: RE: [j-nsp] Juniper SONET OC48/192 Hello! >I'm just looking information about juniper 'PC-1OC192-SON-XFP, >XFP-10G-L-OC192-SR1'. For this we need to have SDH or we can directly >terminate into DWDM network. What will be the coloring scheme? How do you >consider dB losses when interconnecting router optical interface to SDH >which contains two to three ODFs on the path? What if I'm expecting -5 dBm >-6 dBm losses, the above card will work or not. I'm looking the same thing >for 'PC-4OC48-SON-SFP'.? If you use PC-1OC192-SON-XFP with XFP-10G-L-OC192-SR1, you need a transponder in the DWDM system, you can not insert the signal directly since this type of XFP sends "normal" light. Same goes for PC-4OC48-SON-SFP with the SFP-1OC48-SR. The loss discussion is then not upto the XFP/SFP, since you need to use a transponder in the system, and the DWDM system will be the source of the colored light. Are you indeed looking for OTN type of equipment that inserts colored laser directly into the DWDM system? Cheers Patrik ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
Dear all, I do have the same problem. I am using M320, M120. I upgrade from 9.1R2.10 to 9.3R1.7, and my flow analysis can't get the right result because one of my analysis depends on the interface snmp index. Hope Juniper guy can response and get it fixed. cheers, Ethern On Fri, Feb 13, 2009 at 3:51 PM, Tore Anderson wrote: > * Malte von dem Hagen > >> we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a >> while ago, and got the response from JTAC that this is expected behaviour. > > Unbelievable. This provokes me! I really hope that the idiot(s) that > made this design desicion are no longer working at Juniper. > > Hey, Juniper, if you're reading this: Do you think that I ENJOY wasting > hours of my to clear up the mess this «feature» has caused, you're sadly > mistaken! Not only is it fscking annoying - I use the data in my graphs > for accounting too (and I think that's pretty common to do), so now > valuable data used for invoicing customers is lost forever. > > And this was only for the MXes! My EXes have 100s of graphs... I don't > want to even think about the hassle it would be to fix all of those > manually. > >> Public interfaces get snmp ifIndex numbers *after* private interfaces, >> so every time the private interfaces (whatever they exactly are) change, >> the index numbers of public interfaces will change as well. And yes, >> that is big PITA and very lame. > > Jesus. So reserve some room for the private interfaces and enumerate > public ones staring from ifIndex 100 or 1000 or whatever, then. That > wasn't too hard now was it? > > Juniper: to simpy say that this is just «expected behaviour» is > COMPLETELY UNACCEPTABLE, it's a DEFECT, and it NEEDS to be FIXED. > > *fumes* > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- = Ethern M., Lin, Network Division Computing Center, ACADEMIA SINICA Phone: +886-2-2789-9953 Fax : +886-2-2783-6444 = ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
It's a simple UNIX file 'dcd.snmp_ix' ("I believe Juniper guys don't change
format/syntax of the file with each upgrade."), if you back
/var/db/dcd.snmp_ix while upgrading your JUNOS software and then later
restore it.
ja...@r1> file list /var/db/dcd.snmp_ix
Regards,
Masood
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Patrik Olsson
Sent: Friday, February 13, 2009 5:19 PM
To: Chris Adams; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I use Cacti (it is free), have not seen this issue (yet). I think I will
poke around in it a bit, but I am with Chris and Tom in the spirit.
Cheers
Patrik
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IOS to JUNOS QoS
What is the equivalent to this in JUNOS, keeping in mind that I'm not pasting classes intentionally. Policy-map test-policy Class FTP Bandwidth percent 10 Class HTTP Bandwidth percent 20 ! Interface Serial 0/0/0 Bandwidth 1536 service-policy output test-policy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
On Fri, Feb 13, 2009 at 08:51:23AM +0100, Tore Anderson wrote: > * Malte von dem Hagen > > > we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a > > while ago, and got the response from JTAC that this is expected behaviour. > > Unbelievable. This provokes me! I really hope that the idiot(s) that > made this design desicion are no longer working at Juniper. Normally I'm the one yelling at Juniper when they do something stupid and break things for no reason, but honestly... Any software which relies on static ifIndex mappings between polling cycles is fundamentally flawed, period, end of discussion. There is absolutely no excuse for this, it is beyond trivial to map data by ifDescr, and the SNMP spec even tells you that ifIndex is not to be used for this kind of thing. I really don't understand why people still can't figure out how to do this. Here is an example of a very compact poller which does efficient retrieval using snmp bulk walk. All you need is php and the netsnmp lib, it's just a wrapper to a very simple C implementation which is 100x more efficient that the utter crap you'll find in mrtg, rtg, etc. You can easily use this to interface with any number of tools like rrdtool, sql, etc. http://www.e-gerbil.net/ras/snmp-php -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 1000baseT SFP unsupported in 9.4
Upon upgrading an EX4200-24F from 9.3R2.8 to 9.4R1.8, I found that the 1000baseT SFPs I had installed in it no longer worked. Is there a supported 1000baseT SFP for this switch? -- Jeff S Wheeler +1-212-981-0607 x8579 Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] preventing DoS attacks
Hi - does anyone know if it is possible on Junos to install a policers on
logical interfaces to prevent DoS attacks so that control plane as a whole
is identified in a filter rule?
Right now I see a default ARP policer is installed on every interface.
I want to customize this so that all traffic is policed (on 100s of my
logical interfaces). How do you identify control plane in such filter? I
have a bunch of loopback addresses in my box and do not want to specify each
IP address in my filter.
I'm looking for a keyword like "host-inbound-traffic" or something similar.
For example in CoS you can do this, you can classify all outbound control
traffic with a very few statements:
host-outbound-traffic {
forwarding-class network-control;
dscp-code-point af41;
}
I'm not interested in other implications of such approach at this point (for
example 'limiting BGP update rates is not good idea" and such), I don't
worry about BGP or other routing updates at this time. All I need to do is
prevent DoS on certain interfaces.
Thanks,
Marlon
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L2 vs L3 policing rates
Hi - anyone know if there is a way to set policing rates based on L2 packet length, as opposed L3 as it is default on Junos?Thanks, Marlon ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] preventing DoS attacks
On Fri, Feb 13, 2009 at 8:49 PM, Marlon Duksa wrote: > Hi - does anyone know if it is possible on Junos to install a policers on > logical interfaces to prevent DoS attacks so that control plane as a whole > is identified in a filter rule? > Right now I see a default ARP policer is installed on every interface. > I want to customize this so that all traffic is policed (on 100s of my > logical interfaces). How do you identify control plane in such filter? I > have a bunch of loopback addresses in my box and do not want to specify each > IP address in my filter. If you want to filter control plane traffic destined for the RE (as opposed to transit traffic) the easiest way to accomplish this would to apply a firewall-filter on the lo0.0 interface. Of course you can always protect it by applying the filter on the requisite incoming interfaces, but if you have a large number of interfaces you are faced with the dilemma as you suggest. Other options would be to use apply-groups and apply those filters to a large number of interfaces using wildcard matching. The Secure JUNOS template made available from the lovely folks at Team Cymru has lot's of good information on applying firewall-filters and protecting the control plane of your routers - http://www.cymru.com/gillsr/documents/junos-template.pdf. -- Stefan Fouant Yesterday it worked. Today it is not working. Windows is like that. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 vs L3 policing rates
On Fri, Feb 13, 2009 at 9:39 PM, Marlon Duksa wrote: > Hi - anyone know if there is a way to set policing rates based on L2 packet > length, as opposed L3 as it is default on Junos?Thanks, I could be wrong but my assumption would be that this is not possible. When a packet enters the router on an incoming PIC the Layer 2 header information is stripped by the I/O manager prior to creation of the notification cell which is sent to the IPII Processor. The IPII Processor handles the forwarding-table lookup, firewalling and policing features, amongst other things. As the L2 header information is not present in the notification cell, the IPII processor has no awareness of the L2 information - therefore policing on things such as L2 packet length is not possible. Somebody may correct me if I am wrong but this is my understanding... -- Stefan Fouant Yesterday it worked. Today it is not working. Windows is like that. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 vs L3 policing rates
Thanks Stefan. But maybe there is a statement that says how many bytes to prepend to each packet when policing.Something like that exists for ingress shaping already: pop-10# set chassis fpc 10 pic 3 traffic-manager ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups egress-shaping-overhead Number of CoS shaping overhead bytes in egress (0..255 bytes) ingress-shaping-overhead Number of CoS shaping overhead bytes in ingress (0..255 bytes) mode Configure traffic manager mode On Fri, Feb 13, 2009 at 7:41 PM, Stefan Fouant wrote: > On Fri, Feb 13, 2009 at 9:39 PM, Marlon Duksa wrote: > > Hi - anyone know if there is a way to set policing rates based on L2 > packet > > length, as opposed L3 as it is default on Junos?Thanks, > > I could be wrong but my assumption would be that this is not possible. > When a packet enters the router on an incoming PIC the Layer 2 header > information is stripped by the I/O manager prior to creation of the > notification cell which is sent to the IPII Processor. The IPII > Processor handles the forwarding-table lookup, firewalling and > policing features, amongst other things. As the L2 header information > is not present in the notification cell, the IPII processor has no > awareness of the L2 information - therefore policing on things such as > L2 packet length is not possible. > > Somebody may correct me if I am wrong but this is my understanding... > > -- > Stefan Fouant > > Yesterday it worked. > Today it is not working. > Windows is like that. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 vs L3 policing rates
On Fri, Feb 13, 2009 at 11:08 PM, Marlon Duksa wrote: > Thanks Stefan. But maybe there is a statement that says how many bytes to > prepend to each packet when policing. Why not just subtract the L2 overhead and set your firewall-filter to match on packets of a particular IP packet length using the packet-length match condition? -- Stefan Fouant Yesterday it worked. Today it is not working. Windows is like that. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
