[j-nsp] libcurl for SLAX missing HTTPS/SSL support?

[Jeff Wheeler]

I was hoping to call an API by HTTPS from a script.  To my surprise,
libcurl on vSRX 15.1X49-D60.7 on AWS doesn't support SSL, and neither
does fetch, etc.

This seems a little ridiculous, especially since the documentation
indicates HTTPS support and provides examples.
https://www.juniper.net/documentation/en_US/junos15.1/topics/reference/general/junos-script-automation-libslax-curl-extension-library.html

The KB is barren on this topic, too.  I saw that Saku Ytti got Juniper
to correct missing HTTPS for one use-case some years ago, and a 2013
thread with a similar complaint.  What gives?

-- 
Jeff S Wheeler 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Help with MSTP in EX8208

[Jeff Wheeler]

Octavio, notice that the Role of the ports is MSTR not ROOT.  Your two
EX8200s are not in the same MSTI Region.  Compare the
configuration-name, revision-level, and VLAN-to-Instance assignments
on the two switches; they are not the same.

For more on the different MSTP Port Roles and their meanings, see IEEE
802.1Q-2005 Section 12.12 Port Role assignments.  Vendor documentation
is mostly worse than the IEEE standard, and Juniper's is no exception.
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Junos 11.4R1.6 shipping on new EX-series switches, serious problems

[Jeff Wheeler]

Junos 11.4R1.6 is currently shipping on new EX-series switches.  In
this release, the CLI program isn't even stable.  I've had it crash on
me before I can even get as far as to commit a root password.

For the EX PMs who may be reading, please change the version that
ships on new-in-box units to one that isn't so buggy that it should
never have been released.

Is it your express goal to make sure customers buying new units
understand than many Junos releases are such garbage as to be
unusable?  To inform us that your Q/A is non-existent?

Is there an 11.4R that basically works?  Yes.

Is there one that JTAC recommends?  Yes.

Is the currently-shipping version covered by Juniper security
vulnerability notices indicated to be serious?  Also, yes.

Is that supposedly-serious vulnerability fixed in the JTAC-recommended
version, which functions better?  Again, yes.

Why is that not the version that ships on new kit from the
distributors?  Bad management.
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos 11.4R1.6 shipping on new EX-series switches, serious problems

[Jeff Wheeler]

On Sun, Jun 23, 2013 at 6:02 PM, Chris Adams c...@cmadams.net wrote:
 Once upon a time, Gavin Henry ghe...@suretec.co.uk said:
 We're getting two EX4200's and two MX5's delivered this week. Hope
 they have the recommend JTAC versions on them!

 Why do you expect they will?  The recommended releases are not very old;
 it isn't like Juniper (or any other vendor) is going to pull back all
 the stock in the supply chain and reload the OS every time they change
 the recommended release.

I don't expect them to do that.  I just expect a Release version that
isn't so bad, that the CLI is unusable, to be installed on the
switches from the factory.  Sure, it may take some weeks to deplete
all the remaining inventory that still has 11.4R1 on it, and that's
fine.  Continuing to ship a version that is so broken is idiotic.

Yes, as Mark says, customers who have a clue are going to install a
different version anyway.  Not every customer has a clue.  Some might
expect the software that ships on a switch that has been out for 4+
years to basically work right.  The reason it doesn't is they seem to
change the shipping Junos only when a new extended support release
comes out, or when new EX switches come out that they want to be able
to stack with older ones out of the box.  That would be fine if
those releases worked right.

Fix it, EX PMs!  This is a simple problem with a simple solution.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Inter-racks switch routing recommended practice

[Jeff Wheeler]

On Tue, Jun 4, 2013 at 9:24 PM, Ihsan Junaidi Ibrahim ih...@grep.my wrote:
 I'm thinking multi-areas OSPF/v3 but would a flat OSPF area 0 topology with 
 BGP make more sense? I don't have a lot of exposure in dense datacenter 
 routing so I'm bringing the conventional WAN routing thinking cap into the 
 picture.

This is really a scale question.  I think you'll find that, if you
just dump everything into area 0 for now, it will not be very
difficult to change that later on should you need to scale up.

Note that the EX4550 has a rather small FIB/TCAM even compared to the
EX4200.  For tens of racks, this should be no problem.  It is not what
I would consider a good datacenter aggregation platform, though, due
to its limited FIB.  If you scale up you may find that you need to
move layer-3 aggregation to a different kind of box.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ex4500 best-effort drops nowhere near congested

[Jeff Wheeler]

On Tue, May 7, 2013 at 4:01 PM, ryanL ryan.lan...@gmail.com wrote:
 good discussion. the tl;dr - nothing i can do about it. right?

You can add LACP/ECMP ports/paths to reduce the chance that packets
need to be buffered so long that the buffer becomes full.

To use a dirty word, flow-control might be an option as well.
However, you need to carefully test the particular switch and software
to see if it works with any sanity.  Also remember that flow-control
is likely to effectively cause HoL blocking on a port transmitting a
lot of traffic toward another port that is busy, and other ports which
aren't.  For example, you would not want to send flow-control to a
10GE storage server's port that is transmitting to any 1GE ports
because it would likely be harmful to storage performance for all
connected hosts, whenever just one host's port is full.  I personally
think that the complexity, buggyness, and potential gotchas of
flow-control far out-weigh the small potential gains.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ex4500 best-effort drops nowhere near congested

[Jeff Wheeler]

On Wed, May 1, 2013 at 8:27 PM, ryanL ryan.lan...@gmail.com wrote:
 i'm guessing this is a buffer thing, but i can't explain why it only
 happens on my 1ge ports and not when i punt the traffic over an 10ge

Yes, it is a buffer thing.  A 10GE interface is basically never going
to not have time to transmit frames unless it is receiving from 10 or
more 1GE interfaces at the same instant, steadily, for long enough to
fill the buffer; or there is at least one 10GE interface also talking
to it.  On the other hand, two 1GE interfaces transmitting toward the
same out-going 1GE port can fill its buffer.

This is sometimes not obvious, because you look at the long-term
traffic and see a few hundred Mb/s, thinking, why is there packet
loss?  You must keep in mind that the available buffer on modern ToR
switches is often less than 1ms worth of traffic.

The buffer bloat discussion of recent years has not done us any
favors.  Many customers now think that buffers have historically been
too big.  In fact, they were just often used incorrectly / configured
badly.  Now we are not evaluating purchases based on having sufficient
buffer, so vendors have spent years developing products that ... lack
sufficient buffer.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP on logical-system fxp0

[Jeff Wheeler]

On Wed, Apr 24, 2013 at 7:17 PM, Brandon Ross br...@pobox.com wrote:
 On Wed, 24 Apr 2013, Pavel Lunin wrote:
 This is what I never understood. Why people want to use fxp0 (or any
 other dedicated management) iface for real production management?

 Are you suggesting that they should purchase a 10/100/1000 copper card just
 for management?  Or are you suggesting that they should buy 10GbE switches
 for their out of band management network?

No, he's questioning the wisdom of doing SNMP queries, and other
automated, routine management functions, against fxp0 instead of an
interface that is protected by the hardware CoPP.

One of my clients uses an NMS that sometimes starts sending ~3k PPS of
SNMP BulkGets to a router.  They don't know why.  If that traffic was
hitting fxp0 with no policer, etc. then it would consume a lot of CPU.

My view is that fxp0 is an out-of-band interface for manual
intervention; not one that I ever use for SNMP.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX Switch Question

[Jeff Wheeler]

On Sun, Mar 31, 2013 at 10:18 AM, Mark Tinka mark.ti...@seacom.mu wrote:
 no answer to Cisco's ASR1000. Even just for route
 reflection, I'd be very hard-pressed to choose a US$1 MX480
 with a 16GB RE over a Cisco ASR1001 costing ten thousand
 times the price.

These are all symptoms of Juniper's incompetent management.

* inability to manage supply chain  logistics, leading to 6 month
lead times on incredibly high-margin products
* essentially no software Q/A
* consistently failing to deliver on software commitments / roadmap
* big gaps in the product line that could be fixed easily, but aren't
* far worse TAC than competitors
* refusal to admit basic, obvious, and huge bugs exist so they can be fixed
* widespread ineptitude in the sales and sales-support force
* misplaced RD efforts
* basic features that customers require missing from products *by
choice* while competitors have those features

Just problem #1 clearly demonstrates that upper-management has no idea
what they are doing.  They are managing their inventory like they're
making automobiles with razor-thin margins, not I.T. products which
sell for many multiples of the manufacturing and logistics cost.  Not
only that, but they have no systemic way for customers to expedite
orders (and generate revenue / additional margin from such expedites),
which is just leaving money on the table.

They cannot even solve the basic, easily-fixed problems with their
business.  I have little faith in Juniper's long-term future.

--
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Weird routing issue on my MX80

[Jeff Wheeler]

On Fri, Mar 29, 2013 at 9:37 AM, Matthew Crocker matt...@corp.crocker.com
wrote:
 Is it possible for the FIB to contain different information than what's
in 'show route'?
 How do I look at whats in the FIB?

Yes, it is possible.  Start with user@cli *show pfe route ip prefix
192.0.2.0/24*

 How do I reset the FIB and resync it with the actual routes?

If only Junos would get a command-line tree like *clear cef* so the user
has a reasonable option (not rebooting PFEs) for fixing these problems.
 But that would first require Juniper to admit that this happens often
enough that customers need it.  It took Cisco a few years to reach that
point with customers begging for things like CEF Scanner.

I do not think this is your problem though.  If you ran show route A.B.C.0
detail on the ASBR that is connected to your customer, you must either be
doing ECMP to a customer loopback IP, some other ebgp-multihop business, or
whatever.  In any case, you didn't provide enough relevant information for
anyone to say for certain; but I suspect your router is not malfunctioning.
 You have probably just made a mistake.

 show route A.B.C.0 detail

 inet.0: 439841 destinations, 876907 routes (439825 active, 0 holddown, 32
hidden)
 Restart Complete
 A.B.C.0/24 (1 entry, 1 announced)
 *BGPPreference: 170/-101
 *Next hop type: Indirect*
 Address: 0xdeadbeef
 Next-hop reference count: 6
 Source: X.Y.Z.11
 Next hop type: Router, Next hop index: 1048574
 Next hop: Q.W.E.195 via ge-1/1/1.0
 Next hop: X.Y.Z.11 via ge-1/1/2.0, selected
 Protocol next hop: *T.U.V.122*
 Indirect next hop: 160865a0 1048575
 State: Active Int Ext
 Local AS:   Peer AS:  
 Age: 13:39  Metric: 0   Metric2: 20
 Task: BGP_.X.Y.Z.11+12834
 Announcement bits (3): 0-KRT 4-BGP RT Background
