from:"Richard A Steenbergen"

On Fri, Jan 06, 2012 at 09:34:35PM -0500, Chuck Anderson wrote:
 Like I said, that is nuts.  I will NEVER buy the QFX then as long as
 this vendor arrogance exists.  And don't give me this but we
 haven't tested it with every possible SFP+ vendor so we can't allow
 you to use any vendor crap.

FWIW they've actually had serious problems interoperating correctly with 
copper SFPs from other vendors, on EX and MX. There are still unsolved 
issues with ports showing link state up despite nothing being plugged 
in. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] QFX3500 optics lock?

On Sat, Jan 07, 2012 at 11:45:40AM +, Phil Mayers wrote:
 Oh for the love of...
 
 In terms of practical what now ideas, have you tried to source a 
 Juniper compatible SFP+ i.e. someone has blown the string into the 
 EEPROM? Or maybe investigate FlexOptix' flexBox?

FWIW eoptolink's stock SFP+'s seem to not set off the NON-JNPR flag in 
EX without any additional hackery required, though I have no clue at all 
if they'd work properly in a QFX.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] QFX3500 optics lock?

On Sun, Jan 08, 2012 at 02:27:44PM +1100, Julien Goodwin wrote:
 
 Nobody is asking Juniper to *support* third party optics, they never 
 have before. All we want is, that like all other Juniper products to 
 date (that I'm aware of) that third party optics work, and have 
 feature parity.

Be careful what you ask for... We've seen many issues with the support 
for third party optics, for example we still have ongoing issues with 
Cisco copper SFPs which show link up despite nothing being plugged in 
when used in an MX80... It's not as bad as a blatant lock, but if they 
don't have to support it they don't need to fix it either. :)

The better way to say it is, we aren't going to call you and make you 
fix it if it's just one broken optic doing something bad, but we still 
expect you to make every reasonable effort to make your product work 
correctly with other standards compliant components.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] QFX3500 optics lock?

On Sun, Jan 08, 2012 at 12:11:19PM +, Phil Mayers wrote:
 However - crappy though they were, imagine my irritation when, even 
 with service unsupported-transceiver, a duplicate SFP serial number 
 caused err-disable on BOTH ports, and requires BOTH transceivers to be 
 removed.
 
 It's not obvious to me that this is a reasonable response; the 1st 
 transceiver was in, and forwarding packets. Why disable it? What 
 possible value does that add?

Actually, this one I get... They're trying to detect and block a 
counterfeit product that says Cisco on it, and which as you said, was 
introduced into the supply chain without your knowledge that it was an 
inferior fake (and maybe even without your VARs knowledge too). This is 
COMPLETELY different from artificially disabling a third party's 
product.

Of course, if they weren't so busy trying to do the later there wouldn't 
be nearly as much demand for people doing the former, but they're still 
probably justified in blocking the duplicate serial #'s of Cisco 
products.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] QFX3500 optics lock?

On Mon, Jan 09, 2012 at 11:37:03PM +, Phil Mayers wrote:
 
 I am not trying to compare this to vendor locking. They are indeed 
 completely different, and I merely cite it as illustration of one other 
 position on the spectrum of transceiver permissiveness.
 
 I will grant that denying the new optic is understandable. But 
 shutting down an existing link is deeply unhelpful (as well as TOTALLY 
 NON-OBVIOUS to the person inserting the optics).
 
 For starters - what if the existing link is a Genuine Cisco(tm) SFP? 
 Then the forged SFP not only doesn't work (fine) but stops a valid SFP 
 from working (not fine). Unlikely I will admit, but not impossible.
 
 I will also add that I have no evidence this duplicate checking is 
 limited to transceivers matching CISCO* in the EEPROM; for all I know, 
 it does it for any transceiver...

In theory the way it's supposed to work is that a cryptographically 
verifiable code based on the serial number (probably some sort of hash, 
but no clue what they actually use) is written to the EEPROM. That way, 
Cisco can give the actual manufacturers a list of SN's and codes equal 
to the number of units they're purchasing, to prevent the classic 
counterfeiting problem of the factory in China running during the day 
for the customer and at night for themselves.

But even without defeating the hash, they can always just clone the 
serial number from a known good one... Of course in theory there should 
never be two identical serial numbers, so when they do show up in the 
same chassis you should be guaranteed that they're both counterfeit. 
Of course, I'm sure mistakes do happen from time to time, and you could 
make the argument that it's bad to affect production customer traffic if 
the customer didn't know, but there is at least some logic behind it.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Junos 11.2R4.3 on MX

2011-12-24 Thread Richard A Steenbergen

On Sat, Dec 24, 2011 at 09:27:55PM +0800, Mark Tinka wrote:
 On Friday, December 23, 2011 07:51:45 PM Sebastian Wiesinger 
 wrote:
 
  Oh and to fix it you have to reset the VPLS BGP sessions.
  Changing the config back does not help.
 
 That's a nasty bug.

So, just another day using JUNOS then? :)

It would almost be funny, if it wasn't so tragic.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] DA rejects

2011-12-18 Thread Richard A Steenbergen

On Sat, Dec 17, 2011 at 08:11:39AM -0500, Paul Stewart wrote:
 
 It has magically started working again for the customer, which is 
 quite strange.  Again, very confident this is a CPE issue but wanted 
 to ensure I understood how JunOS will look at ARP output like above 
 (make sure there is no confusion) :)

Erm, did you move the customer to a new endpoint on your side? If so, 
you were probably receiving DA Rejects because they had your old router 
MAC address stuck in their arp cache, and it magically fixed itself 
when their ARP cache timed out and it re-learned the gateway mac.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] DA rejects

2011-12-18 Thread Richard A Steenbergen

On Thu, Dec 15, 2011 at 02:11:18PM -0500, randy.tay...@bell.ca wrote:
 I have seen this before facing Cisco device running CDP.  Maybe you 
 have something that is running on your box that it does not 
 understand.

DA Rejects are when your router receive receives a packet that is 
destined for a MAC address that isn't it... This is normal/expected 
behavior in small doses, since even on a switched network the unknown 
unicast flooding stage of MAC learning will result in a few packets 
being sent to ports that weren't actually the correct destinations. If 
the router was an ordinary host these would be the type of packets you 
would need to turn on promiscuous mode to see.

This is not to be confused with L3 Incompletes, which is what you're 
probably thinking about re: CDP. This simply means a packet without a L3 
header that the router doesn't know what to do with (since the Juniper 
device doesn't speak CDP), and thus discards.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Difference MX DPC-R / DPCE-R

2011-12-14 Thread Richard A Steenbergen

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 r...@e-gerbil.net   http://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

Re: [j-nsp] traffic drops to 8 Gb/s when a firewall filter is applied

2011-12-14 Thread Richard A Steenbergen

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 fpcx
show ichip y iif stat

example:

  Traffic stats:
 Counter NameTotal   Rate  Peak Rate
   --  -- --
   GFAB_BCNTR 4229125816477883 949530 1276098290
 KA_PCNTR0  0  0
 KA_BCNTR0  0  0
  Discard counters:
 Counter NameTotal   Rate  Peak Rate
   --  -- --
WAN_DROP_CNTR  298  0 82
FAB_DROP_CNTR 1511  0419
 KA_DROP_CNTR0  0  0
   HOST_DROP_CNTR0  0  0

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Resource Temporarily Unavailable - Juniper MX

2011-12-14 Thread Richard A Steenbergen

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 x) 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 r...@e-gerbil.net   http://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

