[j-nsp] Resource Temporarily Unavailable - Juniper MX
Humair Ali
humair at premier.com.pk
Thu Dec 15 14:36:24 EST 2011
I think it is cuz of bgp prefix size
Thanks
Humair Ali
Sent from my iPad
On Dec 15, 2011, at 11:38 PM, "juniper-nsp-request at puck.nether.net" <juniper-nsp-request at puck.nether.net> wrote:
> Send juniper-nsp mailing list submissions to
> juniper-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> or, via email, send a message with subject or body 'help' to
> juniper-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> juniper-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of juniper-nsp digest..."
>
>
> Today's Topics:
>
> 1. Re: default Junos on EX4200s currently shipping (Chuck Anderson)
> 2. Re: default Junos on EX4200s currently shipping (Chris Cappuccio)
> 3. Re: default Junos on EX4200s currently shipping (Jeff Wheeler)
> 4. Re: Difference MX DPC-R / DPCE-R (Richard A Steenbergen)
> 5. Re: traffic drops to 8 Gb/s when a firewall filter is applied
> (Richard A Steenbergen)
> 6. Re: Resource Temporarily Unavailable - Juniper MX
> (Richard A Steenbergen)
> 7. Re: traffic drops to 8 Gb/s when a firewall filter is applied
> (Keegan Holley)
> 8. Re: default Junos on EX4200s currently shipping (Mark Tinka)
> 9. DA rejects (Paul Stewart)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Dec 2011 17:14:04 -0500
> From: Chuck Anderson <cra at WPI.EDU>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] default Junos on EX4200s currently shipping
> Message-ID: <20111214221404.GF21253 at angus.ind.WPI.EDU>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Dec 14, 2011 at 04:45:26PM -0500, Jeff Wheeler wrote:
>> Dear List, and Juniper lurkers!
>>
>> The EX4200s we have been purchasing lately are coming with Junos
>> 11.2R1.2 installed from the factory. That version is totally
>
> Are these the old EX4200-48P, or the new PoE+ EX4200-48PX models? The
> new models require 11.2 (but they should have loaded a later R).
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 Dec 2011 14:09:18 -0800
> From: Chris Cappuccio <chris at nmedia.net>
> To: Morgan McLean <wrx230 at gmail.com>
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] default Junos on EX4200s currently shipping
> Message-ID: <20111214220918.GK2377 at ref.nmedia.net>
> Content-Type: text/plain; charset=us-ascii
>
> Morgan McLean [wrx230 at gmail.com] wrote:
>> How does that kind of code even pass QA to start? I really don't understand.
>>
>
> Somewhere between 1996 and 2006, Juniper used to regularly sell equipment based on being BETTER than Cisco, whose software was notoriously bad and whose platforms were behind the curve.
>
> After that time, juniper started to move to the same category as Cisco. That is, big and dumb. Now you have Idiocracy-style software that crashes on boot, shipped out of the factory by default.
>
> What next?
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 14 Dec 2011 18:27:59 -0500
> From: Jeff Wheeler <jsw at inconcepts.biz>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] default Junos on EX4200s currently shipping
> Message-ID:
> <CAPWAtbK+W5ifcGntt+3AhT_Sbxs-3GFY8uQhnrfUZ53ia0hu1Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Dec 14, 2011 at 5:14 PM, Chuck Anderson <cra at wpi.edu> wrote:
>> Are these the old EX4200-48P, or the new PoE+ EX4200-48PX models? ?The
>> new models require 11.2 (but they should have loaded a later R).
>
> This is the vanilla EX4200-48T. I can't imagine why it is shipping
> with 11.2R1.2. I just got these last week. My last batch had
> 10.something and at least weren't crashing right out of the box.
>
> --
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator? /? Innovative Network Concepts
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 14 Dec 2011 18:46:15 -0600
> From: Richard A Steenbergen <ras at e-gerbil.net>
> To: Nicolaj Kamensek <nsp at accelerated.de>
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Difference MX DPC-R / DPCE-R
> Message-ID: <20111215004614.GY35473 at gerbil.cluepon.net>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Dec 12, 2011 at 05:05:20PM +0100, Nicolaj Kamensek wrote:
>> Hello list,
>>
>> can anyone name the major differences between those modules? DPC are
>> becoming available in the used market for small money and I am wondering
>> if a DPC non-E is good enough for a classical access router environment
>> with 30.000+ ARP entries and a growing number of IPv6 neighbours but
>> nothing fancy overall.
>> Since it's hard to find any facts about this:
>>
>> - does it matter memory-wise if the requirements above are applied to
>> just one routed port or to multiple switched/routed ports?
>> - do bundled links still double the amount of memory required?
>
> Well since nobody has answered this one correctly I guess I'll do it...
> The only difference between DPC and DPCE is the size of the microcode on
> the EZChip ASIC used for L2 framing (1.5KB vs 6KB instruction space).
>
> Almost no features require the larger microcode space, so you should be
> pretty safe... When the DPCs first came out, almost nothing used the
> EZChips at all, and even over the last couple years the only thing I've
> seen that doesn't like running on the Rev A's is PBB (Provider Backbone
> Bridging). Maybe you can get someone from Juniper to provide a more
> extensive list, but it's pretty safe to assume that nothing about the
> config you mentioned above will be impacted by DPC non-E's at all.
>
> --
> Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 14 Dec 2011 19:33:05 -0600
> From: Richard A Steenbergen <ras at e-gerbil.net>
> To: Keegan Holley <keegan.holley at sungard.com>
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] traffic drops to 8 Gb/s when a firewall filter is
> applied
> Message-ID: <20111215013305.GZ35473 at gerbil.cluepon.net>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Dec 09, 2011 at 01:19:54PM -0500, Keegan Holley wrote:
>> Yea but it should have enough silicon to do simple policing in
>> hardware unless you have every single other feature on the box
>> enabled. If a policer with no queueing, and no marking etc, caused
>> throughput to decrease by 20% across the board I'd inquire about their
>> return policy. Hopefully, it's the policer config. Most of my 10G
>> interfaces do not require policers, but I've got 1G interfaces with
>> hundreds of logicals each with a unique policer.
>
> Unfortunately not... There are all kinds of ways to make I-chip cards
> not deliever line rate performance even with relatively simple firewall
> rules, and it's very poorly logged when this does happen. Admittedly
> I've never seen a simple "then accept" push it over the edge, but maybe
> it was RIGHT on the edge before... Try looking for some discards, such
> as WAN_DROP_CNTR, on the *INGRESS* interface (i.e. not the one where you
> added the egress filter). For xe-x/y/0 do:
>
> start shell pfe network fpc<x>
> show ichip <y> iif stat
>
> example:
>
> Traffic stats:
> Counter Name Total Rate Peak Rate
> ---------------------- ---------------- -------------- --------------
> GFAB_BCNTR 4229125816477883 949530 1276098290
> KA_PCNTR 0 0 0
> KA_BCNTR 0 0 0
> Discard counters:
> Counter Name Total Rate Peak Rate
> ---------------------- ---------------- -------------- --------------
> WAN_DROP_CNTR 298 0 82
> FAB_DROP_CNTR 1511 0 419
> KA_DROP_CNTR 0 0 0
> HOST_DROP_CNTR 0 0 0
>
> --
> Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 14 Dec 2011 19:38:59 -0600
> From: Richard A Steenbergen <ras at e-gerbil.net>
> To: Paul Stewart <paul at paulstewart.org>
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Resource Temporarily Unavailable - Juniper MX
> Message-ID: <20111215013859.GA35473 at gerbil.cluepon.net>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Dec 05, 2011 at 07:48:22AM -0500, Paul Stewart wrote:
>> Can anyone shed some light on these log messages?
>>
>> Nov 30 04:48:21 core2.toronto1 rpd[1359]: bgp_send: sending 19 bytes to
>> xx.xxx.52.50 (External AS xxxxx) blocked (no spooling requested): Resource
>> temporarily unavailable
>
>> grep "Resource temporar" /usr/include/errno.h
> #define EAGAIN 35 /* Resource temporarily unavailable */
>
>> man 2 send
> ...
>
> [EAGAIN] The socket is marked non-blocking and the requested
> operation would block.
>
> It's just a socket message saying it can't write the data it wants to
> write into that particular TCP session... This COULD potentially
> indicate a problem, such as congestion or errors, but it can also just
> be a quick dump of data filling up the socket buffer before the other
> side can read it. 99% odds are this is cosmetic. :)
>
> --
> Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 14 Dec 2011 21:04:16 -0500
> From: Keegan Holley <keegan.holley at sungard.com>
> To: Richard A Steenbergen <ras at e-gerbil.net>
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] traffic drops to 8 Gb/s when a firewall filter is
> applied
> Message-ID:
> <CABO8Q6S2oXd9ObD75FDF8unyJd=nvgW1Y+JvMpz-ZDsE98P7fQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I
>
>
> 2011/12/14 Richard A Steenbergen <ras at e-gerbil.net>
>
>> On Fri, Dec 09, 2011 at 01:19:54PM -0500, Keegan Holley wrote:
>>> Yea but it should have enough silicon to do simple policing in
>>> hardware unless you have every single other feature on the box
>>> enabled. If a policer with no queueing, and no marking etc, caused
>>> throughput to decrease by 20% across the board I'd inquire about their
>>> return policy. Hopefully, it's the policer config. Most of my 10G
>>> interfaces do not require policers, but I've got 1G interfaces with
>>> hundreds of logicals each with a unique policer.
>>
>> Unfortunately not... There are all kinds of ways to make I-chip cards
>> not deliever line rate performance even with relatively simple firewall
>> rules, and it's very poorly logged when this does happen. Admittedly
>> I've never seen a simple "then accept" push it over the edge, but maybe
>> it was RIGHT on the edge before... Try looking for some discards, such
>> as WAN_DROP_CNTR, on the *INGRESS* interface (i.e. not the one where you
>> added the egress filter). For xe-x/y/0 do:
>>
>> start shell pfe network fpc<x>
>> show ichip <y> iif stat
>>
>> example:
>>
>> Traffic stats:
>> Counter Name Total Rate Peak Rate
>> ---------------------- ---------------- -------------- --------------
>> GFAB_BCNTR 4229125816477883 949530 1276098290
>> KA_PCNTR 0 0 0
>> KA_BCNTR 0 0 0
>> Discard counters:
>> Counter Name Total Rate Peak Rate
>> ---------------------- ---------------- -------------- --------------
>> WAN_DROP_CNTR 298 0 82
>> FAB_DROP_CNTR 1511 0 419
>> KA_DROP_CNTR 0 0 0
>> HOST_DROP_CNTR 0 0 0
>>
>> --
>> Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
>> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>>
>>
>
> I see your point, but I'd still be surprised if a defaulted box with a
> "then accept" filter would drop by this much. You could see the be queue
> discarding packets in the sh int output. The be queue is given 95% of the
> buffer in the default schedule map which still leaves 1G plus unaccounted
> for. Maybe it's a little bit of both.
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 15 Dec 2011 12:40:46 +0800
> From: Mark Tinka <mtinka at globaltransit.net>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] default Junos on EX4200s currently shipping
> Message-ID: <201112151240.49998.mtinka at globaltransit.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Thursday, December 15, 2011 05:45:26 AM Jeff Wheeler
> wrote:
>
>> Perhaps putting a Junos on the switches that is remotely
>> stable when shipping them out from the factory would be
>> a good idea.
>
> I suppose "stable" is in the eye of the beholder :-).
>
> Given regression testing seems to be going down the toilet
> at Juniper (well, let's just say it's not as robust as it
> used to be; either that or the software has outgrown it),
> without the kind of experiences kit and code go through in
> the mine field to call on, I can see why Juniper would ship
> out newer code as stable code.
>
> Mark.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: This is a digitally signed message part.
> URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20111215/7547f728/attachment-0001.sig>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 15 Dec 2011 13:28:11 -0500
> From: "Paul Stewart" <paul at paulstewart.org>
> To: <juniper-nsp at puck.nether.net>
> Subject: [j-nsp] DA rejects
> Message-ID: <006801ccbb57$4e2e0750$ea8a15f0$@paulstewart.org>
> Content-Type: text/plain; charset="us-ascii"
>
> Hey there..
>
>
>
> Can anyone provide some further light on DA rejects on a GigE interface?
>
>
>
> Filter statistics:
>
> Input packet count 24198
>
> Input packet rejects 9074
>
> Input DA rejects 9074
>
>
>
> I'm trying to figure out the cause of so many packets getting rejected -
> read through some docs and it seems MAC address related if I understood.
>
>
>
> This is a layer3 customer facing port (Juniper MX480) and the customer is
> having issues passing traffic. They have a Sonicwall device on their side
> running in "transparent mode" - which translates to the same MAC address
> getting reused a couple dozen times by all the IP's in their /28 block.
>
>
>
> I can't see anything on our side causing these packet rejects but also not
> used to seeing them . any thoughts from folks who have seen them?
>
>
>
> Thanks ;)
>
>
>
> Paul
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> juniper-nsp mailing list
> juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> End of juniper-nsp Digest, Vol 109, Issue 9
> *******************************************
More information about the juniper-nsp
mailing list