5-Resolve tree 1
 AS path: 2 I
 Accepted
 Localpref: 100
 Router ID: M.N.O.169

If this were a vanilla eBGP session to the customer and your paste is from
the ASBR terminating the customer's session / circuit, it would say *Next
hop type: Router* so you might want to double-check the differences between
the correct and incorrect customer routes before investigating further.

If you do find the PFE route doesn't match the software's idea of what
should be in the FIB, I will be a bit surprised in this case; but I think
the above should be helpful either way.
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Am I carrying this route or not ?

[Jeff Wheeler]

On Sat, Mar 23, 2013 at 5:21 PM, Zehef Poto mpdech...@gmail.com wrote:
 I just inherited our backbone. We're a small LIR, we have an AS. The
 backbone consists of four MX80 routers, all acting as eBGP edge ones (there
 are various IP transit links up and running on all of them). I also use
 OSPF adjacencies, and iBGP. Again, all of this is very new to me, so I'm
 learning little by little. Sorry about possible mistakes/errors.

I think you had better get some help before you break your network!

 The question is : how can I check if a particular route is being carried in
 my backbone ? How can I make sure that's not the case ? I'm being suggested
 to use next-hop-self, but for some reason I can't fully understand what's
 involved here...

In the CLI, use the command:
show route 192.0.2.0/24
Hit ? for options such as exact, detail, etc.

Whoever that person is that said something about use next-hop-self
in this context, either you misunderstood them, or you shouldn't
listen to them anymore.  That has nothing to do with looking to see if
your router knows about a route.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Problems with Link Aggregation

[Jeff Wheeler]

On Wed, Mar 6, 2013 at 9:15 AM, Filippo Cugini filippo.cug...@cnit.it wrote:
 However, when we send traffic on the aggregated link, just one ge works, and
 we experience packet loss when we exceed the throughput of 1000mbps.
 Indeed, the statistics of all interfaces show that only the ge-0/0/12 is
 utilized to forward the data traffic, while the other two interfaces send
 and receive only signaling packets.

What kind of traffic are you sending over the LAG?  It may be all
hashing to one of the member-links.

Read this:
http://inconcepts.biz/~jsw/disadvantages_of_nxgbe_links.pdf

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX VC mixed mode experience

[Jeff Wheeler]

On Fri, Mar 1, 2013 at 10:50 AM, Riccardo S dim0...@hotmail.com wrote:
 I'm wondering if anybody have info or experience in a scenario
  with mixed virtual-chassis (6 equipments between 4500 and 4200) with high 
 density
 (more or less 70) of 10GBs ports.

 Since these architecture should be placed in a
  very sensitive position (servers and storage managing online systems of an 
 important airport),
 I'd like to have some informal feedbacks if any problems or whatelse have 
 been experienced by somebody...

 Why chose this design ? only costs...

Sounds like carrier grade to me.

My understanding is there is still no high-speed stacking module for
the EX4500 expansion slot.  Your virtual-chassis obviously won't
approach full wire-speed.  With that said, when you need a mixture of
1000baseT and SFP+ ports, it is a decent configuration.

ARP still sucks on the small-EX platforms but it has improved in 12.3,
which is a welcome change.  Still pretty bad though.  They have made
`clear arp` do what it's supposed to do, but I guess adding something
like `clear arp interface foo all` was too hard.  Go figure.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX3600 port buffers

[Jeff Wheeler]

On Tue, Feb 12, 2013 at 2:39 PM, Piotr piotr.1...@interia.pl wrote:
 I looking some info about buffers size in this model ? Are they
 configureable ?

It is the same chip as the QFX3500 and has similar  10MB buffer for
the whole chip, which is similar to other products in this segment.
It is configurable.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] large subnet/no memory

[Jeff Wheeler]

On Mon, Feb 11, 2013 at 1:44 PM, The Drifter prophecy...@hotmail.com wrote:
 How would you weigh the effectiveness of using your suggestion versus 
 Cristian's?

Well, Christian's suggestion will not solve your problem at all.  I'd
say that should be a good indication.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 BGP performance after reboot

[Jeff Wheeler]

On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger
juniper-...@ml.karotte.org wrote:
 I noticed that a MX80 takes quite a long time after reboot to put all
 routes into the KRT. Is that normal for that box? It takes around 10
 minutes after BGP is established to get all the routes into the KRT

Yes, the routes taking a long time to install is normal,
unfortunately.  I feel like it has got worse since 10.4 but that might
be my imagination.

I am sorry I missed Richard Steenbergen's lightning talk at NANOG,
which was something like if you want your routers to install routes,
call Juniper and reference PR#whatever because they do not want to
fix this bug.

I am hopeful that the move away from a single Junos release strategy
to some segregation among different products will allow Juniper to be
more flexible in how they allocate development resources to different
platforms.

If I had to guess, I'd say the ddos-related log messages you are
reading are related to excessive need to generate ttl_exceeded packets
because of routing loops while BGP is announcing to neighboring
routers but the routes are not actually installed in the FIB yet.
Even if I am wrong about the specifics here, I am certain it is only a
symptom of the problem which is unrelated to the ddos-protection
feature.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos 12.3 Release Date

[Jeff Wheeler]

On Sun, Feb 3, 2013 at 6:25 AM, Craig Askings
caski...@ionetworks.com.au wrote:
 Juniper now want you to buy a Advanced features licence to support Unicast
 reverse-path forwarding (RPF), this is getting absurd.

I might think it less absurd if uRPF was more useful on EX3200 and friends.

Is the current behavior still that uRPF-strict is enabled globally
whenever you configure it for any one interface, and no allowance is
made for having two default routes to upstream routers (ingress
traffic from one upstream is discarded)?

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Smallest size IPv6 allocation typically advertised?

[Jeff Wheeler]

On Wed, Jan 23, 2013 at 5:50 AM, Saku Ytti s...@ytti.fi wrote:
 block in RIPE area, so deaggregation is must. I think in ARIN area this is
 different and two DCs would mean you could get two blocks.

ARIN rules effectively allow you to manage a /32 (or more) per POP,
with every POP getting the same sized block, rounded up to
nibble-boundary based on your plans.  You then take your number of
POPs and round that up to nibble-boundary.

This means many networks can effectively go to ARIN and get a /28 or
/24 today with no problem; some networks even bigger.  It also means
for ISPs there is going to be much less need to announce any routes
smaller than /32.  For PI end-users, though, the waters remain murky.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug

[Jeff Wheeler]

On Mon, Jan 21, 2013 at 4:27 AM, Alex Arseniev alex.arsen...@gmail.com wrote:
 Probably not what you want to hear at the moment but it is working as
 designed.

No, it isn't.

Junos BGP is announcing routes it knows, for sure, are invalid.  It
knows that because BGP is making up a wrong label (2^20-1) because it
hasn't allocated one, and it can't announce the route without a label.
 This is an inexcusable bug that is very far from working as
designed.

The documentation is wrong, you cannot configure both AFI=1 SAFI=1 and
AFI=1 SAFI=4 on the same BGP session.  If it worked as documented, the
above behavior would not happen, and AFI=1 SAFI=1 would be available
to use for these routes.  That is not the case.

--
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug

[Jeff Wheeler]

Dear List,

The process of raising a PR with JTAC generally makes me want to scream, so
I thought I would post first, and perhaps some kind Juniper person can
input a PR# without me having to reproduce the problem again and jump
through twenty hoops to later be told working as designed.

When configuring BGP labeled-unicast on Junos, you might think (like I
hoped) that you could use LDP to create FECs and allocate labels, and then
use those labels in your MP-BGP session.  Unfortunately this does not work,
and the basic reason is Junos BGP wants to allocate its own labels, and
won't consult the LDP FEC table to see if any already exist for a given
protocol next-hop which is being announced to the neighbor.  Fine, so it
wants to allocate its own labels.

However, trying to avoid this behavior, I found it's pretty easy to get
Junos to announce broken labeled-unicast routes that can never work, even
though the receiving BGP speaker has no idea they are invalid.  The
receiver will just install the routes, forward traffic, and the traffic
will get blackholed.

This happens because Junos is trying to announce NLRI with no allocated
labels (because layer-3 next-hop is not self) and it can't announce them
when labeled-unicast is configured, because the documentation is wrong, and
you canNOT actually configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the
same BGP session.  It simply does not work, and the Juniper documentation
on this subject is incorrect.

So what happens is, the announcing router knows it wants to announce a
prefix, but it has no label stack for it, won't allocate one, and instead
it just puts in label 1048575, or 2^20-1.  This label is not in the LFIB,
so when that router receives packets with that label, it doesn't pop the
label and do a layer-3 look-up.  Instead, it just discards the packets.