Re: [j-nsp] Summarize Global Table

2011-10-25 Thread Richard A Steenbergen

On Tue, Oct 25, 2011 at 06:45:27PM +0100, Phil Mayers wrote:
 
 This (aggregate routes on next-hop) comes up now and again, and the 
 idea seems to be controversial for some people. Various criticisms are 
 cited - unpredictability (a single route change could result in a 
 large jump in FIB use), performance implications, and fairly limited 
 improvement (the thread cited below reckons 30% mean, 10% worst case, 
 45% best case, depending on connectivity topology)

Foundry did dynamic FIB aggregation using a covering default route to 
remove more specifics 10-some years ago, back when they had routers 
with only enough CAM for 8k or 16k FIB entries (ye olde Ironcore days). 
It actually worked pretty darn well, and the improvement IS significant 
in my experience (anyone who claims otherwise is full of shit or not 
being realistic in their modeling). It's also pretty straightforward to 
implement, I could prototype the code for it in a few minutes.

The only REAL objections seem to be:

a) The benefits are very non-deterministic, and customers may/will be 
confused if they make one covering route change and it causes thousands 
of FIB entries to be created or destroyed as a result. Nobody likes 
confusing customers more than is necessary, especially when your support 
organization is as disasterously broken as JTAC.

b) It's not entirely impossible that doing this won't cause breakage in 
some unanticipated way. For example, say someone rapidly flaps a 
covering route, which causes a lot of FIB churn. There are a lot of 
potential implementations for performance, interaction with the krt, 
etc. Somebody has to actually take the time to model and test this to 
make sure it doesn't cause something to break/crash/blackhole/etc in 
practice. I'm personally not sure it would actually be any worse than 
the hour+ times to install a full FIB that some of these boxes are 
suffering from already, but I can understand why nobody is particularly 
eager to jump in and own this issue if they don't have to do so.

c) Vendors would much rather sell you new cards wih more FIB capacity 
than find a way to implement a free solution in software (big shocker, 
I know). :)

Of course given the EX8200 situation, where they've knowingly sold a 
bunch of cards that can't possibly do what they claimed they could do, 
maybe a horde of pissed off customers will motivate some renewed 
interest in providing some software assistance.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] TCAM full on EX8200?

2011-10-23 Thread Richard A Steenbergen

On Sun, Oct 23, 2011 at 01:20:28PM +0400, Pavel Lunin wrote:
 TBH, I haven't checked the pricing but I'd expect Brocade MLX
 
 MLX(e) is an edge device and is much like MX in most things. It's 
 cheaper but at a cost of some features lack and few caveats. Although 
 it's a good product, it's not a label-oriented LSR anyway.

The hardware functionality for label switching in MLX/XMR seems to be 
fine (as far as I can tell), it's only the software that is still a 
giant mess. To be honestly they seem to be ok for very simple stuff like 
pseudowires, but last I looked things like rsvp-te were still a complete 
and total mess. Global Crossing recently tried to roll out XMRs as pure 
LSR supercore boxes alongside existing T640s, and a whole bunch of 
blackholing and pissed off customers later they seem to have abandoned 
that project and moved the boxes to L3 edge router roles. As I said, I 
have yet to find ANY vendor other than Cisco/Juniper who ACTUALLY 
understand MPLS well. And even those guys I wonder about sometimes. :)

On Sun, Oct 23, 2011 at 12:24:05PM +0300, Tarko Tikan wrote:

 Same way MX is not ment to be used as LSR, yet everyone does that.

That's because we're not stupid (well, some of us aren't at any rate), 
and we know the difference between what the box is promoted for in 
marketing vs what it can actually do. :)

Foundry on the other hand doesn't appear to have any serious MPLS 
users at all (beyond relatively simple pseudowire/vpls, nothing I would 
classify as serious at any rate).

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] TCAM full on EX8200?

2011-10-22 Thread Richard A Steenbergen

On Sat, Oct 22, 2011 at 08:19:33PM +0400, Pavel Lunin wrote:
 
 As far as I understand, it's not really correct to compare difficulty 
 of these two operations, since they are performed by two different 
 units inside the chip. While label lookup instead of full IP table can 
 dramatically simplify the lookup unit's life, the unit, which inspects 
 packets and extracts bits from them, must be still quite complex even 
 for label-only router. Hashing ALU's life is not a peace of cake 
 either. Say, EX series PFE use only 6-bit seeds to construct hash on 
 them. In case you want to push a whole 20-bit label to the hash seed, 
 I'm afraid, you'll need more bits in ALU registers, more cycles or 
 something else.

Well, nobody said it was EASY, just EASIER. :)

The point is, just by going from full tables to not-full-tables you can 
start taking advantage of existing commodity chips which CAN do IP and 
some pretty deep hashing already, and move from thousands of dollars per 
10GE and 80-120G/slot (MX/ASR-style) down into hundreds of dollars per 
10GE and 480-640G/slot.

Personally my take is that PTX missed the mark as far as interesting 
target customer size goes. There are still a *LOT* of places where you 
could very easily replace a $1mil core T/CRS box at $retardecarrier with 
a $10-20k 1-2U box that does 64x10GE, or 40GE, etc. But obviously 
Juniper doesn't want to canibalize from their own T (or at worst MX) 
market, which is why only made the PTX product that they did (pick 
between massive or super-$%^ing massive, and at only ~MX-style port 
prices).

Eventually someone will come along and realize that there is an untapped 
market here, and then the promise of cheap label switching routers will 
be fulfilled. IMHO the reasons this hasn't happened yet are a) only 
Cisco/Juniper *REALLY* have a good handle on the software side of MPLS, 
and b) not enough non-carriers are currently running (or even currently 
able to conceptualize running) label-only cores. Of course the large 
carriers with the most to gain also tend to be the least innovative and 
the most unwilling to consider cost when designing their architecture, 
until they go bankrupt of course. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] TCAM full on EX8200?

2011-10-15 Thread Richard A Steenbergen

On Sat, Oct 15, 2011 at 11:04:37AM +0100, Phil Mayers wrote:
 
 ...whereas because ACLs are variable length, determined by customers 
 and possibly large, performance of a RAM-based ACL algorithm is hard 
 to predict, and people want predictable performance, and usually 
 line-rate performance.

Just wait until you figure out that it's possible to get significantly 
less than line-rate performance out of an I-chip with just a dozen 
relatively simple firewall terms. :(

 Hehe. Tag switching will make core routers really cheap, you'll have 
 a few really big PE routers only. Wasn't that the line we were sold 
 with TDP?

And they totally could be too, if anyone bothered to actually make them. 
You don't even need to spin custom ASICs (one could argue that their 
might not be enough business to justify it anyways), label switching is 
so easy from a hardware perspective that it's not even funny. Everyone 
and their mother is busy churning out Broadcom Trident+ based 64x10G 1U 
boxes right now (see: Juniper QFX, etc), and at a price of a couple 
hundred bucks a 10G even on the high end. Why aren't these boxes making 
great LSRs?

The problem is, the software side of MPLS (i.e. all of the associated 
protocols surrounding it) is so complicated, only Cisco and Juniper have 
figured out how to actually implement it correctly (and that is only 
because they wrote most of it :P). All the hardware in the world doesn't 
help you if you don't have the right software, and C/J shockingly don't 
want to make a $10k box that obsoletes the need for a $1mil T-series. 
This is why OpenFlow has them all running scared. :)

The PTX is the first thing to actually attempt to be a label switching 
router only, but even that one is a) still vaporware, and b) designed to 
be sold to only a handful of super large carriers, and still at fairly 
premium prices. All they're trying to do is keep the T-series business 
unit from losing money to the MX-series business unit (since the MX is 
just as capable of doing everything T does w/MPLS as a core router, but 
at 1/4 the price), they aren't ACTUALLY trying to make a cheaper LSR. :)

If more people used MPLS, and if some competetive vendor could figure 
out how to write all the protocols for it to run on a small/cheap box, 
the core router market could get REALLY interesting.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] TCAM full on EX8200?

2011-10-15 Thread Richard A Steenbergen

On Sat, Oct 15, 2011 at 02:56:01PM -0400, Jeff Wheeler wrote:
 
 Most customers find that their Juniper boxes still operate at wire 
 rate even when they load up some ugly filters.  On some boxes in some 
 cases, however, that is not true.  But to generalize, M/MX does 
 everything with RAM, provides the operator with more flexibility, but 
 also gives him a little more rope with which to hang himself.

It turns out that on I-chip, a dozen or so relatively simple filter 
terms are enough to exceed maximum number of accesses that give you line 
rate performance. It's especially bad if you try to use filter chains, 
since there is no next filter command, and the next term command 
(which is REQUIRED in every term in order to keep processing things 
further into the chain) is relatively expensive (4 lookups each, and you 
only get ~28 for line rate performance).

Having flowspec routes is another good way to make it angry, since they 
get evaluated on every ingress interface. Even worse, when you DO exceed 
your lookup capacity, the only symptom will be silent packet drops, with 
nothing logged on any interface counter outside of show ichip commands 
in the pfe shell.

We had to kill our filter chains and use commit script built non-chain 
filters to implement chain-like logic (i.e. re-use of common filter 
config components), it was the only way to do it without killing the 
box.


 I doubt Juniper has ignored the possibility of grafting some CAM onto 
 their router boxes for certain operations, but when you already have 
 the ALU+RAM method RD'd and you can simply scale it up a little bit, 
 this is probably more sensible than adding a power-hungry CAM and all 
 the guts necessary to interface to it, and then do more RD to have 
 the control-plane figure out how to take advantage of it, and *then* 
 still live with the fact that Juniper firewall filters *still* give 
 you the flexibility to make that operation not perform at wire rate 
 also.

They actually did put TCAM onto the modular MPCs (i.e. MPC1 and MPC2, 
but not the 16x10GE MPC, and also I'd like to take this opportunity to 
offer an extreme DIAF to whoever butchered the use of the word 
modular on these products!) for exactly this reason. But I've been 
told there are no immediate plans to actually add any support for it in 
software, if ever. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] TCAM full on EX8200?

2011-10-15 Thread Richard A Steenbergen

On Sun, Oct 16, 2011 at 12:56:41PM +1100, Julien Goodwin wrote:

What's needed is for an OEM to build a generic router chassis that has
separate control plane, power, and forwarding modules that can be
swapped as needed. Potentially ATCA might be a good platform for this

This is already being worked on through something called OpenFlow, which
aims to provide an open API to programming the hardware so that anyone
can come along and write their own software for it. The chip makers are
already able to produce massively high performance hardware for cheap,
but none of them can figure out how to write the software for it to save
their lives. This is why vendors are so scared of OpenFlow, if someone
else can come along and write a good OS/BGP/etc for someone else's
hardware they're in for a world of hurt.

At this point vendors like Cisco and Juniper aren't actually hardware
companies, they're software companies. In many ways their hardware is
inferior to the absurdly cheap and high performance chips being produced
by folks like Broadcom (with the caveat that many times those chips have
design flaws caused by lack of practical experience, see: nearly
everyting wrong with the EX, for example :P), but the software is what
keeps people buying the hardware.

Of course the traditional router vendors are also realizing that they
won't be able to compete on price given the massive volumes that third
party ASIC makers are doing, so they've already started building systems
around those chips. The Cisco ASR is EZChip, the Juniper EX is Marvell,
the Juniper QFX and a dozen other similar products are Broadcom, etc.
But ultimately, it still comes down to software. The exact same Broadcom
reference design box can be sold by Dell for $1k or by Force10 for $15k,
and the difference is the software. :)

There are other potential solutions, for example:
http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk17.swhyte_Opensource_LSR_Presentation.pdf

Yup, this is an example of software using OpenFlow.

I do object to the still vaporware, not due to ship until the end of
the year is closer. The main threat to the T-series is that 10ge
slowly removing the need for Sonet/SDH, and if all you need is 10g
LAN-PHY the MX with the 16-port MIC does it nicely.

It's been talked about for a while, but I'll believe it when I actually
see it. :) PTX is also priced very similarly to MX hardware, so while it
may indeed be cheaper than T, that doesn't really mean much (except
for which Juniper business unit gets the revenue :P). It's not anything
revolutionary, that one is still waiting to happen.

--
Richard A Steenbergen r...@e-gerbil.net http://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

Re: [j-nsp] TCAM full on EX8200?

2011-10-13 Thread Richard A Steenbergen

On Thu, Oct 13, 2011 at 02:19:40PM +0200, Michele Bergonzoni wrote:
 Il 13/10/2011 13.31, Chen Jiang ha scritto:
  AFAIK, The EX8200 use SRAM for FIB and TCAM for ACL, that's not like
  EX2200/3200/4200 that use TCAM for all FIB and ACL.
 
  You could vty to line card and try this knob and see what happened:
  PFEM2(vty)# show shim route lpm-dmm-stats
 
 Not sure to understand how something can switch data at that speed using 
 SRAM as a FIB, but it's consistent with my TCAM appearing almost empty.
 
 Anyway, here's the output:
 
 
 PFEM2(vty)# show shim route lpm-dmm-stats
 
 IPV4
 -
 
 ShadowIdx: 0Partition: 0
 
 numOfUsedBlocks  : 2077numOfAllocatedBytes  : 48216
 numOfFreeBytes   : 2046640 numOfPickAllocatedBytes  : 48380
 numOfPickAllBlocks   : 2370
 
 ShadowIdx: 0Partition: 1
 
 numOfUsedBlocks  : 320 numOfAllocatedBytes  : 667884
 numOfFreeBytes   : 1427132 numOfPickAllocatedBytes  : 672216
 numOfPickAllBlocks   : 448
 
 ShadowIdx: 0Partition: 2
 
 numOfUsedBlocks  : 17569   numOfAllocatedBytes  : 
 2083064
 numOfFreeBytes   : 11952   numOfPickAllocatedBytes  : 
 2083816
 numOfPickAllBlocks   : 22343


EX8200 uses SRAM for forwarding lookups, and TCAM for firewall 
filtering. SRAM is perfectly capable of doing lookups at these speeds, 
and infact is a lot more flexible than TCAM, whereas TCAM is actually 
much better suited for doing high speed packet filtering.

At any rate, your problem is in partion 2. See how you have 2MB 
allocated and only 11k free, while in partition 0 it is almost 
completely unused, and in partition 1 only 667k out of 2MB is used? One 
of your SRAM partitions is full, and thus you can't add more routes to 
the FIB.

Determining exactly how this happened, and how far you need to plant 
your foot up Juniper's ass to get it fixed, is best left as an excercise 
for the reader. All I will say is that they are now selling -ES 
(enhanced scale) linecards for EX8200 which have more SRAM capacity.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] download.juniper.net mime types

