[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