Re: [j-nsp] "Yellow led" and "Red led" alarms in Juniper
In addition, has anybody used those alarm relays on craft interface? If yes, then how? Connect a blinker? :-) regards, martin 2011/4/5 Martin T : > I see. And as I understand, there is no SNMP OID for "set chassis > alarm services rx-errors", "set chassis alarm ethernet link-down", > "set chassis alarm management-ethernet link-down" etc, but one should > configure the threshold value for those alarms(ignore/red/yellow) and > monitor "yellow alarm" and "red alarm" alerts in NMS(for example > Nagios)? Which means each time for example "red alarm" appears in NMS, > it may have multiple meanings? > > > regards, > martin > > 2011/4/5 Masagung Nugroho : >> Yellow led is minor alarms >> Red led is major alarms >> When first configuration yellow indicate the rescue configuration is not set >> >> Best Regards, >> -Masagung Nugroho- >> >> -Original Message- >> From: juniper-nsp-boun...@puck.nether.net >> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ido Szargel >> Sent: Tuesday, April 05, 2011 11:58 AM >> To: Martin T; juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] "Yellow led" and "Red led" alarms in Juniper >> >> Hi Martin, >> >> You have the "set chassis alarams" stanza where you can play with the >> chassis alarms levels (yellow/red/ignore) >> The most useful thing I use is to turn off the red alarm about the MGMT >> interface not connected to anything on EX switches. >> >> Regards, >> Ido. >> >> -Original Message- >> From: juniper-nsp-boun...@puck.nether.net >> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Martin T >> Sent: Tuesday, April 05, 2011 2:26 AM >> To: juniper-nsp@puck.nether.net >> Subject: [j-nsp] "Yellow led" and "Red led" alarms in Juniper >> >> As far as I know, all Juniper routers have "Yellow led" and "Red led" >> indicators on "craft interface". Few examples: >> >> http://www.juniper.net/techpubs/software/nog/nog-hardware/html/craft-interfa >> cea11.gif >> http://www.juniper.net/techpubs/software/nog/nog-hardware/html/craft-interfa >> cea4.gif >> http://www.juniper.net/techpubs/software/nog/nog-hardware/html/craft-interfa >> cea8.gif >> >> ..and one photo as well: >> >> http://blog.gyron.net/wp-content/uploads/mx240_right_low.png >> >> As I understand, yellow alarms are informative and red ones are critical. >> However, which alarms classify as "Yellow" and which ones classify as "Red"? >> Is there a possibility to change those thresholds? >> >> >> regards, >> martin >> ___ >> 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
Re: [j-nsp] MX and microbursting...
I assume you have queuing cards to do this? My understanding is that you
need Q or trio cards to do basic traffic shaping.
On Apr 11, 2011 5:28 PM, "Derick Winkworth" wrote:
> We've done that. Its the rx-ring on the controller in the NPE-G2. That
is not
> tunable. A show controller indicates we are basically microbursting 128
or more
> packets at a time (faster than the next cycle to pull packets off the
ring).
>
>
>
>
> Increasing the permanent buffers and the hold-queue definitely reduced the
> number of dropped packets significantly, but still over the last 8 hours
> (business day) I see about 10k drops. Granted, its over 1.2 billion
packets. I
> just don't like seeing 10k drops during the business day.
>
> I will apply traffic-shaping as per previous post.
>
>
>
>
> From: Chris Evans
> To: sth...@nethelp.no
> Cc: juniper-nsp@puck.nether.net
> Sent: Mon, April 11, 2011 3:15:59 PM
> Subject: Re: [j-nsp] MX and microbursting...
>
> You can adjust buffers on the 7200. It is not an interface parameter tho.
> On Apr 11, 2011 2:56 PM, wrote:
>>> {master}
>>> show configuration class-of-service fragmentation-maps
>>> DO_NOT_FRAG_RT-768
>>> forwarding-class {
>>> RT {
>>> no-fragmentation;
>>> }
>>> BE {
>>> fragment-threshold 768;
>>> }
>>> SG {
>>> fragment-threshold 768;
>>> }
>>> }
>>
>> Eh? He said GigE. According to
>>
>>
>
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-services/fragmentation-maps-edit-cos.html
>
>>
>> fragmentation-maps is for link service IQ interfaces only.
>>
>> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>> ___
>> 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX and microbursting...
Sorry - Jumped the gun there.
Had the issue with MX -7200 for APS(lsq) interface which were resolved by
those statements there.
-Nitin
On Mon, Apr 11, 2011 at 11:52 AM, wrote:
> > {master}
> > show configuration class-of-service fragmentation-maps
> > DO_NOT_FRAG_RT-768
> > forwarding-class {
> >RT {
> >no-fragmentation;
> >}
> >BE {
> >fragment-threshold 768;
> >}
> >SG {
> >fragment-threshold 768;
> >}
> > }
>
> Eh? He said GigE. According to
>
>
> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-services/fragmentation-maps-edit-cos.html
>
> fragmentation-maps is for link service IQ interfaces only.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX and microbursting...
We've done that. Its the rx-ring on the controller in the NPE-G2. That is not
tunable. A show controller indicates we are basically microbursting 128 or
more
packets at a time (faster than the next cycle to pull packets off the ring).
Increasing the permanent buffers and the hold-queue definitely reduced the
number of dropped packets significantly, but still over the last 8 hours
(business day) I see about 10k drops. Granted, its over 1.2 billion packets.
I
just don't like seeing 10k drops during the business day.
I will apply traffic-shaping as per previous post.
From: Chris Evans
To: sth...@nethelp.no
Cc: juniper-nsp@puck.nether.net
Sent: Mon, April 11, 2011 3:15:59 PM
Subject: Re: [j-nsp] MX and microbursting...
You can adjust buffers on the 7200. It is not an interface parameter tho.
On Apr 11, 2011 2:56 PM, wrote:
>> {master}
>> show configuration class-of-service fragmentation-maps
>> DO_NOT_FRAG_RT-768
>> forwarding-class {
>> RT {
>> no-fragmentation;
>> }
>> BE {
>> fragment-threshold 768;
>> }
>> SG {
>> fragment-threshold 768;
>> }
>> }
>
> Eh? He said GigE. According to
>
>
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-services/fragmentation-maps-edit-cos.html
>
> fragmentation-maps is for link service IQ interfaces only.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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
Re: [j-nsp] MX and microbursting...
I was thinking of just applying a shaping-rate at the port level. As it stands not more than 300m or so could ever pass through this interface (based ultimately on the sum of the interfaces the traffic is routing to at the WAN edge). It turns out actually there is an EX-4200 between the MX and the 7200. So I'm thinking of just applying a port-level shaper on the EX at 400m or 500m. Flow-control is a no go. From: "sth...@nethelp.no" To: dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net Sent: Mon, April 11, 2011 1:13:08 PM Subject: Re: [j-nsp] MX and microbursting... > I have tuned up buffers and hold-queues on the 7200 and this has drastically > reduced the number of dropped packets, but still there is this rx-ring > limitation. This is actually a fairly well known issue as I understand it. > > Is there anything I could do on the MX to control the microbursting outbound > towards the 7200? You might be able to do something with Ethernet flow control - I don't remember if the NPE-G2 can send pause frames. However, most likely you have to do shaping on the MX. Shaping can buffer and smooth out bursts. Obviously, to do this it has to *delay* some packets. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX and microbursting...
You can adjust buffers on the 7200. It is not an interface parameter tho.
On Apr 11, 2011 2:56 PM, wrote:
>> {master}
>> show configuration class-of-service fragmentation-maps
>> DO_NOT_FRAG_RT-768
>> forwarding-class {
>> RT {
>> no-fragmentation;
>> }
>> BE {
>> fragment-threshold 768;
>> }
>> SG {
>> fragment-threshold 768;
>> }
>> }
>
> Eh? He said GigE. According to
>
>
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-services/fragmentation-maps-edit-cos.html
>
> fragmentation-maps is for link service IQ interfaces only.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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 and microbursting...
> {master}
> show configuration class-of-service fragmentation-maps
> DO_NOT_FRAG_RT-768
> forwarding-class {
>RT {
>no-fragmentation;
>}
>BE {
>fragment-threshold 768;
>}
>SG {
>fragment-threshold 768;
>}
> }
Eh? He said GigE. According to
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-services/fragmentation-maps-edit-cos.html
fragmentation-maps is for link service IQ interfaces only.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX and microbursting...
{master}
show configuration class-of-service fragmentation-maps
DO_NOT_FRAG_RT-768
forwarding-class {
RT {
no-fragmentation;
}
BE {
fragment-threshold 768;
}
SG {
fragment-threshold 768;
}
}
Try this.
-Nitin
On Mon, Apr 11, 2011 at 10:43 AM, Derick Winkworth wrote:
> All:
>
> I have a Cisco 7206VXR w/NPE-G2 attached to an MX. The issue I am seeing
> is
> ignored packets on the 7200. It turns out, the 1G interfaces on the NPE-G2
> have
> 128 packet rx-rings and this is not a tunable thing.
>
>
> I have tuned up buffers and hold-queues on the 7200 and this has
> drastically
> reduced the number of dropped packets, but still there is this rx-ring
> limitation. This is actually a fairly well known issue as I understand it.
>
> Is there anything I could do on the MX to control the microbursting
> outbound
> towards the 7200?
>
> Derick
> ___
> 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 and microbursting...
> I have tuned up buffers and hold-queues on the 7200 and this has drastically > reduced the number of dropped packets, but still there is this rx-ring > limitation. This is actually a fairly well known issue as I understand it. > > Is there anything I could do on the MX to control the microbursting outbound > towards the 7200? You might be able to do something with Ethernet flow control - I don't remember if the NPE-G2 can send pause frames. However, most likely you have to do shaping on the MX. Shaping can buffer and smooth out bursts. Obviously, to do this it has to *delay* some packets. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX and microbursting...
All: I have a Cisco 7206VXR w/NPE-G2 attached to an MX. The issue I am seeing is ignored packets on the 7200. It turns out, the 1G interfaces on the NPE-G2 have 128 packet rx-rings and this is not a tunable thing. I have tuned up buffers and hold-queues on the 7200 and this has drastically reduced the number of dropped packets, but still there is this rx-ring limitation. This is actually a fairly well known issue as I understand it. Is there anything I could do on the MX to control the microbursting outbound towards the 7200? Derick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does any one knows who fix Juniper Power Supply?
No, I have never seen 740-001465 with such problem. I just knew the PSN-2003-12-001. As I told before, I would take the PSU apart and try to understand, how the fan-sensing circuitry is built(which chips and sensors are used). There is a some sort of daughter-card in the 740-001465- maybe this includes the fan-sensing circuitry. regards, martin 2011/4/8 Juan C. Crespo R. : > Hi > > Yes, both match with that model > > Power Supply A REV 03 740-001465 > Power Supply B REV 03 740-001465 > > Do you know how to fix it?, replacing FAN? something like that? > > Thanks > > > > On 08/04/2011 10:40 a.m., Martin T wrote: >> >> Juan, >> was your PSU 740-001465 one of those? >> >> M20 AC PWR-M20-AC-S 740-001465 Revision 7 and earlier >> M20 DC PWR-M20-DC-S 740-001466 Revision 8 and earlier >> >> >> regards, >> martin >> >> 2011/4/4 Juan C. Crespo R.: >>> >>> You're completely right >>> >>> Thanks >>> On 04/04/2011 10:03 a.m., Paul Stewart wrote: Presume you have no J-Care on them? -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Juan C. Crespo R. Sent: Monday, April 04, 2011 9:44 AM To: Juniper Request Help List Subject: [j-nsp] Does any one knows who fix Juniper Power Supply? Hi Guys, could any one of you tell me some company who can repair Juniper Power Supply? I got 3 with the FAN Failed Alarm, but all the FANS are Working so I don't know what to do!!!, if any one of you could give me a hand with any company contacts, i will appreciate this too much.! I try with another Junos and its the same result Juniper Power Supply Part Number 740-001465 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 >>> >> > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper "firewall policer" inner workings
Keegan,
policer configuration is shown here:
http://img690.imageshack.us/img690/3162/iperftest.png
Sthaug,
thanks for explanation! So basically one might describe small buffer
vs larger buffer with following drawing:
http://img24.imageshack.us/img24/3777/leakybucket.png (I'm not very
good with Gimp :P ) Water flows our from both buckets(the 1024KB one
and the 512KB one) with consistent rate of 10Mbps. If water is poured
into the buckets with inconsistent rate, the larger buffer is less
sensitive to bursts while in case of a small buffer, high burst might
cause water to overflow(packet loss).
Chris,
with such policer:
firewall {
policer bw-10Mbps {
filter-specific;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 512k;
}
then discard;
}
}
..results between 192.168.1.1 and 192.168.2.1 were following:
IPERF:
# iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 0.04 MByte (default)
Client connecting to 192.168.2.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 0.01 MByte (default)
[ 4] local 192.168.1.1 port 47344 connected with 192.168.2.1 port 5001
[ 3] local 192.168.1.1 port 5001 connected with 192.168.2.1 port 38624
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 71.5 MBytes 10.0 Mbits/sec
[ 4] Sent 51021 datagrams
[ 3] 0.0-60.0 sec 69.9 MBytes 9.77 Mbits/sec 0.034 ms 1186/51021 (2.3%)
[ 3] 0.0-60.0 sec 1 datagrams received out-of-order
[ 4] Server Report:
[ 4] 0.0-60.0 sec 69.9 MBytes 9.77 Mbits/sec 0.126 ms 1192/51020 (2.3%)
[ 4] 0.0-60.0 sec 1 datagrams received out-of-order
#
NUTTCP:
[root@ ~]# nuttcp -4 -u -Ri10M -T1m -v 192.168.2.1
nuttcp-t: v6.1.2: socket
nuttcp-t: buflen=1024, nstream=1, port=5001 udp -> 192.168.2.1
nuttcp-t: time limit = 60.00 seconds
nuttcp-t: rate limit = 10.000 Mbps (instantaneous), 1220 pps
nuttcp-t: send window size = 9216, receive window size = 42080
nuttcp-t: 71.2344 MB in 60.12 real seconds = 1213.27 KB/sec = 9.9391 Mbps
nuttcp-t: 72951 I/O calls, msec/call = 0.84, calls/sec = 1213.39
nuttcp-t: 9.1user 50.2sys 1:00real 98% 106i+1046d 490maxrss 0+1pf 0+11723csw
nuttcp-r: v6.1.2: socket
nuttcp-r: buflen=1024, nstream=1, port=5001 udp
nuttcp-r: send window size = 109568, receive window size = 109568
nuttcp-r: available send window = 82176, available receive window = 82176
nuttcp-r: 69.4453 MB in 60.12 real seconds = 1182.79 KB/sec = 9.6894 Mbps
nuttcp-r: 1832 / 72944 drop/pkt 2.51% data loss
nuttcp-r: 71116 I/O calls, msec/call = 0.87, calls/sec = 1182.86
nuttcp-r: 0.0user 0.4sys 1:00real 0% 0i+0d 0maxrss 0+6pf 71045+2csw
[root@ ~]#
So basically the packet loss was pretty much the same with both
utilities. However, in order to wrap this "Juniper "firewall policer"
inner workings" topic up, the main thing is that while Juniper counts
the network layer header into the 10Mbps policer, the iperf/nuttcp
don't :)
regards,
martin
2011/4/9 Chris Tracy :
> Hi Martin,
>
>> Iperf UDP is indeed very bursty- I ran "iperf -c 192.168.2.1 -u -fm
>> -t60 -d -b 10m" and at the same time did "tcpdump -w iperf_dump.pcap
>> host 192.168.2.1". Then printed deltas <...>
>
> Yes, as you can see from these results, the majority of the packets are
> spaced very close (~11-12 microseconds apart).
>
> If you just look at the first few hundred lines of the tcpdump -ttt output,
> you'll also see the burst / wait / burst / wait / burst pattern.
>
>> However, if I ran "nuttcp -4 -u -Ri10M -v -T1m -w2m 192.168.2.1" and
>> at the same time did "tcpdump -w nuttcp_dump.pcap host 192.168.2.1",
>> the most popular delta values between packets are way higher than with Iperf:
>> ...
>> As you said, in case of nuttcp UDP flood, packets are much more evenly sent
>> :)
>
> Right, and you can make nuttcp more bursty by doing -Ri10M/5 or -Ri10M/10 to
> instruct it to burst 5 or 10 packets at a time, respectively. By default,
> nuttcp will pace packets as evenly as possible at the expense of burning a
> core. Keep in mind that the behavior of iperf more closely emulates a
> typical application -- I don't think users would find it very acceptable to
> burn up their CPU just to do precise rate-limiting. :-)
>
> So, did you lose less packets through your policer when testing with nuttcp
> vs iperf, assuming the same policer settings in the middle?
>
>> Could you explain this "Your interface speed appears to be GigE, so
>> you are bursting out at line rate and relying on the buffers in the
>> router to accommodate these line-rate bursts. You should have
>> different results if you connected the host at FastE vs GigE." a bit
>> further? I mean why should I see differe