2011-09-13 Thread Richard A Steenbergen

On Tue, Aug 30, 2011 at 01:52:45PM -0500, Richard A Steenbergen wrote:
 Dear Juniper,
 
 You guys broke your mime types again, at least for all the 10.4S6.6 
 service release URLs. :)

Sigh... I know nobody wants to bother trying to be standards compliant 
or testing things on any platform other than IE these days, but I really 
can't believe nobody cares about not serving up your .tgz junos 
downloads with Content-Type: plain/html... Does nobody else notice that 
it's now an epic pain in the ass to download code with something like 
lynx?

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Securing management access to Juniper gear

2011-09-03 Thread Richard A Steenbergen

On Fri, Sep 02, 2011 at 02:37:11PM -0400, Mark Kamichoff wrote:
 
 I'm not an EX guru, but I believe the same concepts can be applied.

With the caveats that:

1) lo0 filters *WILL* (quite incorrectly) match data plane exception 
packets that get punted to the RE for further processing as well, such 
as TTL expiring traceroute packets routing THROUGH the box. Mostly this 
issue applies to EX, which seems to punt a whole bunch of everything to 
the RE rather than deal with it on the FPC CPU like traditional Juniper 
hardware, but the same thing actually still happens with TTL expiring 
packets being popped out of an LSP on MX Trio hardware too. You need to 
make exceptions for this in your lo0 filter, or else you'll find your 
control plane filters matching more than just control plane packets, 
breaking traceroute/etc, and generally pissing everyone off. I believe 
there was also a related ongoing issue on EX where an lo0 filter with an 
explicit deny of all traffic at the end would actually match ARP traffic 
too, so you should probably be careful with those as well. :)

2) EX lo0 filters don't actually work correctly for DoS prevention, they 
get applied *AFTER* the packets have already destroyed the RE, and thus 
are completely ineffective at defending the boxes from attack. The only 
way to correctly block control plane traffic on EX is with ingress 
filters on real intefaces (or RVIs).

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826

2011-09-01 Thread Richard A Steenbergen

On Wed, Aug 31, 2011 at 08:59:26PM +0800, Mark Tinka wrote:
 10.4R4.5 today on our EX3200's/4200's.

We were forced (kicking and screaming) into 11.1S2 on our EX8200s for 
some feature support that just wasn't available any other way, but all 
things considered the code has actually been pretty darn good (as far as 
EX code goes). Put it this way, I was expecting a LOT worse. Yes you can 
still royally screw up the fib if you insert cards while it's 
converging, or make it take an hour to update the fib by looking at it 
funny, but things have actually been relatively stable and light on the 
other major issues (crashing, blackholing, etc). Chalk one up to the 
new development process I guess, though personally I'm still pretty darn 
annoyed at the whole hour to update the fib thing. :)

  SRX, you might as well run whatever came on it,
  because it won't work anyway.  The ALGs don't work, at
  times proxy arp doesn't work, your logs will be full of
  interesting (and scary) error messages, bugs that were
  supposed to have been fixed aren't, licensed features
  (like dynamic-vpn) don't work at ALL, etc.
 
 None here, but the constant pain about them on the list is 
 glaring.

I have an SRX210 in my basement doing my home routing, and it is the 
only free device I've ever been given that I would seriously consider 
returning and asking for my money back. Broken doesn't even begin to 
describe it, my condolences to anyone who actually needs to run these 
things in production.

  M/T series probably have the most flexibility as 
 they
  have been around long enough not to push people towards
  10.4/11.[12] -- people can just select the appropriate
  SR.
 
 Agree - we have far fewer issues with these as they're older 
 and most of the new junk going into Junos today isn't to do 
 with them save for a couple of features (which are sometimes 
 hardware dependent) and general bug fixes.
 
 We've hit some silly bugs on the M-/T-series lately, but 
 nothing near as bad as the MX.

We've been running 10.4 on MX ever since R4, with a healthy mix of 
I-chip and Trio boxes (not combined though), and the code has actually 
been pretty solid. Yes there are some outstanding issues somewhere 
between annoying and obnoxious but you can work around it that still 
aren't fixed until R7, but in the grand scheme of things it all mostly 
works. Then again, after the debacle that was 10.2 I'm excited when the 
things don't randomly shoot flaming packets out of their ass, so maybe 
it's just a case of lowered expectations. :)

 Can't blame you. If you're new to Juniper, just coming from 
 Cisco, feelings might be familiar. If you started with 
 Juniper back in the days of Junos 5, 6, 7 and 8.4, as they 
 say, Those were the days.

About as good as Cisco is where I'd put things today on the code 
reliability scale. Not to say that I'm happy with that state of 
affairs, but as Homer would say, urge to kill... fading :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826

2011-09-01 Thread Richard A Steenbergen

On Thu, Sep 01, 2011 at 11:48:36AM -0400, Paul Stewart wrote:
 Actually I'm curious as well - RAS is not typically wrong though about 
 this kind of stuff ;)
 
 We have numerous SRX deployed for firewall and router functionality - 
 some are running Dynamic VPN (which yes, we've had issues with - 
 definitely it's not perfect).  We've been bitten by some surprises as 
 well ... so I'm not disagreeing, just saying that we're pretty used to 
 these issues we've encountered and don't deploy if we know they will 
 come up. Typically, we use them as site to site VPN boxes along with 
 firewalling.
 
 I have an SRX210 at my home as well - run the full UTM suite on it and 
 had no real issues (granted it's a home environment to be fair).
 
 RAS, can you share a few highlights of broken?

Just doing simple routing and IPSec tunnels, and we're talking every 
random little thing you can possibly imagine, across about a dozen 
different versions of code and a lot of time hoping it would get better. 
I still have to reboot the thing once every few weeks just to keep the 
packets forwarding.

The most insane thing I saw was when trying to use BGP to originate a 
/24 over my IPSec tunnels, you couldn't keep the sessions up for more 
than ~24 hours without restarting rpd. I've had to disable just about 
every feature to keep things even mostly working, for example the last 
time I tried to configure IPv6 on a gre tunnel it would sometimes 
randomly not configure ANY IPs on the interface when it would boot. You 
could show int terse gr-#/#/# and they just wouldn't be there, no 
matter what the config was, etc. I'd have more reliable internet at home 
if I had a Linksys. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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] download.juniper.net mime types

2011-08-30 Thread Richard A Steenbergen

Dear Juniper,

You guys broke your mime types again, at least for all the 10.4S6.6 
service release URLs. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826

2011-08-30 Thread Richard A Steenbergen

On Wed, Aug 31, 2011 at 07:42:21AM +1000, Dale Shaw wrote:
 Hi all,
 
 So, --sigh--, it looks like there are still severe bugs being
 discovered in JUNOS 10.4:
 
 http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2011-08-348actionBtn=Search
 
 Does anyone know more about PR/676826 and what the various
 conditions that trigger it might be? Anyone know when the defect was
 introduced?
 
 I've opened a JTAC case in an attempt to find out more because we've
 just embarked on an upgrade to 10.4R6; if the bug can/will bite us I
 need to decide whether to stick with 10.4R6, go to 10.4S6, or wait for
 10.4R7.

We hit this bug on several MX devices running junos 64 at the 49 day 
mark. 10.4R7 isn't due until October, so if you're running the new REs 
you probably want to go with S6.6 for the fix.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] CWDM SFP+ 10gigE

2011-08-30 Thread Richard A Steenbergen

On Tue, Aug 30, 2011 at 06:31:04PM -0400, Chuck Anderson wrote:
 Has anyone tried third-party CWDM SFP+ 10gigE transceivers in MX Trio
 or EX4500?  A quick Google search turns up many vendors I haven't
 heard of:

We're running many of the 40km DWDM SFP+ in EX8200 quite successfully, 
can't speak to the other platforms.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Juniper MX SCBE-MX-R

2011-08-11 Thread Richard A Steenbergen

On Thu, Aug 11, 2011 at 07:33:20AM -0400, Chuck Anderson wrote:
 
 I'd rather they slip and put out well tested, stable code than to just
 release what they have on a specific time schedule.

Don't worry, they can still find a way to fail at both.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Any takers on 10.4R5.5 yet ?

2011-06-27 Thread Richard A Steenbergen

On Mon, Jun 27, 2011 at 11:05:48AM -0600, David Ball wrote:
   I know it's unreasonable to have people continually posting to the
 list asking about which code is best, but I know many were waiting for
 a stable 10.4 revision (due in part to its' EEOL nature) but last I
 heard, 10.4R2 (or was it R3) wasn't ready for primetime.  Didn't find
 much in the archives about 10.4R4.

10.4R4 has been the least problematic code on MX (either trio or ichip, 
but not mixed) that we've seen in a very long time, probably at least 
1.5 years. There were a handful of mostly minor issues in it, but in 
theory they've been fixed in 10.4R5 (though we have only a couple of 
routers running R5 so far, so we don't have a massive experience base 
yet). As always it varies by your feature set, but for a v4/v6/mpls/bgp 
heavy core router things are finally starting to look up. About damn 
time too. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Understanding versioning of service and regular releases

2011-06-03 Thread Richard A Steenbergen

On Fri, Jun 03, 2011 at 11:58:00AM +0200, Tore Anderson wrote:
 On 2011-05-27, JUNOS 11.1S2 was released for the EX. So this release is
 a couple of weeks newer than JUNOS 11.1R2.3. However,
 https://www.juniper.net/customers/csc/software/junos_software_versions.jsp
 says 11.1R2.3 is the recommended version for the EX 4500 in VC
 configurations.

Let me throw out some warnings about 11.1S2 for EX real quick.

First off, when you upgrade a backup RE (we saw this on EX8200 but it 
might apply to VC's too) and are running some older code on the master 
(we saw this on several dfiff versions of 10.1, 10.2, and 10.3), there 
is a ~15% chance that when the backup RE comes online is will cause the 
router to completely stop forwarding traffic. This isn't a case of the 
backup stealing control of the pfe, and it doesn't leave anything in the 
logs, it just silently disrupts the master RE so it can't reach 
anything, and stays that way until you restart the router or switch over 
to the 11.1 RE. We've seen this happen several times now on several 
different routers, no GRES or anything like that, and there is no PR 
yet.

Also, they've done something to royally hose the sync process between 
master and backup RE on this code. When running 11.1S2 on the backup, 
and any of a dozen different versions of 10.1, 10.2, or 10.3 (haven't 
tested 10.4, doesn't seem to happen when both REs are running 11.1S2), a 
commit sync will always fail. This wouldn't be so bad, except that on EX 
(at least on EX8200) you CAN'T disable commit sync, even if you don't 
specify it it always does it. This means that you will never be able to 
commit with the backup RE online, and the only workaround seems to be to 
reboot the backup RE before you commit on the master so that it sees it 
offline and successfully ignores it. Again no PR on this yet.

No experience with it on 3200/4200/4500/VCs yet, but based on our 
experience w/EX8200 so far this code should come with a warning label, 
may be hazardous to your health. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX80 Opinions

2011-06-03 Thread Richard A Steenbergen

On Fri, Jun 03, 2011 at 08:31:51AM -0700, Serge Vautour wrote:
 Hello,
 
 Would it be possible for you to share what code version you recommend 
 for Trio? We've had a few MX80s in Prod with 10.2S6 for a while now. 
 We need to add MPC cards to our MX960s and are struggling what version 
 to go with. Continue with 10.2 or move to 10.4? We're also planning on 
 adding alot more MX80s.

As of right now we're doing 10.4R4 on new deployments/upgrades of MX80 
and MPC, and it's working reasonably well. It's not perfect of course, 
we have a few fixes already in the queue for 10.4R5 and just found a new 
rpd coredump the other day, but it's a hell of a lot better than any 
previous 10.4 builds, and now seems to be the right time to pick up the 
EEoL release. 

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX80 Opinions

2011-06-03 Thread Richard A Steenbergen

On Sat, Jun 04, 2011 at 12:04:09AM +0800, Mark Tinka wrote:
 
 One thing to think seriously about is whether you're going to run your 
 MX's with a mixture of DPC's and MPC's. Depending on which features 
 you need to turn on, you may not be able to boot DPC cards if you have 
 MPC's installed as well.
 
 I'd seriously suggest checking with your SE before turning up any 
 features if you're going to mix DPC's and MPC's, or if certain 
 features for the MPC's seem kinky. We've had too much pain for some 
 items.

Agreed 100%, plus getting line-rate out of a mixed DPC/MPC environment 
is a real bitch for a number of reasons, so you'll be MUCH better off if 
you convert a whole chassis at a time. Though I will say that 10.4R4 
didn't give us ANY grief when doing mixed DPC/MPC during the actual 
conversion maintenance, which is a first for the dozen or so places 
where we've done this already. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] SSH/Telnet session hanging

On Thu, Jun 02, 2011 at 05:44:38AM -0700, Serge Vautour wrote:
 Hello,
 
 I'm confused by your statement that BGP is limited to 4096. I have BGP 
 peers up with 8192:

From RFC4271:

4.  Message Formats

   This section describes message formats used by BGP.

   BGP messages are sent over TCP connections.  A message is processed
   only after it is entirely received.  The maximum message size is 4096
   octets.  All implementations are required to support this maximum
   message size.  The smallest message that may be sent consists of a
   BGP header without a data portion (19 octets).

I suppose JUNOS lets it use an MSS of Nx4096 that will fit in the PMTU. 
Then again, there was a long standing bug that shows 2x whatever the 
actual MSS was on show system connections output too, so who knows. :) 
But under protocols bgp neighbor x.x.x.x tcp-mss the maximum value you 
can specify if you aren't doing automatic PMTUD is 4096, go figure.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX80 Opinions

On Thu, Jun 02, 2011 at 04:26:54PM -0700, Doug Hanks wrote:
 Daniel,
 
 I have nothing but good things to say about the MX80.

I have almost nothing but good things to say, now that 90-95% of the 
cripling Trio-specific bugs have been worked out of the current code.

The integrated RE is probably the biggest design limitation. For 
example, we just got bit by a bad flash drive on one, which caused the 
kernel to lock up when writing to the disk. This required a physical 
power cycle to bring the box back every time it happened, left no 
evidence in the logs (so we had to catch it actually happening on 
console to know what was going on), and required a complete RMA of the 
chassis to fix. The lack of redundant REs severely limits the potential 
of this otherwise excellent little box. Oh and don't forget, a single RE 
will make your upgrade process take a lot longer too.

Juniper would really do well to introduce a 1U small/simple external RE 
which can be connected over Ethernet, to redundantize a box like the 
MX80, and to be a reasonably sized BGP route reflector.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX80 Opinions

On Fri, Jun 03, 2011 at 11:47:30AM +1000, Julien Goodwin wrote:
 
 There was talk of a VC-like implementation for the MX80, although I 
 don't know if that went anywhere.
 
 Now that they have the XRE200 what about letting us install Junos64 on 
 it and making it a reflector platform.

We actually tested the XRE200 for RR use (since it's a hell of a lot 
more sane than a JCS), but they specifically lock it down so you can't 
run BGP on it directly. This is the only JUNOS platform which is SMP 
enabled right now, and from what I've heard the regular kernel krt isn't 
thread safe, so my theory is to make it do SMP they may have had to 
disable some of the normal routing operations and only make it capable 
of controlling other EX chassis. I'm sure it would make a fine, if very 
overpriced, Olive though. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX80 Opinions

On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote:
 Although expensive, you can buy the JCS1200 with 64-bit Junos to run 
 as a standalone RR.  It's probably more economical if you could also 
 benefit from VPNv4 RRs for MPLS VPN deployments.

Price aside, anyone who wants a 12U RE needs to have their head 
examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, 
slap a Juniper logo on the front, mark it up 20x like everything else, 
and sell it to us as a fully supported RR? I'm still confused how this 
has managed to escape their attention.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX80 Opinions

On Thu, Jun 02, 2011 at 07:11:31PM -0700, Doug Hanks wrote:
 The new MX REs run 64-bit Junos.

64-bit JUNOS != SMP enabled. The only difference is the amount of ram it 
can address, those fancy quad-core CPUs only run on a single core. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] JUNOS major releases - differences between revisions

2011-05-20 Thread Richard A Steenbergen

On Fri, May 20, 2011 at 10:38:22AM -0700, Jim Boyle wrote:
 You can also take a look at the results from our online PRSearch application.
 
 http://www.juniper.net/prsearch/
 
 Select 10.4R3, or 10.4R4 and show the results Closed in that 
 release.  That will show available PRs with commits/resolution in that 
 release (Closed isn't quite accurate here as the PR may be open for 
 other releases or follow-on actions)
 
 Thanks to Alex for the pointers on the release notes.  In general, the 
 release notes show what is fixed in that release (under Resolved 
 Issues for each section).  So if you check the PRs in the 10.4R4 ones, 
 and cross check them on the web, you should find they are resolved in 
 10.4R4.
 
 I'll admit that finding the this information isn't as easy as it 
 should be.  Juniper certainly has room for improvement here for 
 usability as well as consistency of information.  We are working 
 towards improvements in this area.

Alas we find that something like 75% of our PRs end up being marked 
confidential until we ask for them to be changed (sometimes multiple 
times :P), even when there is no reason for them to be, which tends to 
make the PR search all but useless for any real work. And I won't even 
start complaining about the accuracy of the PR public facing 
descriptions, that would be a whole 'nother thread. :) Sorry but the 
only way to get any real work done is to have an RE or SE be your bitch 
and look up the PRs to tell you what they're REALLY about, hoping for 
anything else is a complete fantasy.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] EX switches and TCAM utilisation

2011-05-18 Thread Richard A Steenbergen

On Wed, May 18, 2011 at 05:10:54PM +0100, William J Hulley wrote:
 Hi,
 
 I'm using some EX3200s running 10.0S6.1 and developing a configuration 
 using filter based forwarding to policy route traffic between routing 
 instances.
 
 It's all working fine in the lab but I'm concerned about the potential 
 growth of the firewall policy and utilisation of the TCAM in 
 production and would obviously like to model the usage and monitor it.
 
 Are there any known supported/un-supported ways of getting useful 
 stats out of the box beyond just relying on syslog messages saying 
 there isn't enough cam?

Drop into the fpc shell from root, like so:

RE:0% vty fpc0

BSD platform (MPC 8544 processor, 48MB memory, 0KB flash)

PFEM0(vty)# 


Next you need to find the vendor ID for the platform, like so:

PFEM0(vty)# show tcam vendor
Vendor = internal_ch3_tcam Vendor_id = 1

For EX8200 it's vendor id 6, for EX3200 it seems to be vendor id 1.

Then you need to find the instance ID for the hardware you're looking 
for. On EX8200 I know instance 2 is used for GE cards, instance 4 is 
used for XE cards. On EX3200 there only seems to be instance 2 (as 
you'd expect):

PFEM0(vty)# show tcam vendor 1 instances

 Vendor InstancePage Size

 internal_ch3_tcam 2 4 


So then to view the usage info for this vendor/instance:

PFEM0(vty)# show tcam vendor 1 instance 2 rules
Number of rules as Ingress PACL: 0
Number of rules as Ingress VACL: 0
Number of rules as Ingress RACL: 528
Number of rules as   Egress PCL: 135

528 Ingress RACL rules

HW-indexPage_idEntry_idrule_size fw_idRule

6296   1574   0227
AUTOFW-INVALID-PROTOCOLS.ext.0
6298   1574   2227
AUTOFW-INVALID-PROTOCOLS.ext.1
6496   1624   0227
AUTOFW-BORDER-FILTERED-PROTOCOLS.ext.0
6498   1624   2227
AUTOFW-BORDER-FILTERED-PROTOCOLS.ext.1
6708   1677   0227
AUTOFW-BORDER-LIMIT-IP-OPTIONS.ext.0
6710   1677   2227
AUTOFW-BORDER-LIMIT-IP-OPTIONS.ext.1
6960   1740   0227
AUTOFW-LIMIT-ICMP-ECHO.ext.0
...

TCAM utilization: 1326(used), 12938(free), 14264(total)

And there is your total tcam utilization above. Depending on code and 
platform it may show you a slightly different view, for example here is 
the utilization on an EX8200 running older 10.1 code:

PFEM15(vty)# show tcam vendor 6 instance 4 rules
Instance 4
  DB 0  Ingr PACL:0/ 996 (current/max) rules. Util. 0.000%
  DB 1  Ingr VACL:0/   12288 (current/max) rules. Util. 0.000%
  DB 2  Ingr RACL:  410/   32768 (current/max) rules. Util. 1.251%
  DB 3   Egr PACL:0/1024 (current/max) rules. Util. 0.000%
  DB 4   Egr PCL1:  103/8188 (current/max) rules. Util. 1.258%

But you get the gist. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] SFP Status and Conditions

2011-05-11 Thread Richard A Steenbergen

On Wed, May 11, 2011 at 03:39:39PM -0300, Giuliano Medalha wrote:
 People,
 
 Is it any possible to monitor the SPF status of an EX switch ?
 
 Is there some commands to see SFP or XFP or SFP+ status ?
 
 - power
 - model
 - temperature
 
 Some SFP supports DD for verification.  Juniper supports it ?

show interfaces diagnostics optics

You may also be interested in http://juniper.cluepon.net/OS_dom, which 
adds a sorely needed summary view for DOM.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] EX Series | 10.4R3.4 Limited Received Routes

2011-05-01 Thread Richard A Steenbergen

On Sat, Apr 30, 2011 at 08:48:59AM -0700, Bill Blackford wrote:
 So if what you are saying is that the EX, only being capable of 16k 
 routes, will only Receive and Accept a random smattering of a full 
 table being sent up to 16k and any filters beyond that filter on the 
 16k Received and installs that balance as Active?
 
 If this assumption is correct, then what I'm seeing is expected 
 behavior?

The 16k limit is a RIB limit from the default hard-coded configuration 
on small-EX's. This doesn't really protect the FIB, as the FIB is much 
smaller still, more along the lines of 12k total unicast entries for 
IPv4 (and much less if you actually install IPv6 routes) on 
EX3200/4200..

You can see the RIB limit at /etc/config/ex-series-defaults.conf:

routing-options {
rib inet.0 {
maximum-prefixes 16384;
}
rib inet6.0 {
maximum-prefixes 4096;
}

All you have to do to override this is apply those options with 
increased values to your own configuration. Of course if you do, you'll 
immediately hit the next limit, a hard-coded maximum data size of 128MB 
which will cause rpd to coredump when it allocates that much memory. To 
change this, you have to edit /boot/loader.conf and increase the 
kern.maxdsiz line to something a little more sensible (like say 512MB). 
Unfortunately this value will be blown away every time you do a new 
jinstall, so you'll need to keep it up to date every time you upgrade.

To not flood your FIB, you'll need to block a bunch of routes at the 
RIB-FIB export layer, which happens in a policy you apply at 
routing-options forwarding-table export XX. For example, you might 
want to allow a default, static, isis|ospf, and some internal cust 
routes, but otherwise block the rest of the BGP routes to keep the table 
size small.

None of this has anything to do with an arbitrary liit of 28k active 
routes. If you were bumping up against the maximum-prefixes config, the 
number would be 16k total for the RIB, not 28k. When this limit gets 
hit the future routes are just silently dropped from the RIB, which is 
certainly a lot better than the Cisco method of disabling CEF and making 
the box unusuable until someone goes to reboot it. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] ex4200 egress filter

2011-04-28 Thread Richard A Steenbergen

On Thu, Apr 28, 2011 at 12:22:43PM +0100, Nick Ryce wrote:
 Hi Chris,
 
 The issue should be resolved next week in a service release against 
 11.1R1

We hit this issue while testing 11.1R1, and oh what a mighty big screwup 
it was on Juniper's part too (that it even tries to parse the packets 
that are killing it in the first place, when NOT CONFIGURED TO DO SO, 
simply boggles the mind). Unfortunately it's also not the only packet 
of death which crashes the FPCs issue in 11.1 on EX, we also discovered 
another one which DIDN'T get fixed in 11.1S1, so you're taking your life 
into your own hands if you try to run that code in production. Oh and 
BTW, 11.1 on EX will also blackhole your packets while BGP converges 
following bootup, for up to 15 minutes in our testing. Consider 
yourselves warned. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] ex4200 egress filter

2011-04-28 Thread Richard A Steenbergen

On Thu, Apr 28, 2011 at 05:17:46PM +0200, Tore Anderson wrote:
 * Richard A Steenbergen
 
  We hit this issue while testing 11.1R1, and oh what a mighty big screwup 
  it was on Juniper's part too (that it even tries to parse the packets 
  that are killing it in the first place, when NOT CONFIGURED TO DO SO, 
  simply boggles the mind). Unfortunately it's also not the only packet 
  of death which crashes the FPCs issue in 11.1 on EX, we also discovered 
  another one which DIDN'T get fixed in 11.1S1, so you're taking your life 
  into your own hands if you try to run that code in production.
 
 Hi Richard,
 
 Could you be a bit more specific about this issue that remains
 outstanding in 11.1S1? Is there a PSN for it?
 
 I have a pair of EX4500s in my lab for setup currently, and any older
 release isn't an option due to the lack of IPv6 and VC support.

No comment on how to reproduce it, at least until they fix it and ok the 
release of details. No PSN yet, but basically it's just another magic 
packet of death which crashes the FPCs, similar to the last NetBIOS 
issue. Almost all of our testing is on EX8200, but often times these 
things behave similarly across the smaller EX's too. I'm just warning 
people not to jump into 11.1S1 expecting everything to work great, 
because it most certainly does not. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] output-list for ex4200

2011-04-27 Thread Richard A Steenbergen

On Wed, Apr 27, 2011 at 12:24:25PM +0100, Nick Ryce wrote:
 
 Any ideas if this is supported in 10.4 as we have a standard ACL we 
 use on most customer vlans and then a customer specific vlan?

Nah, filter chains are definitely not supported on EX, and I'm not aware 
of any near term plans to add it.

Even on the major platforms, filter chains aren't exactly a completely 
well-thought-out solution. Doing the next term operation that you need 
to force packets to be evaluated all the way through the chain actually 
consumes lookup capacity inside the firewall processing, and it is 
surprisingly easy to exhaust this capacity. For example, something on 
the order of a dozen filter terms in a chain, doing relatively simple 
matching, is enough to exhaust the capacity of an I-Chip on an MX DPC. 
When this happens, you'll suddenly discover that your ports are no 
longer capable of doing line rate packets/sec, and there will be no 
indications of the drops short of poking around in the show ichip 
commands on the PFE. Needless to say, this can make for a really bad 
day.

We use a commit script to automatically build unique per-interface 
firewall filters out of individual filter config components. It's not 
pretty, but unfortunately this is really the only practical way to get 
the kind of config reuse you're looking for, not to mention the only way 
to actually protect the control plane on the EX. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX480 troubles.

2011-04-13 Thread Richard A Steenbergen

On Wed, Apr 13, 2011 at 01:27:15PM -0400, Chris Evans wrote:
 Question to you all...
 
 It seems like alot of folks run bleeding edge code with some if these 
 major bugs popping up.I also get the impression that a lot of shops 
 don't test code before they deploy.
 
 I'm just curious how this works for you. In my company we would get 
 seriously reprimanded for deploying software that is not tested and 
 any time we have outages we have to go through big hoops to understand 
 why how to fix etc.. so we do the best we can to deploy 
 architectures/platforms/code that wont have issues.
 
 I couldn't imagine being bleeding edge in a service provider 
 environment, its just a concept I can't fathom being in the 
 environment I'm in..

Nobody wants to run bleeding edge code, but newer code is required to 
support new hardware such as the MX Trio cards (which are much cheaper 
per port, higher density, and more featureful). Unfortunately a lot of 
the older newer code that had initial support for the new hardware 
(such as 10.2) is *REALLY* buggy, which makes the bug fixes in really 
new code a lot more attractive. We've tried to look at 10.4R3 (since it 
finally fixes ISSU for us for the first time in close to 2 years :P), 
but it's still just too buggy in the lab, so we're still doing 10.3R3 on 
new MX deployments/upgrades. Overall 10.3R3 has been relatively less 
bad than a lot of other recent code.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX480 troubles.

2011-04-13 Thread Richard A Steenbergen

On Wed, Apr 13, 2011 at 10:48:30AM -0700, Derick Winkworth wrote:
 
 They don't 
 
 1.? immediately just blame you or 
 2.? just tell you to upgrade and sit and do nothing until you do 
 3.? or tell you that you should have known that with some very narrow set of 
 unlikely circumstances after two or three weeks?some bug will occur.? 

I don't know what 7 leaf clover you picked to have that kind of luck, 
but all 3 of the above describe nearly every one of my (many, many) JTAC 
cases. I'd also throw in:

4. Repeatedly fail to read/comprehend anything you say in the ticket, 
sometimes for months (or even years) on end.

Just the other day I had an exchange with ATAC which went something like 
this:

Me Hi, when this bgp neighbor flaps it sometimes doesn't syslog the 
event correctly, and instead records garbage messages.

ATAC The bgp neighbor is flapping, that is why you are logging the 
neighbor down, can I close this case?

I couldn't make this stuff up if I tried. :) 

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX480 troubles.

2011-04-13 Thread Richard A Steenbergen

On Wed, Apr 13, 2011 at 10:09:12AM -0700, Keith wrote:
 
 We saw random reboots, sometimes hourly, with the first MPC
 and this was on 10.4R2.6. Juniper wanted to RMA it.
 
 When the latest MPC and MIC arrive I will update to 10.4R3.4
 and see how that goes.

Honestly, sometimes they get a little too RMA happy and throw that out 
as the solution instead of actually trying to find the real issue. 
Personally I'd be far more inclined to believe that the problem is 
software than it is two bad cards in a row, especially where 10.4R2 is 
involved. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] MX80-48T Fan Speed Variation

2011-04-05 Thread Richard A Steenbergen

On Tue, Apr 05, 2011 at 11:42:08PM +0200, Daniel Roesen wrote:
 
 JUNOS logging is a desaster. Either you get FAR too much noise (JUNOS
 developers love to leave a bouqet of debug messages in there,
 miscategorized as something else than debug), or you don't get relevant
 things anymore (like link/adjacency up events). Looks like extensive
 logging regexp is the only way to get proper logging. :-(

A mechanism to recategorize syslogging on an event basis using a policy 
(so you can fix these terrible defaults) is very VERY high on my feature 
request list. I forget the exact details, but the last I heard there was 
at least some interest in implementing this some time in the next year 
or so. If you agree that this is an important feature, please ask your 
account teams to make this a higher prority. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] Changing SSH port on EX switches, M routers

2011-04-01 Thread Richard A Steenbergen

On Fri, Apr 01, 2011 at 08:23:31PM -0400, Jesus Alvarez wrote:
 Hi,
 
 Is there a way to change the SSH port for managing the EX switches and M 
 routers? We normally avoid using the standard port 22.

No, I've been asking for this feature. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] XFP-10G-L-OC192-SR1

2011-03-24 Thread Richard A Steenbergen

On Thu, Mar 24, 2011 at 08:07:57AM -0400, Paul Stewart wrote:
 Hi folks.
 
 These are 10KM optics - how short of a run can you use them for?  We 
 have several of these spared at the moment and I'd like to use them 
 for connections between MX480's in the same rack. will they run too 
 hot?

http://www.nanog.org/meetings/nanog48/presentations/Sunday/RAS_opticalnet_N48.pdf

See page 79. LR and below has no blindness danger even back-to-back, ER 
has a blindness danger but not a damage danger, and ZR you can actually 
damage if you don't have enough attenuation before going into the 
receiver.

We don't even bother with shorter reach optics, after way too many 
issues encountered with SR and the like. It's easier (and cheaper if you 
have the right sources) to just buy all LR and standardize on SMF than 
it is to bother maintaining two inventories and mucking with orange 
cables even for intra-rack stuff.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] 10.0 or 10.4?

On Tue, Mar 22, 2011 at 05:18:47PM +0100, bas wrote:
 Hi All,
 
 Well, after this thread I still didn't know which version I should
 choose for our 960 with MPC's only.
 From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as
 the better choice, and people who talk to JTAC say 10.4r2 is the
 better choice.
 
 (Of course it depends on configuration and config.)
 
 But we chose to upgrade to 10.3r3, and installed the version this morning.
 The upgrade seemed to have gone smooth, but after all BGP sessions had
 been re-established, and prefixes re-learnt the CPU stayed at 100%.
 
 Dropping to shell I saw rpd consuming 99% CPU.
 Looking at task accounting and rtsockmon I saw no obvious causes.
 A failover to the backup RE had no effect, the new master RE consumed
 100% within a couple of minutes.
 
 A colleague of mine did a trace of the process saw that the cycles are
 being consumed by getrusage system calls.
 
 Tomorrow morning we'll try to restart routing, if that has no effect
 we will try 10.4r2.

Haven't seen that here. Both 10.3R3 and 10.4R2 picked up a very similar 
set of fixes (they have very close release dates) for major PRs which 
were giving us grief, but 10.3R3 seemed to introduce less new ones in 
the process. 10.4R3 just came out yesterday, so feel free to give it a 
shot and report back, but most of our 10.3R3 issues have been relatively 
less bad than normal.

Occasional logging of these junk messages:

Mar 22 11:47:12.629  re1.xx1.xxx1 /kernel: %KERN-3: Unlist request: unilist(nh 
index = 1049538) found on the rnhlist_deleted_root patnode, hence returning

Logging of these junk messages (note the incorrect timestamps too, these 
were actually logged AFTER the Mar 22 output above :P):

Mar  4 10:29:50.527  re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 
1:07.860442
Mar  4 10:47:22.577  re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 
1:22.570405
Mar  4 10:55:44.479  re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 
1:21.765648
Mar  4 10:59:59.056  re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 
1:19.371199
Mar  4 11:02:04.228  re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 
1:18.704278

Weird stuff like that. Probably the worst issue we've seen so far is 
that on MX w/MPC cards (not sure if its the sw or hw) doing an l2circuit 
to a vlan-ccc endpoint and then confusing vlan-maps to push/pop the vlan 
tag off of the packet before encapsulating in the pseudowire (so you can 
mismatch vlan IDs on the endpoints) seems to block ISIS packets from 
being transported (most likely blocking 802.3 LLC frames is my guess). 

On EX there is a definite problem with the power supplies getting stuck 
110v low power mode as far as the chassis is concerned, which is an 
issue if you need 220v power to fully and redundantly power your FPCs. 
But at least this code hasn't crashed or blown up massively yet (or 
failed to do some really important operation like say correctly counting 
packets in SNMP so you can bill your customers), which is definitely an 
improvement over a lot of other recent JUNOS code. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] 10.0 or 10.4?

On Tue, Mar 22, 2011 at 05:18:47PM +0100, bas wrote:
 From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as
 the better choice, and people who talk to JTAC say 10.4r2 is the
 better choice.

Oh and btw, I have multiple confirmed reports of YET ANOTHER major 
memory leak in mib2d in 10.4R2. Hope everyone learned their lesson about 
trusting JTAC version recommendations. :)

From 10.4R3 release notes:

The mib2d process leaks memory during SNMP walks. [PR/586074: This issue 
has been resolved.]

I'm going to assume it's that. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] about 10.4R3 on EX

On Tue, Mar 22, 2011 at 12:54:25PM -0700, Kaj Niemi wrote:
 Hi,
 
 sarcasm
 To whomever who decided to introduce new features in a R3 release, thanks
 ;-( Specifically installing jloader separately is highly appreciated.
 /sarcasm

Sadly, they've been silently introducing new features in the middle of a 
bug fix release (and introducing new bugs too, which is how I find out 
about them) for a while now. But for extra bonus points, be prepared for 
the upgrade to take a REALLY long time to complete too. :)

From the release notes:

How Long Will the Upgrade Process Take?

The process of upgrading to a resilient dual-root partitions release 
takes longer due to the additional step of upgrading the loader software 
and a longer reboot time while the disk is reformattedto four partitions 
during the reboot of the switch that completes the Junos OS upgrade. The 
reformat increases the reboot time for EX2200, EX3200, EX4200, and 
EX4500 switches by 5 to 10 minutes. For EX8200 switches, the reboot time 
increases by 10 to 25 minutes per Routing Engine, and additional reboots 
are required.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://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

Re: [j-nsp] about 10.4R3 on EX