Worse than that, the announcing router's `show route advertising-protocol
bgp neighbor` output is incorrect.  It shows no label, even though it
really is sending a label stack with 2^20-1.  You have to go over to the
receiving router to find this out.

So this combination of documentation bugs and ridiculous Junos ability to
announce labeled BGP routes that it knows for sure are invalid, is quite
foolish, to say nothing of the fact that it won't just use FECs you already
created using LDP. :/

Anyway, if you ever get labeled BGP routes with label 2^20-1, this might be
why.  Hopefully some kind Juniper folks will be willing to file some bugs
on this for me, because I don't have a week to fight with JTAC about it. It
is, however, very easy to reproduce the problem. :-)

Thanks
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MLD snooping and IPv6 ND

[Jeff Wheeler]

Could any of the Juniper folks mail me off-list regarding some MLD
snooping and IPv6 ND interactions?

Thanks
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Debugging mysterious packet loss on J2350 under stress

[Jeff Wheeler]

On Sat, Dec 29, 2012 at 3:18 PM, 叶雨飞 sunyuc...@gmail.com wrote:
 InterfaceLink  Input packets(pps) Output packets
 (pps)
  ge-0/0/0  Up11772104571  (24744)  11662868938
(161012)
  *ge-0/0/3*  Up 3405764281 (*148559*)   6036903599
 (12097)

 traffic is routed from ge-0/0/3 to ge-0/0/0.   *ge-0/0/3 is 100M* link,
 which is not being used in full, ge-0/0/0 is 1G link:

That link is full.  A 100Mb Ethernet circuit can't carry more than 148Kpps.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 4 byte as mixed with 2 byte recieving problem

[Jeff Wheeler]

On Tue, Dec 11, 2012 at 6:04 AM, moki vom...@gmail.com wrote:
 The customer have 4byte as and requested we add prepend (with our
 as) to

Loop detection is preventing your RR from accepting the path.  Do you
actually need the prepend behavior to influence best-path selection
inside of your network, or does the customer really want you to
prepend your AS when you EXPORT the route to your EBGP NEIGHBORS?

I think what you need is a mechanism for prepending upon export.
Normally this is implemented by assigning a BGP community and doing
the prepend in your export policy.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] small multitenant datacenter

[Jeff Wheeler]

On Mon, Dec 3, 2012 at 11:06 PM, Ryan Goldberg rgoldb...@compudyne.net wrote:
 Do you see an issue with blowing up ex4200s with all this ospf and vrrp?  I'm 
 labbing tomorrow and will try to get the boxes to thrash.

I'm interested to know your thoughts on RE performance after you have
labbed this scenario.  I've read the EX4200 supports 256 VRF-Lite
instances, but like you, I imagine the control-plane may become
sluggish before it gets to that point.

I noticed you include the EX3300 in your design.  I also considered
this switch and decided against it once I read the feature table.  I
would like to use them once additional features are working, but right
now, it lacks critical items like storm-control.
https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html

Also, you mention both EX4200 virtual-chassis, and VRRP.  I think it
is unusual to choose BOTH V-C and STP+VRRP as redundancy mechanisms,
because you get the worst of both worlds in terms of potential
failure modes.  For example, you get the unknown-unicast problems
associated with ingress traffic arriving on the VRRP non-master and
potentially being flooded out many ports of that switch, because it
may never learn MAC addresses of downstream servers while it is the
non-master.  You also get any problems that you might encounter with
virtual-chassis, meaning, bugs.

I think you should pick one: V-C or STP+VRRP, depending on which
technology you are most comfortable with.  Mixing the two is IMO not
smart, not because of any unique problems that arise from this
combination, but simply because you have decided to expose yourself to
two sets of gotchas without necessarily gaining anything.

My experience with EX4200 virtual-chassis has been extremely good
since Junos 10.4.  Before then, we had problems with file system
corruption on the EX4200, but this was fixed in 10.4.  I have not had
any serious stacking-specific bugs since about Junos 9.5.  I rely
totally on EX4200 virtual-chassis for redundancy in many environments,
and am very pleased with the results.

Good luck with your project.  I hope my comments are constructive and helpful!
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Set weight (BGP attribute) in JunOS

[Jeff Wheeler]

On Sun, Nov 25, 2012 at 4:56 AM, Mihai mihaigabr...@gmail.com wrote:
  Weight is a Cisco proprietary thing and cannot be used with a Juniper
 device. Maybe you could use preference (not local-preference).

preference in JUNOS is like administrative distance on IOS.  It's
probably a good idea to mention this when suggesting its use as a
substitute for weight because it is conceptually different.  Like
weight, though, it is possible to make your iBGP domain produce
unusual results if you fool around with preference.  Unlike
local-preference, these changes are not signaled to iBGP neighbors.
In a network like:

A---B---C

If you alter preference on router B, it is possible that router A will
send packets for a prefix which it thinks will exit the network at
router C, but in fact, router B has made a different bestpath
selection and picked its own neighbor as the egress for that prefix.
This may make the network confusing to troubleshoot.  If you had BGP
customers who weren't stupid, it would anger them.  If you have
labeled-unicast it would not happen though.

--
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Set weight (BGP attribute) in JunOS

[Jeff Wheeler]

On Sun, Nov 25, 2012 at 6:29 PM, Ali Sumsam
ali+juniper...@eintellego.net wrote:
 Actually I am working on migration from Cisco to Juniper.
 On Cisco router weight attribute is used and have to set same preference
 same on Juniper.

 Thats where I found that there is no weight in Juniper.
 Good to know some thing :).

I think you mis-understood the information you read in the
documentation that Ytti referenced.  Please see my earlier post on
this thread.  I will expand on it since you must not have gotten it
clearly.

On IOS, Weight is an attribute you can use to basically override the
whole BGP bestpath selection process, and pick a path you want.  This
is a double-edged sword.

If you use Preference1 on Junos to get the same effect you will
sometimes have results that are different than you expect.  Like I
mentioned before, Preference1 on Junos is the same concept as
Administrative Distance on IOS.  You usually use it to make one
routing protocol, or type of route, have better bestpath selection
than another.  For example, if you configure distance under router
bgp ASNXX.

This matters because if you were to pick Preference1 = 100 for a
route, and the rest of  the configuration was basically the default,
that route would be selected in favor of OSPF type E routes, which
normally have Preference1 = 150.  You might use such routes for
learning 0/0 inside your network, etc.

I think this is important for you to know before you finish your
project.  Otherwise, it may cause confusion later that you are not
equipped to troubleshoot!

--
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX110 and Cisco2970 MSTP issue

[Jeff Wheeler]

On Mon, Nov 19, 2012 at 6:04 PM, Ali Sumsam
ali+juniper...@eintellego.net wrote:
 If I try to set the priority on one of the SRX110 to become root bridge,
 MSTP seems to be converged but there are huge packet losses in the network.
 I removed the priority and one of the cisco2970 became root and then
 everything seems to be fine. No packet loss after that.

Just taking a wild guess here, but does the SRX110 have enough
forwarding performance, and enough port speed, to switch all of the
traffic between your 2970s?  Check the CPU usage and link headroom
when the SRX is root.  Unless you manipulate your port costs, the
configuration you suggested would have traffic going
2970#1---SRX110---2970#2.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX - DWDM no link

[Jeff Wheeler]

On Wed, Nov 7, 2012 at 2:37 AM, Luca Salvatore l...@ninefold.com wrote:
 This might seem silly but when I look into the XPF in the router I don't see 
 any red lights coming from inside the XPF. Normally when you look into a XFP 
 or SFP you can see the red laser inside it. I'm not seeing that with the XFP 
 in the MX. Should I be able to see a light?

 Any suggestions?  I have configured the wavelengths on each side and the 
 interface is just configured as a simple inet interface.

SwedeMike don't look into laser with remaining good eye!

The light coming from that XFP is not within the visible spectrum.
You can't see it BUT IT CAN DAMAGE YOUR EYE.  Do not look into it!

To be honest, I'm not sure your post isn't a troll!  However, there
are plenty of things that could be wrong with your installation.  The
Tx/Rx fibers could be reversed.  You may be using the wrong wavelength
for the underlying DWDM system.  The fiber span may not be good enough
for 10G -- are there other 10G waves working on it?  1G/2.5G waves?
You might need amplification or chromatic dispersion correction
equipment.  Your XFPs could be bad.  Maybe it's vendor fiber and it is
not patched correctly?  Perhaps you have in-building cross-connects
which are not completed or are of poor quality?

Who really knows?  You have done zero basic troubleshooting steps.
The reason why is (assuming you aren't a troll) you don't understand
what you are doing.  I think your project will be more successful if
you find a local contractor to help you.  This may sound rude, but you
are not even working SAFELY at this point, let alone effectively.  Get
yourself some assistance so you can get the job done without damaging
your eyesight or delaying your work.  You probably need someone local
to you, because there is a very big knowledge gap between what you've
got (in this specific context) and what you might need to troubleshoot
quickly and SAFELY.  The mailing list can hand-hold you through it if
you post more information and do a bunch of troubleshooting steps, but
I wouldn't want to be on the phone with my dark fiber vendor going,
well, some guys on juniper-nsp told me to rent a light meter and I
used it and can't see any signal from my other POP...  :-/

$0.02.  Again, I apologize if my response seems rude, but you are
going to harm your eyes!
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches

[Jeff Wheeler]

On Fri, Oct 26, 2012 at 2:46 PM, Morgan McLean wrx...@gmail.com wrote:
 fault tolerance. How reliable is VC? I've really done my best to avoid it

I can't speak to EX3300 specifically, but on EX4200 the VC works very
well.  I have many stacks running for many years, and have had no
stacking-related problems since before Junos 10.4R.

We configure no-split-detection on VCs of two units (like TOR) based
on our guess that it is much more likely one unit will fail
completely, than the likelihood of split-brain happening where both
switches are still working.  If it did happen we would have a fast
time-to-repair, and we think good MTTR is too often overlooked.

-- 
Jeff S Wheeler j...@inconcepts.biz +1 502-523-6989 Mobile
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Switch EX4200 doing broadcast for all ports from multicast traffic

[Jeff Wheeler]

On Fri, Oct 19, 2012 at 9:36 PM, Giuliano Medalha
giuli...@wztech.com.br wrote:
 We have 4 x EX4200 (4200-24F and EX4200-48T) running 12.1R3.5 code
 connected using Virtual Chassis configuration.

That's brave.  Perhaps you should consider running a version of Junos
that is less disasterous.  JTAC would recommend 11.4R5.5 as of this
week.  We have yet to have good results from any 12.x release on
EX3200/EX4200.
http://kb.juniper.net/InfoCenter/index?page=contentid=KB21476actp=RSS

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How are max routes calculated on an SRX

[Jeff Wheeler]

On Wed, Oct 17, 2012 at 8:38 PM, Ben Dale bd...@comlinx.com.au wrote:
 Table  Tot Paths  Act Paths SuppressedHistory Damp State
 Pending
 inet.0   1056579 354871  0  0  0   0
...
   Data plane memory576 MB Max   420 MB used ( 73 percent)   --- 
 FIB sits here

It's probably worth applying some simple arithmetic.  The DFZ today is
20% larger than in Ben's snapshot, above.  Data-plane memory use
obviously doesn't scale linearly with the number of routes, but it it
did, his memory use today would be ~88%.

Now add the IPv6 DFZ, which is still in its infancy at 10k routes
today, but requires more memory per route (a lot more, depending on
implementation.)

You just ran out of memory.  Today.  Not with IPv6 growth in the
future, or IPv4 growth in the future, but just by taking the current
IPv4 and IPv6 DFZ.

If I had that box deployed today, I would plan to upgrade it when
needed.  If I deployed it as a new device today, I would expect to be
fired.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX3500-48S4Q-ACR

[Jeff Wheeler]

On Thu, Sep 27, 2012 at 7:13 PM, Dave Peters - Terabit Systems
d...@terabitsystems.com wrote:
 We are considering deploying these for a customer's TOR, but I don't have any 
 experience with them.

 Anybody out there have experience or comments good/bad on these?  Anything I 
 should know going in?

We have several QFX in production in clients' networks, doing L2, and
are mostly satisfied.  We are recently working on a problem with high
amount of unknown-unicast or multicast traffic but we are not sure the
problem is the switch.  If this is our only gripe, I'd say that is an
indicator the switch works well.

We haven't done any L3 or QFabric.  The reason for no L3 is there are
some hard-coded CoPP accept rules that you cannot override by
configuration which make the switch unusually vulnerable to a DoS
attack.  Juniper says they will not address this, so we don't have
hopes of using them for L3 in the future.

I think QFabric is brain-damaged and doubt we will ever try it.

Also, if you run software before 12.2, you should apply a fix
suggested by JTAC to stop the switch from hanging when you plug/unplug
the serial port, or send it a break.  The PR# is finally un-hidden
(now that they have fixed it, go figure) and is available below.  You
just need to modify /etc/rc.conf.platform or upgrade to 12.2.
https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR769146
This is the worst problem we had with the QFX and it took us a lot of
time to realize what was going on.  Hopefully it will save you some
trouble!

Overall, I continue to recommend QFX to my clients for layer-2 where
commit/rollback is beneficial.  Outside of that, I believe it has
limited application at this time due to the CoPP problems; but Juniper
could decide to fix that if they think some customers will buy the
switch because of fixing it.

My $0.02
-- 
Jeff S Wheeler j...@inconcepts.biz +1 502-523-6989 Mobile
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX3500-48S4Q-ACR

[Jeff Wheeler]

On Thu, Sep 27, 2012 at 9:15 PM, Julien Goodwin
jgood...@studio442.com.au wrote:
 some hard-coded CoPP accept rules that you cannot override by
 I know Trident+ (which this uses) has some weird limitations around this
 area, any idea if this actually is one?

No, I believe it is a choice by Juniper not to change it, because they
think it will give customers too much rope.  I really doubt the chip
is hard-wired to punt all BGP packets but that's basically what
happens.

Also the ACL TCAM is relatively small and CoPP rules use up a lot of
TCAM rows.  There are some Juniper KB entries on this.  So if you
configure say, like this:
interface lo0.0 family inet filter input [ MYCOPP ]
interface xe24.0 family inet filter input [ CUSTOMER1FILTER ]
interface xe25.0 family inet filter input [ CUSTOMER2FILTER ]

and MYCOPP uses up 30 TCAM rows (easily possible) then it will
actually use 30, then 30 more (on top of whatever CUSTOMER1FILTER
needs) for xe24, and yet 30 more for xe25 (plus that customer's filter
rows.)  So you can exhaust your available ACL TCAM rather quickly if
you are doing much on it.

 I think QFabric is brain-damaged and doubt we will ever try it.

 Really? Any reasons why? (other than the whole locked optics thing)

I think their whole concept for the control-plane is bad and
unreliable.  If you are considering QFabric I think you should buy
enough hardware for testing and reboot the control-plane switches a
few times and watch how long it takes to start working right again.

They say they will/have fix the optics lock-in but I have not tested
this recently.

Just my $0.02 but I think QFX is good for L2, not so good for other
things at this time.
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 bridge-domain QinQ question

[Jeff Wheeler]

On Sun, Sep 23, 2012 at 6:28 AM, Robert Hass robh...@gmail.com wrote:
 Could you paste working configuration here if you find solution ? As
 I'm also interested in same configuration.

Sorry, Robert (and others who might find this thread in The Google)
small update:

The previous configuration I pasted did not work because we need to
manipulate the VLAN tags.  On my EX-facing interface we had to make
the following config:

root@CR3.1250RL# show interfaces xe-0/0/3.423
description CUSTXP xxx Internet;
encapsulation vlan-bridge;
vlan-id 423;
input-vlan-map {
push;
vlan-id 1428;
}
output-vlan-map pop-swap;
family bridge;


Notice above I am adding input-vlan-map and output-vlan-map.  We
tested this today and it works.  I am not sure if we can do a
swap-swap or similar in order to connect to more CE that have
different outer-tags, though.  :/
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Config help for basic MPLS setup

[Jeff Wheeler]

On Mon, Sep 24, 2012 at 6:55 PM, Caillin Bathern caill...@commtelns.com wrote:
 On point 2 there, the ex can only process one label at a time but there could 
 be a larger label stack than that so it can be a P router.

I've been told the EX4200 will actually drop frames with more than one
MPLS label.  If you are able to get your proposed configuration
working, please post a follow-up.  I would like to know if it will
indeed function as a P box.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 bridge-domain QinQ question

[Jeff Wheeler]

On Sun, Sep 23, 2012 at 6:28 AM, Robert Hass robh...@gmail.com wrote:
 On Thu, Sep 20, 2012 at 8:39 PM, Doug Hanks dha...@juniper.net wrote:
 [...]
 You'll just need to define each CTAG as you have been doing.

 Hi Jeff
 Could you paste working configuration here if you find solution ? As
 I'm also interested in same configuration.

Hey, Robert, I have just configured a bridge-domain and associated
LIFs per each CVLAN.  It works just like this:
root@CR3.1250RL show configuration bridge-domains
vl423 {
description CUSTXP xxx public;
interface xe-0/0/3.423;
interface ge-1/1/8.14281;
}
vl424 {
description CUSTXP xxx LAN;
interface xe-0/0/3.424;
interface ge-1/1/8.14282;
}

root@CR3.1250RL show configuration interfaces ge-1/1/8.14281
description CUSTXP xxx public;
encapsulation vlan-bridge;
vlan-tags outer 1428 inner 423;
family bridge;
root@CR3.1250RL show configuration interfaces ge-1/1/8.14282
description CUSTXP xxx LAN;
encapsulation vlan-bridge;
vlan-tags outer 1428 inner 424;
family bridge;

root@CR3.1250RL show configuration interfaces xe-0/0/3.423
description CUSTXP xxx public;
encapsulation vlan-bridge;
vlan-id 423;
family bridge;
root@CR3.1250RL show configuration interfaces xe-0/0/3.424
description CUSTXP xxx LAN;
encapsulation vlan-bridge;
vlan-id 424;
family bridge;

Basically, if we needed to haul a lot of CVLANs into the
bridge-domain(s) for connection to several other sites, we would have
to push an outer-tag onto the CVLANs using the EX4200 in the
datacenter network, and pop them back off at their office CEs.  That
would allow doing it without b-d and LIFs per every CVLAN.  We don't
want to do the push on the EX4200 though, because in this instance,
the customer only has one port on the datacenter network for mixed
use.  If the customer asked for a bunch more CVLANs to be hauled
around for them we would ask them to take another switch port to
simplify things.  For only two CVLANs the above is pretty sane and
better for us than making the customer take more ports.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 bridge-domain QinQ question

[Jeff Wheeler]

On Wed, Sep 19, 2012 at 4:07 PM, Doug Hanks dha...@juniper.net wrote:
 Use a SP-style IFL using 802.1ad for telco. Use a SP-style IFL using
 802.1q for the EX4200. The BD will automatically pop and push tags for
 you.

Could you give an example?  I searched high and low in the KB and
elsewhere.  What I am doing now is below.  The physical interfaces
obviously have many other things connected and are setup with
flexible-vlan-tagging and encap flexible-ethernet-services.

interface ge-1/1/8.14281 {
  description customer office via telco network;
  encapsulation vlan-bridge;
  vlan-tags outer 1428 inner 423;
  family bridge;
}
interface xe-0/0/3.423 {
  description customer servers via EX4200;
  encapsulation vlan-bridge;
  vlan-id 423;
  family bridge;
}
bridge-domain vl423 {
  interface ge-1/1/8.14281;
  interface xe-0/0/3.423;
}

The above configuration works.  Unfortunately, I must duplicate the
above stanzas for each CVLAN.  If I try to use vlan-id-list [ 423 424
] on the EX4200-facing port, the IFL sees 0 packets.  For example:

interface xe-0/0/3.423 {
  description customer servers via EX4200;
  encapsulation vlan-bridge;
  vlan-id-list [ 423 424 ];
  family bridge;
}
That commits but xe-0/0/3.423 never sees any packets arrive, and the
BD never learns any MACs from it.  Certainly it doesn't work as I
thought it might.

Using interface-mode trunk and configuring a vlan-id-list in the BD is
not possible, as far as I can understand, because I can't work out how
to configure the telco-facing IFL to push/pop as needed to get the
outer-tag on it.  It seems I can't use input/output-vlan-mapping in
concert with a BD configured with a vlan-id-list in order to utilize
mode trunk.

Thanks
--
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP setup question, advertise-peer-as?

[Jeff Wheeler]

On Sat, Aug 25, 2012 at 7:26 AM, Morgan McLean wrx...@gmail.com wrote:
 My main issue is I can't seem to get the advertised routes from firewall A
 to be shared between the border routers. I know the nature of iBGP will
 block this, so I tried enabling advertise-peer-as for just the border to

I've read your posts to date.  I do not clearly understand if you have
a full iBGP mesh or not.  If you do, ASBR-B does not need to learn
FW-A's routes from ASBR-A.  ASBR-B will already be learning FW-A's
routes directly.

If you want ASBR-A to re-advertise FW-A's routes to ASBR-B then you
must use route reflection or similar.  The advertise-peer-as feature
is unrelated to what's going on here.

I hope the above gives you a starting place.  I think if you re-read
the rules for when routers will re-advertise a route to an iBGP
neighbor, you will quickly feel silly and wonder why you didn't figure
this out yesterday :)

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] OSPF Forwarding Address

[Jeff Wheeler]

On Thu, Aug 2, 2012 at 7:59 AM, Benny Amorsen benny+use...@amorsen.dk wrote:
 If I replace router1 with a VRF on a Cisco 7600, Forwarding Address
 is set to 10.10.200.1 and everything works as I expected. This is
 obviously not my preferred solution :)

Do router2 and router1 have an OSPF adjacency on the /27?  This is
required for forwarding-address to be set.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vmember limits in EX series stack

[Jeff Wheeler]

On Mon, Apr 30, 2012 at 11:15 PM, Naveen Nathan nav...@lastninja.net wrote:
 I'm attempting to retire a cisco 6509 setup, replacing it with an EX4200
 virtual chassis configuration (8 linecards). I've run into a warning
 when committing the configuration:

I found your problem.  You are attempting to retire a Cisco 6509 by
replacing it with a closet full of stackables.  That is a pretty
foolish thing to do.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper SFP's

[Jeff Wheeler]

On Tue, Apr 24, 2012 at 9:02 PM, Skeeve Stevens
skeeve+juniper...@eintellego.net wrote:
 Juniper are really pissing me off in regards to their SFP's.

Agreed.

 Is there ANY actual difference between these SFP's? They are all the same
 price from the distributor but they all have different availability - see
 number above for example from one of my disties.

Yes.  The QFX3500 actually requires QFX-specific SFP/SFP+ and even the
Juniper OEM ones for other Juniper products will not function in a
QFX3500, at least as of 11.3.  A little bird told me that they will
remove the optics lock-in sometime this year.  The sooner this
happens, the better.

I, too, am not willing to wait for Juniper to supply me with SFPs,
especially since Juniper is honestly pretty bad at supply chain /
logistics, and does not even offer colored SFPs for some of these
products.  Cost is not the overriding concern here, it is
AVAILABILITY.

We literally shipped a QFX3500 to a third-party optics vendor's lab
and had them figure out how to re-flash generic optics so they would
work in it.  This because our SE gave us an incorrect answer about
whether or not it would work with generics -- turns out it doesn't.
One of my clients was so angry about this that they returned some of
their QFX3500s and got their money back over this, and bought another
manufacturer's product instead.

I can only guess that the reason Juniper has different SKUs for the
optics for different product families is that this is the mechanism
they use to credit the optics revenue to the correct product group,
and this must be why the QFX won't work with Juniper optics from other
product lines.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] redistribute iBGP learned routes

[Jeff Wheeler]

On Sun, Apr 22, 2012 at 1:53 PM, Matthias Brumm matth...@brumm.net wrote:
 Thanks for your insight. I would like to clean up our structure a bit,
 so I will go with route-reflection.

If you are not very knowledgeable about BGP, you should probably avoid
doing route-reflection (or confederating) until you have a more
thorough understanding of how things work and your various options /
caveats.

You may not be aware that you do not need a direct circuit (or VLAN,
etc) to establish an iBGP session from your access router to your edge
router.  Establishing iBGP sessions among all of your routers is the
normal way of deploying a small BGP network.

Route-reflection and confederating are good tools for scaling up, but
in this case, you are using a complicated tool that has non-trivial
caveats, because you do not understand some very basic things about
how BGP works.  This is not good for you or your BGP customer.  :-/

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JunOS 10.4R8.5 on MX5? Am I forced to run 11.4+?

[Jeff Wheeler]

2012/3/22 Timh Bergström timh.bergst...@videoplaza.com:
 I recently bought a MX5-T (Instead of the MX80-5G) and I'm running
 10.4R8.5 on my other MX80s and would naturally like to run the same
 codebase on all my MX-series hardware. However when I try to install
 the 10.4R8.5 release on the MX5-T it says that the platform is not
 supported, I thought the MX5/10/40 was the same hardware as the MX80
 (it surely looks the same, side-by-side)?

I just got an MX80 that won't boot 10.4 software.  Like you, I did not
want to upgrade to newer software yet, as my existing MX80s are all
running 10.4R4.5 and we are satisfied with it.

FYI my Midplane is REV 09, PEMs REV 04, QXM REV 06.  All part numbers
are identical to my existing MX80 routers in this network, the only
difference is the hardware revision numbers, and the fact that this
device doesn't seem to want to run 10.4.  I guess I won't plan on
deploying any new MX80s until I have time to test 11.2 or newer.
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] configure MAC address on MX logical unit?

[Jeff Wheeler]

I have a somewhat unusual network topology where it would really benefit me
to be able to change the MAC address used on a given AE interface logical
unit.  This does not seem possible in 10.4 on the MX series.  Is it
available in any later release?  For example, I wish to configure:

interface ae0 {
  unit 40 {
family inet {
  address ...;
}
  }
  unit 50 {
mac-address 02:02:02:04:04:04; /* different MAC for this unit */
family inet {
  address ...;
}
  }
}

The mac-address statement above is imaginary, it does not exist in 10.4,
but if something similar is available in a later release, it will compel me
to upgrade eventually.

I have tried tricking the router into doing this using VRRP, but I need to
establish an eBGP session from this unit 50, and the router still transmits
the BGP session packets with the hardware MAC address, not the VRRP address.
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] default Junos on EX4200s currently shipping

[Jeff Wheeler]

I am resurrecting this old thread because we are still receiving new
EX4200s from the distribution channel with Junos 11.2R1.2 on them.  This
version is so unstable on the 4200 it is pathetic.  Juniper guys, please
talk to whoever in the company decides what software ships on new products,
and make a change for these switches.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Set MED in BGP to IGP metric for iBGP NEXT-HOP router

[Jeff Wheeler]

On Tue, Feb 21, 2012 at 7:25 PM, Paul Zugnoni paul.zugn...@onlive.com wrote:
 I'm looking to set the MED on routes exported to eBGP peers to reflect the 
 IGP metric to the BGP protocol next-hop

I did not see any replies to your question.  Apologies if you already
figured this out yourself.

set metric igp already does what you describe.  You will also want to
read the documentation on `set metric minimum-igp` which is often what
folks really want.

Keep in mind that the MED will be set to the IGP metric to the
protocol next-hop, NOT the address of the router it learned the route
from.  You used both phrasings in your post.  So for example, if you
have a route reflector in your AS, a route may be learned from an RR
but the metric will obviously not be based on the path to the RR, but
the path to the next-hop.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX-UM-2X4SFP- 2-port 10G SFP+ / 4-port 1G SFP Uplink Module

[Jeff Wheeler]

On Tue, Feb 21, 2012 at 3:05 AM, Skeeve Stevens
skeeve+juniper...@eintellego.net wrote:
 The common thought was that you could use EITHER the 2 x 10Gb OR the 4 x
 1Gb.

You are correct.  It will not operate in a mixed mode.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PVLAN for tagged VLANs on EX4200

[Jeff Wheeler]

On Fri, Jan 27, 2012 at 12:37 PM, Shane Short sh...@short.id.au wrote:
 I'm currently trying to figure out how I can deploy either PLVAN or some kind 
 of local ethernet isolation on my network.
 I currently have a bunch of customers on /30 interconnects which are trunked 
 back to our EX4200 for aggregation. I'd like to somehow shift those customers 
 into a larger (say, /25) range, while forcing all the traffic through the 
 aggregation switch. I initially thought that PVLAN would do what I want, but 
 it seems to baulk I try and add one of the tagged VLANs into the mix. Basic 
 diagram is below (forgive my horrible ASCII art)

Also note that the EX4200 does not support l3-interface on a private
vlan.  In this role it is useful for L2 but not a mix of L2 and L3,
for private vlans.  The 4200 might not be able to do what you have
planned.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4200 missing ARP entry work-around

[Jeff Wheeler]

We have decided on a better work-around for our missing ARP entry
problems on the EX4200 and friends.

As you may recall, the EX4200 will sometimes have an ARP entry in the
control-plane, but it will not be present in the data-plane.  You can
investigate by checking your destination IP address with the command
`show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32`
which will produce output like this:

PFEM0(vty)# show halp-rt route ip rtt-index 0 prefix 192.0.2.2 prefix-length 32

  RouteType Paths RtIdx Rpf SipSa Row:Col:Row:Col
    - - --- - ---
  192.0.2.2  ECMP 0 2037  No  No439:0:0:0

  Dev0 (RtIdx:2037)
  -
  Command   : Route  CpuCode: 3
  AppSpCpuCodeEn: 0  UcSipFiltEna   : 0
  TtlDecEna : 1  TtlOptChkBypass: 0
  IngressMirror : 0  QoSProfileEn   : 0
  QoSProfileIndex   : 0  QoSPrecedence  : 1
  ModifyUp  : 2  ModifyDscp : 0
  CounterSet: 2  ArpBc2Cpu  : 0
  SipAccessLevel: 0  DipAccessLevel : 0
  IcmpRedirExpnMirr : 0  MtuProfileIdx  : 2
  Ipv6ScopeCheckEn  : 0  Ipv6DstSiteId  : 0
  NhTnnl: 0  NhTnnlIdx  : 0
  NhVlan: 6  NhIf   : VIDX4095
  NhArpIdx  : 138
Device: 0
  ArpEntry Idx 138  : 00:2b:f0:19:87:01
  Hit/Miss  : N

Notice above a reference to NhArpIdx 138.  In order for forwarding to
work correctly, there must be an entry # 138 in the `halp-nh
arp-table.`  Since there isn't one, the NhIf shown is VIDX4095, not a
port.  However, if you want to verify that there is no NhArpIdx 138 in
the hardware, you can examine the table with `show halp-nh arp-table`
and scroll down to where # 138 should be.  You won't find it!

PFEM0(vty)# show halp-nh arp-table
Device: 0
... lots of scrolling ...
  ArpEntry Idx 136  : 00:18:8b:f8:b6:6e
  ArpEntry Idx 137  : 00:0e:b6:2d:01:a0
  ArpEntry Idx 139  : 00:19:b9:f9:24:2a
  ArpEntry Idx 140  : 78:2b:cb:3c:91:60

How do you get the switch to populate that entry?  Well, since `clear
arp` on the EX4200 doesn't actually do what it is supposed to do, what
we have been doing in the past is deleting whole subnets, impacting
potentially many machines, and then re-adding them.  This is not good
but it does work.

Our new solution is much better.  We just add a bogus static arp entry
for 192.0.2.2, pointing to some made-up MAC address, and then we
commit, roll back, and commit again.  Like magic, the ARP entry will
re-populate correctly.  Almost as if you really did have a `clear arp`
command on the EX4200, one that worked right!

After adding and then deleting the bogus static ARP for 192.0.2.2 you
can re-examine the PFE and see the results.  Also, your customer's
Internets will begin working correctly again.

I hope this helps.
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX3500 optics lock?

[Jeff Wheeler]

On Sat, Jan 7, 2012 at 8:48 PM, OBrien, Will obri...@missouri.edu wrote:
 I'd make darn sure that Juniper knows that this is an issue for you.

In fact, we've let them know that the competing vendor is getting 60%
more money for a comparable product; but that large price premium is
worth it given the obvious logistical issues with stocking
vendor-coded optics.  Juniper could give me optics for free and it
still wouldn't be acceptable.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] QFX3500 optics lock?

[Jeff Wheeler]

We just received our first QFX3500s, and contrary to what the Juniper
SE told us, they will not work with non-Juniper optics.  Is there some
clever, undocumented means of using third-party optics in these
switches?  JTAC says it will never be compatible with non-Juniper
SFP+.  Right now it looks like we will be sending them all back and
going with another vendor.  Glad I wasted my time doing QA with the
sales engineer.. :/

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX3200 proxy-arp behavior

[Jeff Wheeler]

I'd like to describe proxy-arp behavior I am observing on the EX3200.
I am not sure it is really doing the right thing.  It certainly isn't
ideal for my topology.

I have an ISP who is unable or unwilling to route additional subnets
to my client via routing protocols or static routes.  They simply add
secondary interfaces to their router for everything.  I would like
nothing more than to abandon these jokers, but in the mean time...

allocation A 192.0.2.1/29 my EX3200, .7 ISP router

allocation B 203.0.113.128/25, .254 is their secondary interface, but
I split this subnet into various /30s and similar, and
203.0.113.254/31 is not utilized (so goes to default route, 192.0.2.7)

allocation C 198.51.100.96/27, .126 is their secondary interface, and
I have the whole /27 configured on one of my downstream interfaces

So my ISP uplink port looks like this:
 show configuration interfaces ge-0/0/23.0
arp-resp unrestricted;
proxy-arp unrestricted;
family inet {
address 192.0.2.1/29 {
primary;
preferred;
}
address 198.51.100.125/30;
}

Notice the additional 198.51.100.125/30 subnet configured on my
ISP-facing interface.  This was required because the EX3200 receives
the ISP's ARP WHO-HAS from 198.51.100.126 and, without this /30
configured, it either fails to respond to them or sends them out the
wrong interface (not sure which.)  As you may imagine, the ISP also
sends me WHO-HAS sourced from 203.0.113.254, but because I do not have
a route for that, the ARP behavior is correct without anything
hackish, for that allocation.

Obviously the solution to this is don't design the network stupidly
and maybe it wouldn't operate stupidly, but I found the behavior
described above surprising.  I think the EX3200 should simply respond
to the ISP gateway's WHO-HAS based on the L2 address of the request
and ignore the tell 198.51.100.126 entirely.  That is not what
happens.  I do not think there is a standard behavior defined since
all this proxy arp garbage is evil anyway.

Insights or comparisons with other vendors' behavior appreciated
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] TASK_OS_MEMHIGH on ex2200

[Jeff Wheeler]

On Mon, Jan 2, 2012 at 11:44 PM, Maciej Jan Broniarz gau...@gausus.net wrote:
 Today my switch started dropping traffic and in logs it says:

 Jan  3 05:30:49  ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of 
 memory, 100 percent of available
 Jan  3 05:31:49  ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of 
 memory, 100 percent of available
 Jan  3 05:32:49  ex2200-s1 vccp[748]: TASK_OS_MEMHIGH: Using 50598 KB of 
 memory, 100 percent of available

It looks like vccpd has leaked a lot of memory.  You may drop to the
shell and kill off vccpd, hoping that the switch returns to a working
condition momentarily, rather than freaking out and requiring a
reboot.  Personally, if I were you, I would just reboot it anyway.  If
you expect multi-year trouble-free uptimes from your switches you made
a bad purchase with the EX-series, and I say that as someone who does
advocate using them for certain things.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Issue related to ARP learning

[Jeff Wheeler]

On Fri, Dec 30, 2011 at 3:05 AM, Sachin Rai sachinrai1...@hotmail.com wrote:
 The thing is when I ping the IP 192.168.1.2 from EX4200 and run command 'show 
 arp' then it displays 192.168.1.1 and 192.168.1.2 binded with 
 aa:aa:aa:aa:aa:aa, and after this the IP 192.168.1.2 is pingable from 
 external network.

 I want to know why EX4200 is not displaying all the IPs configured on the 
 interface binded with MAC aa:aa:aa:aa:aa:aa. Can anyone help me on this 
 situation or explain me what is happening.

Sachin, could you post what JUNOS version you are using?

If I were you I would investigate in more detail, by using tcpdump or
similar on the server, and verify that the EX4200 is not sending ARP
WHO-HAS to the LAN when you try to ping 192.168.1.2 from the external
network.  With the information you supplied so far, I think the most
likely explanation is that your servers are somehow mis-configured.  I
would be the first to say ARP on EX4200 is bug-ridden and needs
serious attention, but with the limited details you supplied so far, I
do not think the EX4200 is malfunctioning.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] default Junos on EX4200s currently shipping

[Jeff Wheeler]

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
unusable.  Various processes crash at the most trivial operations,
commits, and the CLI even crashes when editing the config (before
making any commit) in some cases.  Yes, we change the software before
we deploy the switches, but I would hate to be an unsophisticated
customer who just expects the switch to mostly work right out of the
box.  It's a PITA even for me to get software onto the things when
they are drop-shipped to POPs with connectivity and serial consoles
waiting.

Perhaps putting a Junos on the switches that is remotely stable when
shipping them out from the factory would be a good idea.  I'm sure
this is obvious, but maybe the Juniper folks on the list could
communicate this obvious idea to the people who decide what version
ships on new units.

Merry Christmas!
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] default Junos on EX4200s currently shipping

[Jeff Wheeler]

On Wed, Dec 14, 2011 at 5:14 PM, Chuck Anderson c...@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 j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX as BRAS / demux

[Jeff Wheeler]

On Thu, Nov 17, 2011 at 12:32 PM, Bjørn Tore b...@paulen.net wrote:
        interfaces {
            demux0 {
                no-gratuitous-arp-request;

On other types of interfaces, you would also need
no-gratuitous-arp-reply, but it can't be configured there.  :-/
Perhaps there is an ER#?

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Wheeler]

On Fri, Oct 21, 2011 at 6:24 AM, Pavel Lunin plu...@senetsy.ru wrote:
 http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-00

 Keeping in mind what we discussed in the next thread, it's way too
 complicated for the cheap ASICs, used in ethernet switches. Most of them, as
 far as I understand, are just hardcoded to extract bits with given offsets
 and that's all. In addition, looks like they have a limited-size memory
 cells (registers or whatever), on which they can do xor/mod/cmp/etc for the
 hash-key calculations and hash-key-next-hop mapping.

Size of one MPLS header: 4 octets
Size of one IPv6 header (w/o TCP, etc.) 40 octets

Since many of these devices have IPv6 routing capability (with a
limited FIB size) it is certain that they can look far enough into the
packet to see as many labels as any reasonable design will require.
Whether or not they have the ability to understand those labels is
another matter; but if a chip can route IPv6 it can sure see as many
labels as you are likely to require.

On Fri, Oct 21, 2011 at 7:21 AM, Pavel Lunin plu...@senetsy.ru wrote:
 BTW, this is why I'm quite sceptically looking at the Juniper's marketing of
 Express Chip simplicity and corresponded benefits. Lower number of

I share your skeptical view of the PTX.  The power requirements they
have published (estimates, I imagine) are relatively high and FCS
density is not terribly exciting.  I hear the price is also not going
to be very exciting.  They have not said how much buffer it will have,
which would contribute to energy consumption.

As far as how they have decided to implement PTX, I guess if you are a
big enough customer, you can just ask them.  The forwarding look-up
itself is trivial and, assuming packets are arriving at a rate of
300MHz (two 100GbE interfaces) you could do it without any off-die
memory at all, which means you save pins and power by eliminating
off-chip memory banks.  The internal buffering / queuing across the
system fabric is probably more complicated than the destination
look-up.  QoS is another complexity.  i doubt it is quite as simple as
install less SRAM and rate the ALUs for more Mpps because they are
doing less work per packet, but certainly one area of the process
does get much less complicated.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Wheeler]

On Sun, Oct 16, 2011 at 10:02 AM, Julien Goodwin
jgood...@studio442.com.au wrote:
 Arista is the one company that seems poised to actually take this on and
 keep coming out with good hardware, at a decent price, with a powerful,
 open control plane. Their kit isn't Openflow interoperable yet that I
 know of, but that should be doable.

Every time I speak to Arista, I say, you know, if your software had
MPLS features at this price-point, we and everyone else would like to
buy a lot more of them... but they do not seem to understand the size
of the market that is available to them.  I'm sure they are doing a
lot of good business in 10Gb ToR / End-of-Row, and are clearly quite
good at it.  The large amount of RD needed to be an MPLS P box is, in
their mind, not worth the potential business.

I hope all of you guys say the same thing to your Arista rep whenever
you order their kit for more ordinary uses.  I agree that the biggest
threat to Juniper and Cisco is Arista, but I don't think Arista knows
it! :-)

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Wheeler]

On Sat, Oct 15, 2011 at 6:04 AM, Phil Mayers p.may...@imperial.ac.uk 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.

It's not so much that it's hard to predict -- it isn't.  It's hard to
market.  Customers can't understand that the 100 line ACL in front of
their server farm is spending too much time walking a structure (or
executing instructions) read from RAM.  They can understand if the
vendor says wire speed and that's what is marketable.  The trade-off
is flexibility, which you mention below...

 Having said that - personally I might be willing to trade line-rate
 performance for (say) an ACL mechanism with near line-rate for simple ACLs,
 the option of a jump opcode, and some way of knowing what the exact
 performance (range) of a given ACL/interface combo would be.

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.

 Do I take it that non-destination-based routing (policy routing, filter
 based forwarding) are therefore implemented differently on boxes that use
 RAM-based forwarding?

There's more than one way to do it, but to use M/MX as an example
again, this still happens using RAM.  In a box designed for routing
tables (or MAC/ARP/MPLS/etc) the size of what M/MX delivers, CAM is
not the most effective solution.  Could they glue some on for the
purpose of accelerating large ACLs?  It depends on the match terms.
CAM still cannot implement the fancy operations you can do with
Juniper firewall filters in one operation; all it can potentially do
is accelerate the types of filters that optimize better into TCAM
matches than ALU+RAM searches.

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.

 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?

I see Richard has covered this in his follow-up.  I'm sure you
eventually will get those cheap LSRs, but there is no reason for Cisco
or Juniper to be the first to market these devices.  Either one of
them could decide to spin up that product, glue it all together from
their existing technology, and ship it in no time; but why would they
when that would take away from big iron product segments?

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jeff Wheeler]

On Fri, Oct 14, 2011 at 3:52 AM, Michele Bergonzoni berg...@labs.it wrote:
 can only be done with TCAM. For those who want more info on this issue, this
 is the very interesting reference that I received in a private email:

 http://www.firstpr.com.au/ip/sram-ip-forwarding/

I wouldn't use that particular document as a reference.

On Fri, Oct 14, 2011 at 6:08 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
 On that topic; I'm familiar with how TCAM can be used to accelerate routing
 lookups, but less so with SRAM. Is the SRAM used to implement a simple

A CAM electronically searches all of its rows for matches at the same
time.  It is relatively expensive in terms of power/heat.  It has
never been a particularly smart way of doing many kinds of look-up
operations.  It is useful is when the data set is small, the size of
the rows / number of bits to search is fairly large, and distribution
of keys is basically random.  This is why CAM is used for Ethernet
switching, TLB in microprocessors, etc.

When your data set grows, like the DFZ, it is less expensive to have
an ordinary RAM and search algorithm.  Which particular kind of RAM is
in use is not all that exciting, but in routers that use some kind of
tree search, you can find all manner of SRAM and DRAM.

There has been some mention about TCAM being good at ACL matching.  It
can take a whole lot of ALU operations and RAM accessing to figure out
if a given packet should pass an ACL or not, and this is especially
true if you have those long ACLs blocking or allowing a ton of TCP
ports, etc.  At some point, it still becomes cheaper to implement ACL
with an ALU and RAM than with a TCAM.

The reason vendors do not want to do this is the TCAM can evaluate a
very large ACL in one step, while a ALU+RAM might be more
power-efficient, if you have a ACL with hundreds of entries, it will
take a long time to process packets, and you will not have wire speed
performance anymore, on packets trying to compare against that big
ACL.  Predictable performance is important and it is a lot easier to
predict the performance of a CAM/TCAM (because it is simple) than of
other methods.  From the operator's perspective, you don't want to
hear that you might lose wire speed forwarding if you have more than
17 ACL entries unless the optimizer figures out a clever way to
install them into the memory in which case 80 entries might work just
fine.  You just want your ACLs to work.

Of course, Juniper does do ACL with ALU+RAM in most boxes, and so you
can indeed create this problem for yourself.  This is often not
obvious until you have a few millions PPS passing through a filter
that it cannot optimize into anything clever.

It is nice to understand how your routers work at a deeper level.
More often than not, though, all it will do is make you wonder how a
given product ever shipped or make you angry that you can't just get
an MPLS P box for the same price as an Ethernet switch.  :-)

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] what happens in JUNOS when interface is disabled/enabled

[Jeff Wheeler]

On Sun, Oct 2, 2011 at 9:56 PM, Tim Harman t...@muppetz.com wrote:
 Reminded me of the old days (or maybe still modern times, I wouldn't know)
 on a Cisco box where no ip cef cr ip cef would usually fix these sorts
 of problems.

It feels like we are having progressively more CEF problems with
Juniper boxes.  It would be really great if Juniper provided some
commands with the intent of bringing the PFE back into sync with what
the control-plane says should be in it, in a low-impact manner that
does not involve bringing interfaces down and up, bouncing fabric
modules, literally or effectively rebooting, etc.

Of course I would like to have fewer malfunctions / bugs, but I can
live with them more easily if getting the box back to a
correctly-functioning state is a low-impact operation.  I don't think
Juniper really gets this.  Bugs happen, that's life; but if the vendor
provides a relatively pain-free way to remedy the situation, it can
save us from tough choices like, do we reboot a box at 2pm to restore
correct function, or live with some serious headache and customer
gripe until 2am when a reload will cause less collateral damage to
unaffected customers or services?

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] M10i JUNOS Upgrade

[Jeff Wheeler]

On Wed, Sep 28, 2011 at 2:43 PM, Jake Jake 2012j...@gmail.com wrote:
 I am looking at upgrading the JUNOS on our M10i router. Current JUNOS
 platform is 6.3R1.3 . The router has redundant routing Engine  RE-5.0 with
 512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can any
 one suggest on if I can upgrade the router to 11.1R5.4 with the current
 hardware specification .  Please advise on if a direct upgrade can be done
 as well from 6.3 to 11.1.

If you have DFZ routes you should upgrade the RAM to 768MB, or
alternatively, replace the router or buy more modern routing engines.
There is a big jump in memory usage in 8.x and if you have only 512MB
and are carrying Internet BGP routes, you will be using the swap and
the RE will perform badly.

No, you cannot do a direct upgrade from 6.3 to 11.1.  You'll be going
through quite a few intermediate software versions to do that.  It
will be easier to simply reinstall Junos from an 11.1 install-media
disk and then load your configuration.

 Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing the
 combination of RAM used ..i.e 256+256MB or a single 512MB RAM.

I don't think the RE-5.0 will recognize more than 256MB per slot.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Interesting EX4200 gotcha and resolution

[Jeff Wheeler]

On Mon, Sep 26, 2011 at 1:39 PM, Brent Jones br...@servuhome.net wrote:
 Did you observe any strange entries in /var/log/shadow when these events 
 occur?
 I've had similar issues, where some EX4200's in a VC lose the ARP
 table, and traffic cannot transit the switch to another switch (if the
 traffic must go through that VCP).
 JTAC was unable to find any root cause, but there were number errors
 in /var/log/shadow about the ASIC forwarding table didn't match what
 was in software/memory

No, the only entries present in /var/log/shadow.log are the mysterious
Non RTG error messages that it logs every ~5.5 minutes.

In this instance, the VC contains two EX4200-48T and both switches
have identical halp-nh arp-table data, with both missing the same
entries.

What the root cause is, who knows; but if Juniper wanted to provide me
with a fix they could make clear arp actually clear the arp
entries.  This happens so rarely that it's only a problem because the
obvious fix that NOC guys try before escalating does not work.

I am hoping a future instance of this problem will get escalated to me
so I can try installing a static ARP entry with a different MAC and
then removing it, which should correct the problem without impacting
other machines on the subnet.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Interesting EX4200 gotcha and resolution

[Jeff Wheeler]

A colleague pointed out recently that some of the gotchas and fixes we
run into are interesting to others, so in that spirit, I have another
one to share with you today.

In this case, a malfunctioning EX4200 (10.4R4.5) appears to have valid
ARP entries for a few boxes, but when you try to ping them, etc. the
boxes do not get any traffic.  In fact, they receive nothing from the
switch except ARP who-has.  They respond, and upon clearing the ARP
entries from the EX4200, that process repeats.

Upon investigating the PFE data, I found that the halp-nh arp-table
was missing these ARP entries, even though they were present in the
Junos CLI and indeed the correct MAC address is referenced in the PFE
route table.  See below:

PFEM0(vty)# show route ip prefix 192.0.2.39 detail

IPv4 Route Table 0, default.0, 0x0:
Destination   NH IP Addr  Type NH ID Interface
  ---  - -
192.0.2.39   192.0.2.39  Unicast  2933 RT-ifl
197 vlan.1122 ifl 197

  RT flags: 0x, Ignore: 0x, COS index: 0
  DCU id: 0, SCU id: 0,  RPF ifl list id: 0



PFEM0(vty)# show nh id 2933 detail
   ID  Type  InterfaceNext Hop AddrProtocol
Encap MTU   Flags  PFE internal Flags
-    -  ---  --
    --  
 2933   Unicast  vlan.1122  192.0.2.39IPv4
Ethernet 0  0x 0x

   Flags: 2   nh_idx:  3
   CMD:   Route   Arp Idx:  1341
   MTU Idx:   2   Num Tags:0
   Upd Cnt:   1   Tun Strt:False
   Chain_nh   3484:
   Hw install:1
   Mac: 00 0e 0c a2 2d dc



PFEM0(vty)# show halp-nh arp-table
Device: 0
...hundreds and hundreds of lines...
  ArpEntry Idx 1340 : 00:15:17:6b:a9:7c
  ArpEntry Idx 1342 : 00:25:90:2c:41:e5
...hundreds more, but where is Idx 1341?!


Our fix is to remove 192.0.2.1/27 from the vlan.1122 configuration,
commit, and then rollback.  This is obviously not good.  I would like
to have tried installing a different ARP entry (by configuring this IP
address on another machine) but I have not had an opportunity to test
this yet.

The reason this is happening is the ASIC vendor format ARP table in
the PFE memory is abstracted from the Juniper ARP table, as I
understand.  It appears that simply refreshing the Juniper ARP table
with an identical entry does not cause a missing entry to be put into
the forwarding table.

I would love to be able to reproduce this, but with hundreds to a few
thousand machines each on many EX4200 stacks, it happens very rarely.
I only mention it because clear arp from the CLI does not work, so
this problem gets escalated until it reaches someone brave enough to
temporarily break some unaffected boxes to fix a broken one.  It would
be nice, though, if clear arp actually worked right.

If you encounter this problem and do something different, I would be
very interested to hear from you!
-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks

[Jeff Wheeler]

On Wed, Aug 31, 2011 at 2:04 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote:
 On Wed, Aug 31, 2011 at 3:49 PM, Chris Kawchuk juniperd...@gmail.com wrote:
 I don't want to make a giant vlan and put all the devices loopbacks in it, 
 one for
 scalability issues but also for broadcast related issues.

 But is it really an unscalable solution?
 Is it really going to suffer from broadcast related issues?

My argument against that design is simple: spanning-tree.  Why expose
yourself to one more thing that can, and sometimes does, malfunction?
We live in a world where multi-vendor L3VPN works pretty good, but
spanning-tree is apparently really hard to figure out, especially for
some vendors who are particularly good at routing and not so
experienced at Ethernet bridging.

There are plenty of other good reasons not to do a big vlan for all
the routers in that area, but the reason above should be good enough
for anyone.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RE-600 SOLID STATE DRIVE NOT RECOGNIZED

[Jeff Wheeler]

On Thu, Aug 25, 2011 at 3:00 PM, Mario Andres Rueda Jaimes
maeve2...@gmail.com wrote:
 I'm trying to install a 8GB SSD in a RE-600 with compact flash of 2G but

 Anybody has performed this before or has suggestions ?

We use this model drive, a 16GB with old-style parallel IDE connector:
http://www.amazon.com/gp/product/B000T9S52W/ref=oss_product

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] M20 SSB E Memory seller required

[Jeff Wheeler]

On Wed, Aug 10, 2011 at 2:03 PM, Chris Cappuccio ch...@nmedia.net wrote:
 (Of course if I installed an M20 with an SSB-E, i'd put 128MB of DRAM in it 
 just on principle)

Unless I was very budget-constrained or needed a lot of P-type slots
for terminating DS3/OC3/OC12 interfaces, I would try pretty hard to
get a new router instead of throw more time and money at an M20.  I
thought this might be worth mentioning, as the platform is certainly
dated.  If you have enough routes in PFE that you need the SSB-E-16,
your control-plane is probably not very fast.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Junos Pulse / SRX240 problems

[Jeff Wheeler]

I have a very simple VPN configuration for a non-uptime-critical
service, with an SRX240H and Dynamic VPN client licenses.  This worked
fine with Junos 10.4R4.5 (JTAC recommended release) and the Juniper
Access Manager client.  However, Dynamic VPN sessions were becoming
stuck, and hours or days after a user had disconnected, they would
still appear in `show security ike ...` and still consume Dynamic VPN
licenses as reported by `show system licenses`.  The same users were
shown many times, etc.

I have tried 11.1R3.5 and it has solved the stuck IKE associations /
license exhaustion issue, but the Junos Pulse client is not working
well.  JAM does work fine, but the web front-end installs Pulse for
end-users now.  From my test machine, I can sometimes connect the VPN
on the first or second try, but usually have to enter login
credentials at least twice.  Where it gets problematic is if I
disconnect and later attempt to reconnect, I might enter my login and
click continue 50 times before the VPN session is established, if it
ever works at all.  Restarting Pulse does not seem helpful, but
rebooting the PC does.  I have not tried rebooting the SRX, but I find
no entries cleared when issuing `clear security dynamic-vpn all` and
that does not appear to influence the problem.

Before someone asks, since this works perfectly with the JAM client, I
do not think the SRX configuration is any issue.  This config is as
simple as can be, without even a RADIUS server yet.

My impression right now is that the Pulse client is too buggy to
deploy and I should downgrade back to 10.4R4.5 so users will receive
Juniper Access Manager instead.  I have read a few similar opinions on
the Juniper forums.  I would appreciate any thoughts you guys have.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Back-reference in JunOS regular expressions

[Jeff Wheeler]

On Thu, Jul 14, 2011 at 3:00 AM, Jonathan Lassoff j...@thejof.com wrote:
 Honestly, what's the use case of a backreference for an AS path?

If you have that feature, you can detect as-path prepends and use that
to influence your path selection.

http://juniper.cluepon.net/ER_Detect_AS-PATH_prepends

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX loopback filter and monitor traffic

[Jeff Wheeler]

On Thu, Jun 16, 2011 at 10:53 AM, Clarke Morledge chm...@wm.edu wrote:
 However, if I do a monitor traffic on the loopback interface itself, I see
 nothing:

I like to think of monitor traffic as something which is nice when
it works the way I hope it will, but isn't something to really get
concerned about when it doesn't behave as expected.  If you really
need detailed information to debug a problem, mirroring traffic to an
interface (or a GRE tunnel, etc.) and doing packet capture on a PC is
more reliable than betting on the output of monitor traffic.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] bgp to ospf

[Jeff Wheeler]

On Thu, Jun 16, 2011 at 12:48 PM, Payam Chychi pchy...@gmail.com wrote:
 Were you able to figure this out?

I don't have lab gear to test this correctly, so please take my post with a
grain of salt.  Please excuse the use of gmail Rich Text to get a
fixed-width typeface in my composer:

  /\
  ||
ASBR1ABR5---ASBR3

ABR5 redistributes 192.0.2.0/24 into iBGP, but not into OSPF.
ASBR3 redistributes same /24 from BGP into OSPF as an E2 with set next-hop
to ABR5 loopback in the routing policy.
ASBR1 learns the E2 route and its RIB (and FIB) show a next-hop directly to
ABR5

However, in ASBR1 show ospf database external CLI output, the Fwd Adr is
0, not the ABR5 next-hop.

I am really not surprised by this, because the purpose of OSPF Forwarding
Address is, as expressly documented in relevant RFCs, for situations where
several routers are using a multi-access or broadcast media (frame-relay,
Ethernet, etc.) to reach an external neighbor, yet not all of these routers
have routing protocol sessions to same neighbor.  For example:

   AS16631
  |
  ==
||
  ASBR1ASBR2
||
   AR3  AR4

In this stick-figure, === might be Ethernet, ATM, Frame, smoke signals,
whatever.  What matters is you will have eBGP from ASBR1 to the external
neighbor AS16631, but not to ASBR2.  However, if you want ASBR2 to be
capable of routing traffic directly to AS16631 without sending it through
ASBR1, you can use OSPF External routes with Fwd Adr set to the next-hop
address of AS16631 (imagine that ASBR2 just doesn't have the capability of
speaking BGP.)

In fact, on Cisco IOS, the router will not let you accidentally send Fwd Adr
if you send these External routes also to AR3.  It will omit Fwd Adr and so
AR3 will utilize ASBR1 to reach the neighbor.  So Fwd Adr is only set on
LSAs flooded to the === interface.  Further, I do not believe ASBR2 would
preserve Fwd Adr when sending LSA to AR4.

As I mentioned, take my post with a grain of salt.  I may be incorrect here
about the actual functioning, as I have never, ever had reason to utilize
this in a practical network.  But if you do some reading, the intended
purpose of Fwd Adr is expressed above.  The original poster should not be
using it for what he wants to do (I don't think it will work), and should
instead utilize BGP or change his topology.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] some bugs to avoid

[Jeff Wheeler]

We have had our first instance of serious filesystem corruption on an
EX4200 running 10.3R1.9.  I am hopeful that the new-fangled stuff in
10.4 will stop these incidents from causing switches to reboot into an
un-usable state requiring a reinstall from USB. :-/

In other news, we also observed an M160 with two REs (one in the
process of upgrading from JUNOS 6.2) exhibit an interesting new
failure mode.  The second RE incorrectly reported its CPU Temperature
as about 800 million degrees, which caused the master RE's chassisd to
spawn children emitting warnings about 3 times each minute.
Unfortunately, chassisd was not wait(2)ing on these children after
they exited.  This produced additional console warnings about the
maximum number of processes for uid 0.  After about 15 minutes, there
were enough defunct children of chassisd that the kernel process
table was full, resulting in a kernel panic and automatic reboot.  We
had to remove the second routing engine to prevent it from happening a
second time.

IRB on MX80 10.4R4.5 appears badly broken, too.  Configuring a
bridge-domain with one untagged/access interface and one
dot1q-tagged sub-interface, plus an IRB interface for layer-3, is a
pretty good way to waste a couple hours troubleshooting the router.
It works fine most of the time, and all looks well in the PFE console;
but a few times per hour the Bridge-Domain simply stops forwarding any
traffic, while the IRB loses its ARP entries.  This fault sometimes
lasts long enough for BGP to drop.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Code upgrade to 10.4R4.5

[Jeff Wheeler]

On Wed, May 11, 2011 at 3:11 PM, Cyn D. cynthia_...@yahoo.ca wrote:
 Will this be a none (no config loaded at all) and all (if loaded then it is
 intact) situation? What I don't want to see is configuration loaded
 partially and the lines that are not compatible are missing. When you go

I have encountered quite a few upgrade problems where only part of the
configuration loaded.  Verify is by no means a fool-proof check, and
the fool in this case is not you, it's the developers.  For example,
an upgrade from EX4200 9.2(?) to 9.3(?) or there-abouts will break if
you have virtual-chassis { pre-provisioned; } configured, because the
syntax changes to preprovisioned (no hyphen), yet this is not caught
by verify.  The box will be unusable after it upgrades.  EX boxes,
and their spectacular upgrade failures, have justified my OOB
facilities many times over in the past couple of years.

Always have a rain plan.  OOB network, remote hands, let router be
down until you can dispatch an employee, whatever.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4200 LLDP issue with vlan-tagging

[Jeff Wheeler]

I find that EX4200 with interfaces configured with vlan-tagging and
layer-3 sub-interfaces, as opposed to family ethernet-switching and
routed VLAN interfaces, transmit LLDP frames differently.  I do not
think this is the correct behavior, but I would appreciate comments.

The interfaces configured as follows:
interface xe-1/1/1 {
  vlan-tagging;
  unit 3911 {
vlan-id 3911;
family inet {
  address 192.0.2.1/24;
}
  }
}
produces LLDP frames that appear like this:
08:39:23.892264 Out 00:19:e2:51:86:99  01:80:c2:00:00:0e, ethertype
802.1Q (0x8100), length 68: vlan 0, p 0, ethertype LLDP, LLDP,0

Notice the outer-ethertype 0x8100 rather than 0x88CC.  Surely this is
not correct.

Changing the configuration to something like:
interface xe-1/1/1 {
  unit 0 {
family ethernet-switching {
  port-mode trunk;
  vlan {
members 3911;
  }
}
  }
}
interface vlan.3911 {
  family inet {
address 192.0.2.1/24;
  }
}
vlan v3911 {
  vlan-id 3911;
  l3-interface vlan.3911;
}
produces LLDP frames which appear normal:
08:50:01.121422 Out 00:19:e2:51:86:bf  01:80:c2:00:00:0e, ethertype
LLDP (0x88cc), length 74: LLDP, name J3K3.1250RL, length 60

In the first case, my neighboring devices are dropping the LLDP
frames, and thus they do not learn about the advertising device.  In
the later case, everything works as expected.  With both
configurations, the EX4200 itself does detect the neighboring
LLDP-speakers correctly.

-- 
Jeff S Wheeler j...@inconcepts.biz
Sr Network Operator  /  Innovative Network Concepts

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp