Re: [j-nsp] Buffer Size

[Tore Anderson]

* Mark Tinka

> On 20/Apr/20 22:58, Mohammad Khalil wrote:
> 
>> Hi all
>> Am trying to conduct a comparison for campus refresh , my end customer is
>> deeply interested in deep details.
>> He is interested to know the buffer size of Juniper switches (EX series)
>> and I could not find such a piece of information in any place.
>>
>> If anyone has an idea it would be appreciated.
> 
> Atrocious - on the 2 we ran; EX4550 and EX4600.
> 
> We dumped it and went with Arista.

The vendor is usually irrelevant. Implying that Arista have better/bigger 
buffers than Juniper is misleading - it depends on the ASIC used. For example, 
the Juniper EX4600 and the Arista 7050X both contain a TD2 ASIC, so they both 
have a 12 MB large buffer.

https://people.ucsc.edu/~warner/buffer.html is an excellent resource.

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

Re: [j-nsp] Internet monitoring in case of general issues

[Tore Anderson]

* james list

> The question: once you notice issues on internet and your upstreams are
> fine, what instrument or service or commands or web site do you use to try
> to find out where is the problem and who is experiencing the problem (ie a
> tier1 carrier)?

We find that being an NLNOG RING (https://ring.nlnog.net/) participant is very 
useful in diagnosing these kind of issues. We can start pings or traceroutes 
towards towards our own network from 500+ locations all over the globe with a 
single command, for example. Furthermore, there is a tool (ring-sqa) that does 
pretty much this continuously and alerts us if a partial outage is detected.

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

[j-nsp] aes-gcm SSH ciphers broken in JunOS >=12.3R12-S13.1

[Tore Anderson]

Hello,

After upgrading a few old EX switches from 12.3R12-S12 to 12.3R12-S14 I found 
that I could no longer log in using SSH.

When the login attempt is made, the switch logs:

sshd[1521]: fatal: ssh_dispatch_run_fatal: Connection to : 
unexpected internal error [preauth]

The reason appears to be the cipher used.

The SSH server in JunOS 12.3R12-S12 advertises support for the following 
ciphers:

debug2: ciphers ctos: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se

While 12.3R12-S14 advertises:

debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se

Note the addition of aes128-...@openssh.com and aes256-...@openssh.com. These 
are advertised by 12.3R12-S13.1 as well.

The Fedora OpenSSH client will use aes256-...@openssh.com by default when 
supported by the server, and this fails with the above error message. So does 
aes128-...@openssh.com.

Explicitly selecting another cipher works, e.g.:

ssh -o Ciphers=chacha20-poly1...@openssh.com 

Didn't find any KB article about this issue, so I thought I'd post here in case 
any Juniper employee would like to report it internally, as I'm guessing others 
will run into the same issue eventually. (My old switches are long out of 
support, so I can't open a JTAC case.)

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

Re: [j-nsp] GRE on MX960

[Tore Anderson]

* sth...@nethelp.no

> "Ethernet and tunnel interfaces cannot coexist on the same Packet
> Forwarding Engine of a 10-Gigabit Ethernet 4-port DPC."
> 
> I *thought* I remembered that you would disable just one of the 10G
> ports.

You remember correctly. There are four PFEs on that DPC, one per port.

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

Re: [j-nsp] Configuration database stuck with mgd crashing

[Tore Anderson]

* Aaron Gould

> Maybe "commit full"

Thank you for the suggestion! I was however unable to get into configure
mode in the first place, so I couldn't issue any kind of "commit". 

Luis's suggestion of «mgd -I» from a root shell did the trick, though.

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

[j-nsp] Configuration database stuck with mgd crashing

[Tore Anderson]

One of my routers (a MX240 running 16.1R6-S2.3) have gotten stuck in a
state where it believes the configuration database has been modified,
and if I try to configure it anyway, mgd crashes and is respawned:

tore@router> configure exclusive 
error: configuration database modified

tore@router> configure private  
error: shared configuration database modified

tore@router> configure 
Entering configuration mode

Message from syslogd@router at Aug 31 13:38:57  ...
router mgd[20554]: ../../../../../../src/ui/lib/access/model.c:238: insist 
'model > 0 && model <= MODEL_MAX' failed

error: session failure: unexpected termination
error: remote side unexpectedly closed connection
Connection to router closed.

At this point PID 20554 goes away from the process list. However if I
log back in I can see a «ghost» reference to it:

router> configure exclusive 
Users currently editing the configuration:
  tore terminal pts/0 (pid 20554) on since 2018-08-31 13:38:57 CEST, idle 
00:01:25
error: configuration database modified

"request system logout user tore all" will get rid of that reference,
but the fundamental defective state of the configuration database
remains.

Any suggestions on how to correct this problem without requiring
any downtime? I have of course tried "restart management", but 
that didn't help. NETCONF is impacted too.

Tore


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

Re: [j-nsp] Force a reboot from the serial console?

[Tore Anderson]

* Saku Ytti

> I hope there are plans to introduce lights out port in future.

Indeed. I can't imagine adding a standard BMC with serial over LAN and
chassis control features can add many much to the overall manufacturing
cost, so it is beyond me why it's not standard on networking equipment
as well. Pretty much every server produced in the last decade includes a
BMC and there's a very good reason why.

I really detest having to deal with two different management cables
(Ethernet + RS232) for each of my network devices, especially
considering that the end result is so clearly inferior to the single
BMC-connected Ethernet cable you'd use in a regular server. We don't buy
servers without BMCs. Period. So for me, having a BMC would be an
important differentiator when making procurement decisions for
networking equipment as well.

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

[j-nsp] RE-S-1300 - memory upgrade possible?

[Tore Anderson]

I've got a few MX-es with the RE-S-1300 in my network. While out of
support, they work just fine, except for the fact that the 2 GB of
memory is getting rather tight.

Hoping to squeeze some a little bit of extra life out of those boxes, I
was wondering if anyone on the list tried to replace whatever DIMMs are
found on the RE-S-1300 in order to double up the total memory to 4 GB?
If so, any success?

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

Re: [j-nsp] Generating routes from inactive/hidden contributors

[Tore Anderson]

Hi,

* adamv0...@netconsultings.com

> Interesting, 
> There appears to be no cmd to override the default, "contributing route has
> to be active", requirement. (the "from state inactive" attachment point is
> only the export policy). 
> I'm just thinking whether it's not working simply because the inactive
> routes wouldn't be advertised anyways -so why to bother aggregating them
> right? 

True, but this is a generated route, not an aggregated route. They're
quite similar, but the generated routes can have next-hops (copied from
a contributing route), which means you don't really need the
contributing routes themselves to be active or even non-hidden to
actually forward packets somewhere useful.

Aggregated routes are on the other hand discard only, so then you need
the more-specific contributing routes with their next-hops to avoid
blackholing traffic.

(AIUI, anyway.)

> But maybe if you enable "advertise-inactive" towards your iBGP -maybe
> then the aggregation starts to work? 

Perhaps, but if both the generated route and its contributors are
indeed inactive in the RIB and thus not found in the FIB, then I don't
think the router would be able to forward the packets it attracts to
where it should.

> Alternatively, I'm thinking of something along the lines of making the
> prefixes active (to allow the aggregate to be advertised), but use
> them only for routing not for forwarding -so that FIB on a local
> router is not skewed.

Yep, something like that would probably do the trick. I was hoping to
keep them out of the RIB in the first place though, to avoid having to
explicitly filter them on export to the FIB and iBGP peers, but maybe
there's no way around it.

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

[j-nsp] Generating routes from inactive/hidden contributors

[Tore Anderson]

Hi,

I'm looking to generate a route, and do so even if the contributing
routes are inactive or hidden.

The use case is to receive a full feed from an upstream provider and
generate a default route pointing to that provider IFF I've received at
least one route from them that proves that they are in turn receiving
routes from their upstream(s). The point of having this generated
default route is of course to be able to optimise away all the (now
redundant) contributing routes.

I've tried the following as a proof of concept:

set routing-options rib inet.0 generate route 1.1.0.0/19 policy testpol
set policy-options policy-statement testpol term 1 from as-path teliatest
set policy-options policy-statement testpol term 1 then accept
set policy-options policy-statement testpol term 2 then reject
set policy-options as-path teliatest .*1299.*

While I do have contributing routes within 1.1.0.0/19 matching the
as-path, they are all inactive, and thus the generated route does not
go active either. Furthermore, it makes no difference to add:

set policy-options policy-statement testpol term 1 from state inactive

I also get the same results if I filter out the contributing routes in
my upstream's import policy (i.e., making them hidden rather than
inactive).

Anyone know of a clever trick to get the behaviour I'd like?

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

Re: [j-nsp] juniper router reccomendations

[Tore Anderson]

* Mike 

>  Im in a colo in one location (A), and have a private 1G ethernet
> to another geographically distant colo (B). Each colo has a different
> ip transit provider and I am advertising my own prefixes. At colo A I 
> receive a subset of Internet routes internal to that provider, while
> at colo B I get full tables. Id like to like to exchange routes
> between Colo A & B for better routing as well as for failover in the
> event I lose ip transit at either location.

You don't need full tables for failover, getting a default from each
provider will do fine for that purpose.

However, what you could do with a cheaper device with limited FIB space
is to take full feeds but be selective about which routes you download
into the FIB. In JUNOS, you can control that with "set routing-options
forwarding table export FOO".

The assumption here is that you really don't care which transit provider
is used for the odd packet destined for Timbuktu. So you can let those
follow a default route to the colo-local provider, instead of wasting
valuable FIB space on them.

The routes or ASNs you do care about (i.e., the ones where you want
nodes in colo A to cross your backbone link to colo B or vice versa,
instead of exiting through the local transit), those you can
selectively ensure get installed into the FIB. You could do so with
static config, or you with a little more effort use flow telemetry to
dynamically figure out, e.g., your top-10k destination routes and
install those.

If you insist on a router with a big FIB, expect to pay more for it,
much much more. Keep in mind, though, that in all likelihood you will
probably (almost) never send any packets to 95%+ of the prefixes that
will be occupying your big and expensive FIB.

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

Re: [j-nsp] juniper router reccomendations

[Tore Anderson]

* Mike 

>  I am a network operator and have been firmly in the cisco camp
> for many years but the price for 10g ports simply seems too
> unreasonably high across the whole product line and I'm wondering if
> Juniper might be a better solution for me.
> 
>  In fact, have a need for a new edge router today and the job
> would simply be full bgp tables taken on a 10g port, filtering/rate
> limiting DDoS type traffic (for us, inbound dns > 15mbps = attack,
> for example) and then forwarding the remainder to a 1Gbps uplink
> behind the router. How much of a juniper box do I need to accomplish
> that and what models/licenses would I need to accomplish this?

Hi Mike,

Ask yourself if you really, *really*, need those full BGP tables in your
FIB. If you can do without them and install a default instead, you'll
find a plethora of low-cost devices that'll do the job. You could even
pick up a second-hand EX4200 with 2x10GE for US$500 or so, it'll manage.

Note that you could still receive the full tables from your upstream
provider and keep them in your RIB for your amusement. It's the need to
install all of them to the FIB that's going to cost you dearly.

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

Re: [j-nsp] How to catch invalid value/option for a command in SLAX script?

[Tore Anderson]

* Phil Shafer 

> But the newlines are my fault.  The initial XML output for JUNOS
> generated newlines after each tag open/close/data call to ease
> debugging for developers, and also because I thought it would make
> the XML->text renderer in the CLI easier.  By the time I realized
> the latter was false, the former was shipping.  So XML output from
> JUNOS looked like:
> 
> 
> data
> 
> 
> which means that leading and trailing newlines are present on some
> data fields.  It's been corrected in many places, and some libraries
> have options to automatically remove them.

Ah, so you're the one to blame for the mounds of torn-out hair around my
desk... ;-)

There are more of these yet to be fixed, unfortunately. For example:

$ echo '' | ssh -s lab-ex4200 netconf
[...]
http://xml.juniper.net/junos/15.1R4/junos;>
http://xml.juniper.net/junos/15.1R4/junos-interface; 
junos:style="normal">


ge-0/0/0

[...]

This in turn means that XPath expressions such as
«/physical-interface[name="ge-0/0/0"]» don't work, which is a _major_
pain in the arse.

http://www.juniper.net/documentation/en_US/junos15.1/topics/task/operational/netconf-operational-request-output-format.html
states that «the NETCONF server returns the information in XML-tagged
format, which is identical to the output displayed in the CLI when you
include the | display xml option after the operational mode command»,
which is simply not true. Compare with the above output:

$ ssh lab-ex4200 'show interfaces | display xml'
http://xml.juniper.net/junos/15.1R4/junos;>
http://xml.juniper.net/junos/15.1R4/junos-interface; 
junos:style="normal">

ge-0/0/0
[...]

There's also something fishy going on with whitespace magically
appearing inside  tags. I'll demonstrate. First I add a
comment to the config:

$ cat << EOF | ssh lab-ex4200 -s netconf
> 
> 
> 
> 
> /* This is a multi-line
> * comment whose lines are
> * NOT indented in any way */
> 
> 
> 
> 
> 
> ]]>]]>
> EOF

Fetching this comment back via NetConf works as expected:

$ echo '' | ssh lab-ex4200 -s netconf
[...]
/* This is a multi-line
* comment whose lines are
* NOT indented in any way */

Fetching it via CLI and «| display xml» on the other hand:

$ ssh lab-ex4200 'show configuration | display xml'
[...]
/* This is a multi-line
* comment whose lines are
* NOT indented in any way */
 wtf?

I tried my luck with JTAC on these issues in case 2015-1202-0037 last
year, but that didn't go anywhere useful. Maybe you can open an
internal bug issue or something instead and hopefully these issues will
get fixed eventually.

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

Re: [j-nsp] protect ssh and telnet

[Tore Anderson]

* Saku Ytti

> If you want to do this right today, the correct way is to extract
> public key in secure manner (What is secure? OOB not really, but maybe
> human on-site) and store them in your jump box for user-wide
> consumption, and raise alarm if host keys have changed. So who ever is
> physically installing RE, should also make sure hostkeys are updated
> securely in centralised location.
> 
> I'm sure someone out there does this, but I'm going to say that at
> least 99% of user-base (All vendors) just accept any key always.

Speaking only for myself, I'd accept server key change only if it's a
device that is known to have been recently replaced/zeroized/etc. I'd
*never* accept a key changing without that being expected for some
reason known in advance.

I'll also accept unknown keys when accessing devices recently added to
the network.

These corner cases both give a small opportunity for a successful MitM
attack, but I must admit I sleep well at night anyway.

> Making SSH really no safer than Telnet.

That's not really true even if you blindly accept any changed/unknown
SSH key, because telnet will leak information like login credentials in
cleartext to any passive listener while mounting a successful attack on
SSH requires MitM capability. That's more difficult to pull off. Also,
if you're using SSH keys your login credentials won't leak even if you
are successfully MitMed.

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

Re: [j-nsp] Unwanted newline characters in Netconf XML

[Tore Anderson]

Hi Dave,

* Dave Bell 

> It certainly looks like a bug to me. I've tested it in our lab on an
> MX running 12.3R8, and get the same problem as you.
> 
> Interestingly this conflicts with their documentation:
> "The NETCONF server returns the information in XML-tagged format,
> which is identical to the output displayed in the CLI when you include
> the | display xml option after the operational mode command."
> http://www.juniper.net/documentation/en_US/junos13.2/topics/task/operational/netconf-operational-request-output-format.html
> 
> Clearly this is not identical!

Thanks for this pointer. I think I'll have to go to JTAC with this one
and references like these does help (in case they try to claim it's
working as intended).

> Have you tried upgrading to a later version of JunOS?

Tried now. Same behaviour in 15.1R2.

> With actually no information about what you are actually trying to do,
> I don't see there being a massive issue with stripping out new lines.
> I can't think of anything other than comments that might allow a line
> break.

Yeah, if  is the only thing that can contain newlines,
then I'd be fine with a hack like «$xml =~ s/\n//mg» before feeding the
output to the XML parser since I'm not interested in comments anyway.

> In fact I've just been playing with trying to put a line break in a
> comment, and that doesn't even seem to work!

Works fine for me? Even in JUNOS versions as old as 11.4. Try:

{master:1}[edit]
tore@lab-ex4200# load merge terminal
[Type ^D at a new line to end input]
/* This is a
 * multi-line
 * comment.
 */
protocols{} 
[edit]
  'protocols'
warning: statement has no contents; ignored
load complete

{master:1}[edit]
tore@lab-ex4200# show | compare 
[edit]
+  /* This is a
+   * multi-line
+   * comment.
+   */
   protocols { ... }

{master:1}[edit]
tore@lab-ex4200# show | display xml | find junos:comment   
/* This is a
 * multi-line
 * comment.
 */


Some whitespace has appeared out of nowhere in this XML output too...

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

[j-nsp] Unwanted newline characters in Netconf XML

[Tore Anderson]

I'm assuming this must be a JUNOS bug?

$ echo '' | ssh -s lab-ex netconf
[...]
http://xml.juniper.net/junos/12.3R10/junos;>
http://xml.juniper.net/junos/12.3R10/junos-interface; 
junos:style="normal">


ge-0/0/0

[...]

The newline characters immediately following  and preceeding
 becomes part of the node value - that is, the interface name
becomes "\nge-0/0/0\n" instead of "ge-0/0/0". (This does not happen
only with interface names, pretty much any value is wrapped in these
newline characters.)

This in turn makes using XPath with expressions such as for example
«//physical-interface[name="ge-0/0/0"]» to fail miserably.

A simple workaround is to strip all the newline characters from the XML
string before feeding it to the XML parser. But that of course will
also break nodes may actually contain newlines -  comes
to mind, are there others?

I'm far from being an expert on XML or Netconf for that matter, so I'm
wondering if anyone else on the list ran into this issue (surely yes?)
and if so if there's a better way to deal with it?

Interestingly, running "show interfaces | display xml" from the JUNOS
shell looks much better:

http://xml.juniper.net/junos/12.3R10/junos;>
http://xml.juniper.net/junos/12.3R10/junos-interface; 
junos:style="normal">

ge-0/0/0
[...]

If I could only convince the Netconf service to give me its replay
formatted in this way instead everything would have worked well.

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

Re: [j-nsp] Counter on subinterface on EX

[Tore Anderson]

* Raphael Mazelier r...@futomaki.net

 Have you notive/hit some performance problems with this config ?

No.

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

Re: [j-nsp] Counter on subinterface on EX

[Tore Anderson]

* Raphael Mazelier r...@futomaki.net

 I've just realized there is another pretting annoying problem with EX 
 series. It seems that is was not possible to count passing in 
 subinterface (or vlan interface) on EX.

It's quite annoying indeed.

 I wonder if someone ever faced this problem, and if there is some king 
 of workarround. The goal is to monitoring traffic, and billing.

The way I do it is to create input and output firewall filters for each
configured family on the interface with a single term, which just does
count and accept. Then I poll those firewall counters.

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

Re: [j-nsp] Stable JunOS for MX80

[Tore Anderson]

* thiyagarajan b bn.thiyagara...@gmail.com

 Request to suggest stable JunOS for MX 80 with 2GB DRAM and Flash.

See http://kb.juniper.net/InfoCenter/index?page=contentid=KB21476

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

Re: [j-nsp] info VC QFX

[Tore Anderson]

* james list jameslis...@gmail.com

 on QFX VC is there a way to configure VME interface to respond on each
 module of the VC instead to be redirected on the master RE ?
 
 If yes a little configuration example is appreciated.

I haven't tried QFX, but on EX you can use apply-groups to match
individual members in the VC, and set up different addressing on each
member's me0 interface (note: you will *not* be using vme).

See http://kb.juniper.net/InfoCenter/index?page=contentid=KB15556

Try it and let the list know if it works on QFX too?

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

Re: [j-nsp] EX4500 SFP+ laser lit when interface is admin down and vice versa

[Tore Anderson]

* Jed Laundry

 I haven't seen this particular issue, and I'm not sure about the
 EX4500, but on a EX4550 you can:
 
  start shell user root
 
 % lcdd 0 chassism
 
 chassism0#xcvr enable ge-0/0/30
 devNum:0, portNum:49
 
 HERE BE DRAGONS: any errors/warnings in chassism (i.e., finger
 fudges) will cause the device to kernel panic and reboot... Been
 there, done that...

So, for the archive, I tried this in a maintenance window. No panics or
reboots, but it turned out that chassism was confused in the same way
the rest of the switch was, in other words: xcvr enable actually
switched off the Tx laser, while xcvr disable switched it on. So I
suppose that doing xcvr disable would have solved my issue in the
short term and would have saved me a trip to the colo to move the link
to an unaffected port.

Only after rebooting the switch (as part of an NSSU to 12.3R9) did the
port start to work normally again.

Thanks for the tip, Jed!

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

Re: [j-nsp] Recommended Junos version for EX-4500 virtual chassis

[Tore Anderson]

* Mark Tinka

 On 19/Mar/15 15:17, Scott Granados wrote:
  Ok, I’m running 13.2X51-D26.2 now and can’t find out much about
  this code other than that’s what was installed when they shipped
  the units.
 
  I’m thinking going to the recommended version makes the most
  sense.  Thank you and the others who have responded, most helpful.
 
 This code base for the EX4500/4550 is useless for a standalone
 system. I tried it, and a lot of features don't work even though
 commands exist.
 
 My guess is this code base is needed if an EX switch is part of a 
 QFabric system.

Or perhaps to get MACsec support. At least if you select the MacSec
Enabled option in the Type / OS drop-down at the download page, the
only versions you will be able to select 13.2X50 (which is already EOL,
FWIW), 13.2X51, and 14.1X53. (Perhaps QFabric depends on MACsec?)

In any case I'd certainly stay on 12.3 on the EX for now unless I had a
extremely compelling reason not to...

As an aside, it makes me slightly concerned that there's only nine
months left before 12.3 reaches the EOE date, and yet there's no new
EEOL release available for the EX. I prefer to let new EEOL releases
mature for at least a year before upgrading to them, but it seems that
in order to do so this time around I'll have to stay on 12.3 past its
EOE (and possibly EOL) date. I'm not terribly happy about that either...

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

Re: [j-nsp] Proxmox with Multicast Juniper EX

[Tore Anderson]

* Jeff Meyers

 I am mostly confused why the packets passing the core makes a
 difference at all. For my understanding, igmp-snooping inspects the
 communication and passes multicast traffic to exactly those who shall
 receive it. Why isn't this working? I read that this requires an icmp
 querier. Would it help to configure that querier on one of the
 routers (it's two routers because of VRRP)? Can anyone explain why it
 is working on a local switch but not anymore as soon as a 2nd switch
 is involved in the path?

You'll need a querier in your network if you want IGMP snooping to
work, otherwise the switch will remove the host interfaces from their
subscribed multicast groups after a while. The querier can be one of
the switches (you must configure a l3-interface on the VLAN), it
doesn't have to be the upstream routers.

Other than that there's too little information in your message for me
to say exactly what your problem is. I suggest you play around with the
show igmp-snooping ... detail commands on your switches to find out
exactly where the packets gets dropped. Also note that multicast
packets destined for 224.0.0.0/24 are treated differently from other
multicast destinations, so this is important information as well.

https://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/igmp-snooping-ex-series-overview.html

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

Re: [j-nsp] Recommended Junos version for EX-4500 virtual chassis

[Tore Anderson]

* Scott Granados

 Hi, I’m wondering what people recommend for a software release for
 the EX 4500 switch in a virtual chassis configuration.  I noted that
 there is 13.2 code installed in my cluster now but the recommended
 version on the web site is 12.3R8 which obviously doesn’t match.
[..]
 I’m thinking going to the recommended version makes the most sense.
 Thank you and the others who have responded, most helpful.

FWIW, the JTAC recommendation for the EX4500 was just updated to 12.3R9.

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

Re: [j-nsp] Proxmox with Multicast Juniper EX

[Tore Anderson]

* Tore Anderson

 * Jeff Meyers
 
  I am mostly confused why the packets passing the core makes a
  difference at all. For my understanding, igmp-snooping inspects the
  communication and passes multicast traffic to exactly those who shall
  receive it. Why isn't this working? I read that this requires an icmp
  querier. Would it help to configure that querier on one of the
  routers (it's two routers because of VRRP)? Can anyone explain why it
  is working on a local switch but not anymore as soon as a 2nd switch
  is involved in the path?
 
 You'll need a querier in your network if you want IGMP snooping to
 work, otherwise the switch will remove the host interfaces from their
 subscribed multicast groups after a while. The querier can be one of
 the switches (you must configure a l3-interface on the VLAN), it
 doesn't have to be the upstream routers.
 
 Other than that there's too little information in your message for me
 to say exactly what your problem is.

After thinking a bit more about it I think the behaviour you're
observing makes perfect sense. When you connect your hosts to one of the
EX4200s, they'll send an IGMP membership report to join the multicast
group in question. The EX4200's IGMP snooping picks up on this, and
multicast communication the two hosts then works (but probably just for
a limited amount of time, as there's no querier that would normally
cause the hosts to renew their membership in the group, so their
membership will likely just timeout eventually).

However these intial IGMP membership reports are not forwarded to the
EX4550, as it is not a multicast-router interface (from the EX4200s'
points of view, at least). So the EX4550 won't be able to learn of the
existence of the multicast group at all. Also, since the uplink to the
EX4550 isn't a multicast-router interface, nor a regular host interface
that's a member of the multicast group, packets destined for the
multicast group won't be forwarded to the EX4550 either.

You really need a multicast querier in the network for this to work...

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

Re: [j-nsp] Recommended Junos version for EX-4500 virtual chassis

[Tore Anderson]

* Scott Granados sc...@granados-llc.net

 Hi, I’m wondering what people recommend for a software release for
 the EX 4500 switch in a virtual chassis configuration.  I noted that
 there is 13.2 code installed in my cluster now but the recommended
 version on the web site is 12.3R8 which obviously doesn’t match.
 What are people using and or how should I reconcile the difference
 and find the right train to follow?  Any pointers would be most
 appreciated.

We've got a couple of dual-node EX4500 VCs on 12.3R8. We've had only
one issue, a single port whose SFP turns off the Tx laser when the
interface is enabled and vice versa (see the thread I started on the
6th of March). No idea if it is due to a JUNOS bug though or if it is
fixed in another version.

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

Re: [j-nsp] how to see users

[Tore Anderson]

* Aaron aar...@gvtc.com

 I have a user a I've config'd. I see that I can view it within the
 config.
 
 Also, I see that I can see users actively logged in.
 
 But how do I show users that are configured without viewing it in the
 config file? 

file show /etc/passwd | match /cli$ 

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

[j-nsp] EX4500 SFP+ laser lit when interface is admin down and vice versa

[Tore Anderson]

Hi,

I've got an EX4500 running 12.3R8.7 that has a port that's misbehaving
in a rather odd way: If I disable the interface in the config and
commit, the laser is turned on (normal Tx levels in show interfaces
diagnostics optics). If I re-enable the interface and commit, the laser
is switched off (Tx level of -Inf dBm). So it's doing precisely the
opposite of what I'd expect it to.

When I commit the configuration that enables the interface, the
following message is logged:

chassism[1405]: Tx Disable called for port: 0, enable: 0

I've tried multiple SFP+ modules and they all behave the same. Also
I've tried re-seating the SFP+ with as many different combinations of
the interface being disabled/enabled when I remove/insert the module as
I could think of, no luck. Finally it's only impacting port 0, e.g.,
port 4 works as expected (i.e., Tx off when interface is disabled and
on when enabled) - even with the very same module that don't work right
when inserted in port 0.

Anyone seen anything like that? I'm hoping to find a way fix it without
needing a maintenance window to reboot it.

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

[j-nsp] fxp0.0 interface match in firewall filter doesn't work in JUNOS 12.3R5.7

[Tore Anderson]

This is a heads-up to anyone planning to upgrade to 12.3R5.7, especially
if you don't have easy access to the serial console, but only a firewall
term such as:

term allow-oob-management {
from {
interface fxp0.0;
}
then accept;
}

...in your lo0.0 input filter (which presumably then goes on to drop all
unmatched traffic): It simply doesn't work.

I've confirmed on both MX80 and MX240, several times. After a reboot,
the term just gets skipped, it seems. Deactivating the term, committing,
and then reactivating it fixes the problem but that might of course be
easier said than done if locked out of the box.

Terms doing source-address matches seems to work fine.

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

Re: [j-nsp] S-NAT-IN-MX5-MX10

[Tore Anderson]

* Mark Tinka

 Not to my knowledge, no (well, not in 2014 anyway). N:1 NAT 
 is what makes sense.

FWIW, I've been working on a 1:1 (IPv4:IPv6) NAT solution that I believe
make a lot of sense in 2014 and beyond:

http://tools.ietf.org/search/draft-anderson-siit-dc-00
http://www.ipspace.net/IPv6-Only_Data_Centers

/shameless plug

Now, I doubt that the licence in question would enable me to run exactly
this on my MX-es today, but as I understand that the Trio chips are
capable of doing this in-line, I still have some hope that Juniper will
code up support for configuring it in JUNOS at some point. (Cisco and
Brocade have already done so in some of their products.)

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

Re: [j-nsp] Tunnel failing at No propsal chosen but works when target is another device

[Tore Anderson]

* Mattias Gyllenvarg

 The issue is a IPsec tunnel that will not establish with one device as the
 HUB but works with a different device.
 
 Spoke is SRX210 cluster
 
 Hub is SRX240 cluster
 
 Replacement Hub is a stand-alone SRX210
 
 Junos is 12.1X44-D20.3 across the board.

I had a similar problem. With JUNOS 11.4 in both ends, it worked fine,
after upgrading to 12.1 the exact same config failed to establish
tunnels, giving the no proposal chosen error message.

The solution was to revert back to 11.4 on the hubs (which in my case
are passive and never initiate tunnel establishment). The spokes are
still 12.1, but that seems to work fine.

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

Re: [j-nsp] Link local address errors when committing VRRP for inet6

[Tore Anderson]

* Morgan McLean
 So from doing some googling, I see link local addresses being required for
 any sort of multicast usage under ipv6?
 
 What do I need to do here? I removed the eui-64, that was in there while I
 was trying to get it to commit.

IIRC you need another address fe80::x/64 on that interface.

However the requirement to manually set up link local addresses has been
removed in later JUNOS versions. At lest JUNOS 12.2R3.5 happily accepts
the following:

tore@cr1-osl3 show configuration interfaces xe-1/3/0.524 family inet6
[...]
address 2001:db8:1:2:::1:2/64 {
vrrp-inet6-group 0 {
virtual-inet6-address 2001:db8:1:2:::1;
accept-data;
}
}

Tore
___
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

[Tore Anderson]

* Saku Ytti

 That essentially what we are talking about.  Connect fxp0 to a
 SEPARATE switch that is used for only out of band traffic.  You then
 use this network to copy images, etc.  What am I missing here?
 
 What are you winning by not doing this on-band in HW interface?

Cost. The fxp0 port is basically free. The ports on the line cards are
anything but - there's not a chance in hell I could reserve one of the
revenue ports on the line cards for emergency management access that I
could use to get at the box, should for example my IGP melt down.

Or procure a management switch with 10G ports I could connect the
revenue-turned-mgmt port to, for that matter. Unmanaged 100M switches,
is on the other hand practically free.

 Sure you can, I've done it, others here have said they've done it.
 Assuming the OOB network is well protected from outside traffic to
 avoid attacks and the like, why not?
 
 Additional ports, wiring.

Use of the fxp0 port doesn't require any more ports/wiring than the CMP
style approach you appear to be advocating?

It would be better to have an embedded iLO/BMC in the chassis like you
find on pretty much any x86 server these days - with internal serial
console port, power control, etc. I do have x86 servers with iLOs
connected to the same management switch I connect my fxp0s to. fxp0
isn't perfect, but IMHO it is better than nothing.

Tore


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

Re: [j-nsp] EX series junos 12.x version

[Tore Anderson]

* Timh Bergström

 That's interesting, have you seen any other 'gotchas' with 12.2R3? I'm
 running a 11.3 version and desperately want NSSU (among other things)
 and have a similar setup, lag/lacp/vlan termination/routing/ospf(v3).
 Does 3rd party transceivers work? How is missing licenses handled
 (enforced/warnings)?

I've seen one gotcha - uplinks to a couple of Cisco 6120s went down
after a short period of uptime. Error seen on the Cisco side was DCX-No
ACK in 100 PDUs. No idea if the Cisco or the Juniper was to blame - I
never investigated the issue, as deleting the protocols dcbx
configuration hierarchy on the EX made the links stay up. I'm not using
DCBX for anything anyway, so I'm fine with that.

Other than that: So far, so good. YMMV, of course.

I'm using 3rd party optics with no issues, although most of them are
coded specifically for Juniper. We also use some Cisco-coded DAC cables
without any problems.

I have no idea on how missing licences are handled, as I have all the
licences I need.

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

Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

[Tore Anderson]

 255.255.255.255
  Topology default (ID 0)
Type: 2, Metric: 2, Fwd addr: 192.0.2.40, Tag: 0.0.0.0
  Aging timer 00:26:18
  Installed 00:33:38 ago, expires in 00:26:19, sent 00:33:36 ago
  Last changed 04:13:02 ago, Change count: 3

I guess I'll have to open a ticket...

Best regards,
-- 
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

[Tore Anderson]

* Chuck Anderson

 What does the inet6.0 RIB look like for 2001:db8::1/128 ?

This is the output on R2:

inet6.0: 12118 destinations, 28874 routes (12117 active, 0 holddown, 1 hidden)
2001:db8::1/128 (1 entry, 1 announced)
TSI:
KRT in-kernel 2001:db8::1/128 - {fe80::[R1 ae0.0]}
*OSPF3  Preference: 150
Next hop type: Router, Next hop index: 625
Address: 0xb97ee60
Next-hop reference count: 26
Next hop: fe80::[R1 ae0.0] via ae0.0, selected
Session Id: 0xf3
State: Active Int Ext
Local AS: 39029 
Age: 1:51   Metric: 3 
Validation State: unverified 
Tag: 0 
Task: OSPF3
Announcement bits (4): 0-KRT 3-RT 8-Resolve tree 1 9-Resolve 
tree 2 
AS path: I
AS path: Recorded

In any case I've opened a case on the issue now, hopefully
JTAC can understand what's going on here.

Best regards,
-- 
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Routing loop with OSPFv3 NSSA and external routes

[Tore Anderson]

Hi list,

I'm scratching my head over an OSPFv3 routing loop to an external NSSA
destination that happens when extending the area to another router in
the backbone.

This is (hopefully) all the relevant parts of the currently (working)
setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3,
SW1 is an EX4200 VC running 10.4R6.

2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1
exports this route into OSPFv3.

  2001:db8::1/128
| (RIPng-advertised)
~
|
  [SW1 - ID 192.0.2.40]
|
| (NSSA area 10.0.0.0)
|
| xe-1/2/0.5
  [R2 - ID 192.0.2.4]
| ae0.0 | xe-1/2/0.6
|   |
| (area 0)  | (area 0)
|   |
| ae0.0 | xe-1/2/0.6
  [R1 - ID 192.0.2.5]


On R2 I can see the external NSSA route appear fine:

R2 show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface xe-1/2/0.5, NH-addr fe80::3
  Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

...and on R1 I can see that the ABR R2 translated it into a normal
external route and advertised it into area 0:

R1 show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface ae0.0, NH-addr fe80::2
  NH-interface xe-1/2/0.6, NH-addr fe80::62:2
  Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium
 
The problem occurs when I attempt to include R1 into area 10.0.0.0.
This I do by adding ae0.0 on R1 and R2 into the area in secondary
mode. My problem is that as soon as I do so, traffic to
2001:db8::1/128 starts to loop between R1 and R2. 

As expected, R1 now sees the type-7 LSA generated by SW1 (and
readvertises it into area 0 since it's now an ABR):

R1 run show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface ae0.0, NH-addr fe80::2
  Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

R2, on the other hand, for seam prefers the area 0 external route that
was generated by R1 over the NSSA route generated by SW1:

R2 run show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface ae0.0, NH-addr fe80::1
  NH-interface xe-1/2/0.6, NH-addr fe80::62:1
  Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium

I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then
R2 prefers the route it learned from SW1's Type-7 LSA within area
10.0.0.0, instead of the normal external route received from R1. I would
have expected the same to happen with OSPFv3, but for some reason the
priorities are the other way around.

Anyone have an idea as to whether this is a bug or if I'm doing
something wrong here?

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

Re: [j-nsp] CWDM optics support on EX4500

[Tore Anderson]

* Chris Wopat

 I got a few replies off-list about this and others have had no issues. It
 definitely appears to be due to these being Cisco and not Juniper coded.

Yep, I've sometimes had weird issues with that were due to coding. For
example, a while back I got some Juniper-coded DAC cables for use
between a EX4500 and Cisco Nexus 5K. No problems in the Cisco end, but
they showed up as GE interface in on the EX. The fix was to get them
reprogrammed as Cisco cables, ironically enough.

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

Re: [j-nsp] CWDM optics support on EX4500

[Tore Anderson]

* Chris Wopat

 Has anyone had any luck getting CWDM SFP working in EX4500?

No problems here.

  FiberXcvr vendor
  Port  Cable typetype  Xcvr vendorpart number   Wavelength
  0 10GBASE LRSMFiberworks 10GB-CWDM-47-JN   1470 nm 
  1 GIGE 1000LH   SMOEMSFP-L50D-C51-X1511 nm 

-- 
Tore Anderson
___
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

[Tore Anderson]

* Paul Goyette

 12.3 has now been released.

http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/ex-series-software-licenses-overview.html#jd0e146
http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/ex-series-software-licenses-overview.html#jd0e146

Comparing the above seems to suggest that if you're using e.g. OSPFv2 or
VRRP today, you must purchase an Advanced Feature Licence in order to
upgrade to 12.3. Is that really the case?

Also, what is meant with the phrase with four active interfaces for
OSPF? I hope it does not mean that if you're running OSPF on five or
more interfaces today, you simply cannot upgrade to 12.3?

Best regards,
-- 
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Old JUNOS images removed from download page

[Tore Anderson]

Hi,

For EX, 11.4R5.5 is the JTAC-recommended version for most models. It
appears to have been pulled from the download page, and have been
replaced with a 11.4R5.7 that was released on the 28th of January - same
date as the 11.4R6.6 version. This is also the case for the 11.4 MX images.

JTAC-recommended 10.4R8.5 image for MX has also vanished, replaced by
one 10.4R8.6, also dated the 28th of January. Same release date as
10.4R11.5 and 10.4R12.4.

12.1R4.8 for MX was, according to the download page, released six days
*after* the latest(?) version 12.1R5.5...

Anyone have any idea what's going on here? I'm really starting to worry
that there is some critical undisclosed vulnerability in the removed
versions...

Also 12.2R3.5 for EX4500 just gives me a 404 error.

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

Re: [j-nsp] DHCP interface as next hop

[Tore Anderson]

* Aaron Dewell

 I haven't found an answer to this question (except for Cisco options
 which doesn't help me).  I want to configure a static route to a DHCP
 interface on an SRX240.  Here's the scenario:
 
 ge-0/0/0 connected to CX111 (4G modem/DHCP)
 t1-0/1/0 connected to an L3VPN (with BGP)
 st0.0 should connect over ge-0/0/0
 
 The t1 is considered trusted, so we do not want to form the IPSec
 tunnel over it.  There is a default route coming in via BGP on the
 T1.  The goal:
 
 Statically route the IPSec tunnel endpoint over the 4G modem as a
 /32
 Statically route 0/0 over st0.0 (and set precedence to 170, or set
 BGP down to 4)
 Receive 0/0 from BGP over the T1 (or alternately not, with no need to
 alter precedence, and use two next-hops for one static 0/0)
 
 The purpose is to have the tunnel up but not used until the T1 or BGP
 over it goes away.
 
 However, I cannot set ge-0/0/0.0 as the next-hop because it's not a
 point to point interface. I cannot set an IP address as the next-hop
 because I don't know when it will change.
 
 Any ideas on how to address that?

I have no idea if this can be done or will work, but here's a suggestion
at least:

Configure a static link network (e.g., 192.0.2.10/31) on ge-0/0/0.0
in parallel with the DHCP client. Add a static ARP entry for 192.0.2.11
pointing to the CX111's MAC address. Use 192.0.2.11 address as the next
hop for the static route to the remote IPSEC tunnel endpoint.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Preventing direct routes from forming OSPF summaries

[Tore Anderson]

* Wayne Tucker

 2.) Configure xe-0/0/0 in area 1 of both MXs as a secondary interface.
  That will allow them to exchange the LSDB for that area even when the
 downlink to the EX is down.  There are other reasons that you'd
 probably want that, anyhow.

Sweet. I had no idea that a single interface could participate in
several areas. This solution works very well - thank you!

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Preventing direct routes from forming OSPF summaries

[Tore Anderson]

I have a OSPFv3 network that looks something like this (simplified):

+-++-+
|MX240|xe-0/0/0 ---(area 0)--- xe-0/0/0|MX240|
+-++-+
xe-0/1/0  xe-0/1/0
   |  |
(area 1)   +--+(area 1)
   \-- xe-0/0/0|EX4500|xe-1/0/0 --/
   +--+
||
   (production stuff)

I thought it was nice and fault-tolerant, which it was - until I wanted
to configure route summarisation on the MX-es. Area 1 is an NSSA
allocated a range of IP addresses, which I configured as an area-range
on both MX-es.

I noticed that if the OSPF session between one MX and the EX goes down,
that MX will continue to install the summary discard route, effectively
blackholing all traffic destined for area 1. It will advertise this
summary to other area 0 neighbors (not drawn above) too, sucking even
more traffic into the blackhole. The reason for this appears to be that
the downlink interfaces to the EX are numbered using addresses that's
part of the configured area-range, so if the physical interface doesn't
go down, the direct route is still there and triggering the
summarisation of the area-range.

Is there a clever way to avoid this? I'm thinking along the lines of a
knob that would make it so that a summary wouldn't pop into existence
unless an active *ospf* route from inside the area-range exists.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 Virtual chassis ??

[Tore Anderson]

* Rachid DHOU

 We have two EX4200 switches, mainly used for L2 functionalities.
 We want to add two new EX4200 Switches and we want to connect them with the
 old switches.
 
 i have two possibilities :
 
 * Either, interconnect them and control everything with STP.
 * or use Virtual chassis.
 
 
 Please advise, what is the best way ? did you try Virtual chassis in EX ?
 Do you have other options ?

We have several VCs from both EX4200s and EX4500s (no mixed VCs though),
and disregarding some troubles with the former when the EX product line
was brand spanking new several years ago, they've been rock solid and I
wouldn't hesitate to recommend it over a traditional approach with STP.
You'll get one management interface, and you can build a loop-free
redundant network without STP wasting your bandwidth on blocked ports.

The core switch in one of our data centres is a two-node EX4500 VC with
LAGs to each downstream switch/device and upstream routers. The LAGs has
at least one member from each physical node in the VC, so it's all fully
redundant and I'm very happy with the setup.

The largest downside with it is that upgrading JUNOS, you will have a
30-60 sec downtime on the LACP and OSPF adjacencies, due to the fact
that a VC will not form if the member nodes have different JUNOS
versions. So after first having upgraded the line-card node, when
rebooting the routing-engine node, the upgraded line-card must start
everything from scratch when assuming the routing-engine role. This is
about to improve though, as I hear JUNOS 12.1 has gained support for
NSSU. Haven't tried it myself though, so I don't know if it's mature
enough to be trusted quite yet. (Interested in hearing about any
experiences though.)

BTW: Make sure to enable no-split-detection in your VC, or your two
EX4200s will be mutually dependent and you'll have no HA.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Importing interface routes into routing instances

[Tore Anderson]

Hi, 
 
I'm using routing-instances and filter-based forwarding in order to 
emulate policy-based VPN while actually using route-based VPNs on a SRX 
cluster (I cannot use actual policy-based VPN due to the limitations 
described in KB21363 and KB23082). I'm using a commit script to build 
the necessary config like so (repeated for every possible srcnet/dstnet 
combination for each IKE gateway): 
 
interfaces { 
st0 { 
unit 0 { 
description vpn=acme-0, local=192.168.1.1/32, 
remote=100.64.0.0/24; 
family inet; 
} 
[...] 
} 
} 
security { 
ipsec { 
vpn acme-0 { 
bind-interface st0.0; 
ike { 
gateway acme; 
proxy-identity { 
local 192.168.1.1/32; 
remote 100.64.0.0/24; 
} 
ipsec-policy acme; 
} 
} 
[...] 
} 
} 
firewall { 
family inet { 
filter vpn-policyrouting { 
term acme-0 { 
from { 
source-address { 
192.168.1.1/32; 
} 
destination-address { 
100.64.0.0/24; 
} 
} 
then { 
routing-instance acme-0; 
} 
} 
[...] 
} 
} 
} 
routing-instances { 
acme-0 { 
instance-type forwarding; 
routing-options { 
static { 
route 100.64.0.0/24 next-hop st0.0; 
} 
} 
} 
[...] 
} 
 
I found that this does not actually work, as acme-0.inet.0 ends up 
containing no routes (not even hidden routes). However, if I import
the interface-routes RIB into that routing table, it works: 
 
routing-options { 
interface-routes { 
rib-group inet interface-rib; 
} 
rib-groups { 
interface-rib { 
import-rib [ inet.0 acme-0.inet.0 [...] ] 
import-policy interface-rib-import; 
} 
} 
} 
policy-options { 
policy-statement interface-rib-import { 
term inet.0 { 
to rib inet.0; 
then accept; 
} 
term fallthrough { 
then { 
reject; 
} 
} 
} 
} 

What I can't wrap my head around here is that even though my
import-policy seems to me to prevent anything from being imported into
acme-0.inet.0 at all (and I can see that it does prevent other link
routes from being imported), the above config is *not* equivalent to
simply deleting import-rib acme-0.inet.0 from under [edit
routing-options rib-groups interface-rib]. Does anyone understand why? 

Best regards,
-- 
Tore Anderson 
Redpill Linpro AS - http://www.redpill-linpro.com 

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

Re: [j-nsp] How to query the results tree from a commit script?

[Tore Anderson]

Hi Curtis,

* Curtis Call

 In SLAX 1.1 you'd be able to use mvars, but that isn't released in 
 Junos yet, so you'll need to use some sort of out-of-script storage 
 such as the Utility MIB or a disk file.

Thanks, I'll look into this. On first glance I think perhaps the Utility
MIB might do the trick - I'm thinking that every time the template emits
a transient change, it would also write the unit number to the Utility
MIB. The if test would then check to see if the current iterator was =
the stored number, and if so recurse/iterate further. Or, perhaps even
better, I suppose the template that calls the generate-vpn template
could read in the stored value and call the generate-vpn template with
$unit set to the stored number + 1,

 BTW, this could cause your unit numbers to jump around between 
 commits. (If you remove one VPN then every following VPN will 
 suddenly have a lower unit number). Is that going to be a problem
 for you?

It's not optimal that the unit number may change, but I think I can live
with it. It's my intention to auto-generate everything that refers to it
(routes, ipsec vpn definitions, etc) also, so the configuration should
always be consistent even though the unit numbers would be considered
ephemeral.

 It might be preferable to store the assigned unit number for each VPN
 within the configuration, perhaps within an apply-macro, so that you
 can ensure that a particular VPN doesn't change. That would allow you
 to assign the numbers randomly as well, which would be more 
 efficient. (i.e. when the script makes the transient change it also 
 makes a permanent apply-macro change, recording the assigned unit
 [if it is a previously unconfigured VPN])

My motivation for doing this is to prevent the configuration file from
becoming unmaintainably large. I'd have two apply-macros for each
[security ike gateway foo], one containing a list with the local
networks and one with the remote networks. Those two needs to be
expanded to all possible combinations, so if I, say, have a single VPN
peer with 10 local subnets and 10 remote subnets, I need to build 100
vpn definitions under [security ipsec] with the right proxy identities,
100 st0.x interfaces bound to each of those vpns, and then I haven't
even begun looking at the filter-based forwarding that would be
necessary to direct the traffic into the right st0.x interface.

You can probably see that maintaining such a huge configuration file
manually would be a nightmare, so no, I don't want to store the unit
numbers within the configuration itself. Unless I manage to do what I
want with a script, I think I will need to generate the configuration
off the device instead and push it using NETCONF or something like that.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] How to query the results tree from a commit script?

[Tore Anderson]

Hi,

I'm trying to write a template for a commit script that, when called,
will find the first unused unit on an interface and add some transient
config to it. Unused means that that the unit isn't defined in the
main configuration file and that an earlier call to the template hasn't
written transient config to it yet.

This second part I have trouble figuring out how to accomplish. The
following template will, when called repeatedly, make the change to the
same unit every time (the first one not defined in the input
configuration file). The second condition in the first if() for
/commit-script-result/transient-change/... clearly doesn't work, I
just left it in so it's obvious what I want it to do (I've tried
various other xpath expressions too, without luck). Any suggestion on
how to make this work?


template generate-vpn($unit=0, $ikegw, $local, $remote) {
  /* create the tunnel sub-interfaces on this interface */
  var $iface = st0;

  /*
   * call the template recursively until we find the first unused
   * unit on the interface (poor man's iterator)
   */
  if(/commit-script-input/configuration/interfaces/interface[name == 
$iface]/unit[name == $unit] ||
 /commit-script-results/transient-change/interfaces/interface[name == 
$iface]/unit[name == $unit]) {
call emit-vpn-definition() {
  with $unit = $unit + 1;
  with $ikegw = $ikegw;
  with $local = $local;
  with $remote = $remote;
}   
  } else {
/* found the first available unit, now add the transient change */
xnm:warning {
  message adding interface= _ $iface _ . _ $unit _ ; ikegw= _ 
$ikegw _ ; local= _ $local _ ; remote= _ $remote;
}   
transient-change {
  interfaces {
interface {   
  name $iface;
  unit {  
name $unit;   
description ikegw= _ $ikegw _ ; local= _ $local _ ; remote= 
_ $remote;
family {  
  inet;   
}   
  } 
}   
  } 
}   
  } 
}

If I can make this work, the idea is to extend the transient change to
also add filter-based forwarding for the src/dst network into the right
st0.x interface, plus generating vpn entries for under security ipsec
with matching proxy identities and bind-interface, so that I can make
the SRX establish multi-phase2 IPSEC VPNs to e.g. Cisco ASA without
requiring a massive configuration file. The box is running JUNOS
12.1R1.9.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Connection attempt from unconfigured session

[Tore Anderson]

* Randy Bush

 i am getting a lot of these on my seattle internet exchange interface 
 
 May  4 00:18:39 rpd[1485]: rv_listen_accept: Connection attempt from 
 unconfigured session: ::Ffff:222.77.14.229+40604

One neat feature you can use to get rid of noise and misbehaviour from
unconfigured peers is to use a prefix-list with apply-path to allow BGP
traffic only from configured peers, like so:

tore@cr2-osl2# show policy-options prefix-list bgp-configured-peers 
apply-path protocols bgp group * neighbor *;

and then just refer to it in your lo0 input filter (followed by a
default deny of course), in my case:

tore@cr2-osl2# show firewall family inet6 filter lo0-input-v6 term allow-bgp  
from {
source-prefix-list {
bgp-configured-peers;
}
next-header tcp;
port bgp;
}
then accept;

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4500 - 3rd party DAC/Twinax cable support - link-up at 1g instead of 10g

[Tore Anderson]

* Dale Shaw

 I have a customer that is trying to connect some ESX hosts at 10g to a
 recently commissioned EX4500 VC.
 
 Their ESX hosts are IBM servers, and they were supplied with the
 following DAC cables:
 
 Cable: IBM Twin-ax Active Cable 5M, PN: 45W3039
 Cable labelled as: Brocade 10G Active 5M FCoE, 58-123-01
 
 The (two-member) EX4500 VC is running JUNOS 12.1R1 (mostly due to this
 release being the first to officially support active DAC cables).
 
 The EX4500 detects the interface when plugged into an SFP+ slot but
 the line speed/link-up speed is 1g (ge-*), not 10g (xe-*). Note there
 are no uplink modules installed; we're going directly into the
 built-in ports.
 
 Other info:
 ESX Version: ESX 4.1.0 Build 582267
 Adapter Model: IBM 42C1801
 ESX networking driver: qlgc-qlge-1.0.0.45-100.27-offline_bundle-418618
 
 Has anyone experienced this before? JTAC didn't provide much insight,
 other than to try a Juniper branded cable (e.g. EX-SFP-10GE-DAC-5m or
 EX-SFP-10GE-ACT-5M). So, that's our next step.

Hi,

I bought a couple of 3rd party 5m active cables (that were supposed to
be coded for Juniper EX) that showed up as ge-* interfaces. We were
connecting them to a pair of Cisco Nexus 5010s, which detected them
correctly.

We noticed that some 3m «official» Cisco cables we had lying around
worked fine, so we asked the cable provider to copy the EEPROM ID (or
whatever it is called) from one of those onto the 3rd party ones, and
that made them work fine. It shows up in show chassis hardware like this:

Xcvr 11   NON-JNPR F111026008SFP+-10G-CU3M

And show chassis pic fpc-slot 0 pic-slot 0:

1110GBASE CU 3M n/a   CISCO-TYCO  2053783-2  n/a


This is a EX4500 VC running 11.1R3.5, the cables are plugged into the
built-in ports. Everything runs great now.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] anyone running VC with 2 * EX4500?

[Tore Anderson]

* Alexander Bochmann

 we've been putting off converting our EX4500s to a virtual 
 chassis for quite some time now. I've seen a few posts about 
 mixed EX4500/4200 setups, but none with several EX4500s. 
 
 Does anyone run something like that? Any special caveats, 
 and should we wait some more before trying it? 

Works For Me; I have a two-node EX4500 VC running 11.1R3.5 (until very
recently the version recommended by JTAC), and have had no problems with
it at all.

Just remember to set no-split-detection under virtual-chassis if you are
pairing them up for fault tolerance reasons (that's not specific to the
EX 4500 though).

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Preventing NSSA LSAs from leaking into the backbone when part of a summary

[Tore Anderson]

Hi,

I've got a NSSA with a few external routes, which are flooded as type-7
NSSA LSAs in the area. These are converted to type-5 by the ABR and
flooded in area 0 (and other eligible areas). All as expected.

However, the type-5 LSAs is quite pointless, as they only describe
more-specific routes of a prefix that's already set up as an area-range
on the ABR and are therefore already flooded in area 0 as a type-3 LSA.
I can limit the amount of type-5 LSAs that are flooded in area 0 by
configuring the same nssa area-range, but then I only end up with two
redundant LSAs flooded in area 0 for the same prefix (one type-3 and one
type-5).

So I'm wondering if it's possible to configure the ABR so that it
doesn't generate any type-5 LSAs and flood them into area 0 for any
routes that are already covered by a type-3 LSA?

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Preventing NSSA LSAs from leaking into the backbone when part of a summary

[Tore Anderson]

* Vladimir Blazhkun

 Did you try using:
 
 set protocols ospf area ${nssa_area_id} nssa area-range ${ipv4_prefix} 
 restrict,
 
 where ${nssa_area_id} is the NSSA ID, ${ipv4_prefix} - the prefix,
 containing the range you want to filter?

Nope, which is a *facepalm* to me as I _did_ play around with the
«restrict» keyword but for some reason it never ocurred to me to use it
within the nssa {} block.

It worked very well. Final config, does almost exactly what I want:

# show protocols ospf area 0.0.0.1
nssa {
default-lsa default-metric 1;
no-summaries;
area-range 10.22.0.0/16 restrict;

}
area-range 10.22.0.0/16;
interface [...]

The only little thing I could have wanted more was for a type-5 LSA to
be flooded in the backbone IFF there's only type-7 LSAs in the
summarized prefix in area 1 because in that case no type-3 summary would
make it out. But that's not really a problem in my case.

Thanks to all who replied!

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Tore Anderson]

On 2011-05-27, JUNOS 11.1S2 was released for the EX. So this release is
a couple of weeks newer than JUNOS 11.1R2.3. However,
https://www.juniper.net/customers/csc/software/junos_software_versions.jsp
says 11.1R2.3 is the recommended version for the EX 4500 in VC
configurations.

I'm a bit confused on how to interpret the version numbers of the
service releases. Should I consider junos_software_versions.jsp as the
accurate source of information (in other words that 11.1S2 is a
back-port of fixes alrady found 11.1R2.3 to the 11.1R1 branch), like so,
in incremental order of preference:

1) 11.1R1.10
2) 11.1S1 (i.e. 11.1R1.10 + critical fixes)
3) 11.1S2 (i.e. 11.1S1 + more critical fixes)
4) 11.1R2.3

Or, is the page outdated and the release dates is the thing I should
look at when determining which version to use:

1) 11.1R1.10
2) 11.1S1 (i.e. 11.1R1.10 + critical fixes)
3) 11.1R2.3
4) 11.1S2 (i.e. 11.1R2.3 + critical fixes)

BR,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Tore Anderson]

* Richard A Steenbergen

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

Thanks for the heads-up!

This particular VC isn't really in production yet, so I went ahead and
upgraded anyway. The upgrade went well (I came from 11.1R2 though),
commit sync aftwards had no issues either. So it looks good (or at least
not worse than 11.1R2) for the EX4500-VC.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ex4200 egress filter

[Tore Anderson]

* Richard A Steenbergen

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

Hi again,

Have you gotten the chance to test if this issue is fixed in 11.1R2 yet?

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ex4200 egress filter

[Tore Anderson]

* Richard A Steenbergen

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

Hi Richard,

Could you be a bit more specific about this issue that remains
outstanding in 11.1S1? Is there a PSN for it?

I have a pair of EX4500s in my lab for setup currently, and any older
release isn't an option due to the lack of IPv6 and VC support.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VC (2x EX4200) JunOS Upgrade without downtime ?

[Tore Anderson]

* Giovanni Bellac

 Each of our customer (layer2) rack-switches are connected with a
 trunk (lacp) to the VC. So we can shutdown one EX4200 of the VC (2x
 EX4200) without downtime on paper  ?
 
 
 I have read in the forums of Juniper, that you CAN NOT upgrade a VC
 without downtime, because the updated member will NOT join the VC.
 
 Is that right ? Is a JunOS upgrade on a VC without downtime
 impossible ?

Hi Giovanni,

I recently did some testing of this in a lab. I could not find a way to
upgrade the VC without any service interruption at all, precisely
because a newly-upgraded switch will not join the VC. However, you can
keep the impact fairly low, by doing things in the optimal order. Note
that in my testing I only had two members in the VC, and each downstream
switch multihomed (using LACP trunks) to each of the physical switches
in the VC. I don't really know how this would work if you have more than
two switches in your VC. In any case, assuming that FPC0 is currently
the RE, and FPC1 is the backup:

1) Ensure «no-split-detection» is set under [edit virtual-chassis]

2) Upgrade and reboot FPC1. All ports on that switch will go down,
however the service interruption is negligible - limited to some packet
loss for a split second while the LACP trunks converge on FPC0. After
FPC1 comes back up, it won't join the VC, and remain in the «Inactive»
state, with all ports disabled.

3) Reboot FPC0. FPC1 will now assume mastership, a process which led to
around 30 seconds of downtime on the LACP trunks in my lab setup. You
are now on the new code, and when FPC0 comes backup, it will be in the
«Inactive» state, just like FPC1 was earlier. FWIW, I also did testing
of OSPF adjacencies to the VC running on top of those LACP trunks, those
had ~55 seconds of extra downtime (total ~85 seconds before everything
was back to normal).

4) Ensure that the new code works fine. When happy, upgrade and reboot
FPC0. There's no service interruption, as FPC0 wasn't involved in
pushing packets at this point anyway. When it comes back up, it re-joins
the VC (assuming the backup role) and you're all done.

You could of course skip step 3, instead do a upgrade+reboot of FPC0
immediately. However, if you only do a simple reboot to transfer RE
ownership to the upgraded switch, it is very easy to revert to the old
code if the new one doesn't work properly - just reboot FPC1.

Good luck,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Uplink failure detection in EX series

[Tore Anderson]

Hi,

I'm wondering if it possible to configure something equivalent to the
EX2500's Uplink Failure Detection on the JUNOS-based EX series switches?
I want to designate a couple of interfaces as uplink ports, and if they
all go down, all the other ports on the switch should be disabled as well.

I want to avoid repeats of an interesting failure I just experienced: an
EX top-of-rack switch lost both its uplinks simultaneously, most likely
due to lacpd failing to do its job - both uplinks were 802.3ad LAGs, and
rebooting the switch solved the problem in the end. In any case, since
the downstream access ports stayed up, the servers didn't fail over to
the other switch in the rack and therefore lost connectivity. So much
for redundancy... :-/

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Uplink failure detection in EX series

[Tore Anderson]

Hi,

* Keegan Holley

 I'm not aware of a protocol that can shut down switchports.  There's
 something in the optical world that will shut down a gig port if the
 sonet links it traverses flap, but that wouldn't help here.  Op-scripts
 maybe?

The EX2500 has the required functionality, the Cisco Nexus fabric
extenders too (or so I'm told).

 I want to avoid repeats of an interesting failure I just experienced: an
 EX top-of-rack switch lost both its uplinks simultaneously, most likely
 due to lacpd failing to do its job - both uplinks were 802.3ad LAGs, and
 rebooting the switch solved the problem in the end.
 
 
 That sounds like a bug of some sort.  I'd probably fix it by upgrading
 to code where the bug was fixed.  What code are you running?

No doubt a bug, and probably fixable by upgrading - the switch in
question was running 10.1R1.8...

However, it would be nice to have such functionality in any case. I
would not need to waste ports on dual uplinks, for example.

 Maybe you can write a script that pings out periodically and fails over
 the bundles if the ping fails.  Probably easier than opscripts.  If not
 there's always spanning-tree. ;)

I think both those approaches would cause more problems than they solve.
The Linux bonding driver actually has ping based probing functionality,
but from experience, the ping target is more likely to go down than
anything else happening (or, if it was found on the same switch, it
wouldn't help at all). And STP just terrifies me - I try to rely on it
as little as possible.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX unsupported filter policer and actions on loopback lo0

[Tore Anderson]

* Julien Goodwin

 On 18/12/10 07:28, Chris Morrow wrote:
 yea, so... from:
 http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf

 AFL includes licenses for IS-IS, BGP, MPLS and IPv6 routing
 
 While we're on the topic, I'm still annoyed at this.
 
 Juniper have publicly stated that they won't charge for IPv6, so why are
 they still doing so on EX?

+1

I don't really mind paying a fair price for functionality, but the cost
to run IPv6 on the EX-es is beyond ridiculous.  For example, the
EX3200-24T lists at US$3000.  The price of the licence required to run
IPv6 on that box?  US$4000.  Their strategy is utterly incomprehensible
to me;  it's as if they simply don't want IPv6-using customers.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Strange behavior of BGP policy

[Tore Anderson]

Hi Alexander,

* Alexander Shikoff

 Filtering of outgoing prefixes is performed via to-MHost policy:
 minot...@br1-gdr.ki# show policy-options policy-statement to-MHost 
 term Default {
 from {
 route-filter 0.0.0.0/0 exact;
 }
 then reject;
 }
 term Itself {
 from {
 protocol static;
 route-filter 178.214.192.0/19 exact;
 }
 then accept;
 }
 then accept;
   - this makes the policy-statement accept all prefixes.
 (except for 0.0.0.0/0)

 As you can see only route 178.214.192.0/19 from static routes should be 
 redistributed into BGP, but I see another routes (direct, static, OSPF) 
 also being redistributed:

 [...]
 
 Why does policy accepts another direct/static/OSPF routes?

Remove the out-of-term «then accept» and I think it'll behave the way
you want, provided that the «Deny-Rest» statement does what its name
suggests.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 cluster duplicating traffic or broken mirror?

[Tore Anderson]

* Abel Alejandro

 I have a very strange behavior in my Juniper 4 X EX4200 switch
 cluster. I am running version 10.0S1.1.

I can't comment on your specific issue, but I can say I've had strange
behaviour in conjunction with mirroring, too.  It might simply be that
mirroring isn't supported very well on these boxes...

I had a firewall filter defined under [edit firewall family
ethernet-switching] that copied traffic to the analyzer (which was
defined with only an output interface), and then I added the filter in
the input direction on a few selected VLANs.

It worked well, but when I removed the filter from the definition of a
VLAN I no longer wanted to mirror, for some reason the traffic to that
particular VLAN was still being mirrored and I couldn't for the life of
me figure out how to make it stop.

Never got around to submitting a ticket for it, though.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX for access/core routing/MPLS duties?

[Tore Anderson]

* TCIS List Acct

 I've been reading past threads on the SRX line with interest.  It seems
 this box can do many of the things we are looking for (at a low price
 point), which include:
 
 - MPLS
 - IPv4 routing (OSPF, BGP)
 - Runs JunOS
 - Could be used at the access layer
 - Future IPv6 support
 - If required, could be used as an edge device holding a full IPv4 table
 (at least, the SRX650 and above)
 
 Can anyone comment on experiences with these devices, such as:
 
 - Wire rate?  yea/nay?
 - Anyone ever tried to use one as an edge router w/a full BGP feed?
 - MPLS -- mainly EoMPLS type stuff, esp. at the access layer
 - Stability (we understand that this is highly specific to the JunOS
 release)

Hello,

I don't have any first-hand experience with the SRX but if you read back
in the archives of this list there's lots of messages saying it's
basically unusable because of lots of bugs and stability issues, and
even disregarding that there's the issue about it operating in flow-mode
with also is a big problem if you want to use it as a standard router
(as opposed to a security device/firewall).  I'm sure others will chime
in on these issues though.

However I do have first-hand experience of buying Juniper products with
«future IPv6 support».  I would NOT trust Juniper to deliver on that
promise in an honest manner if I were you.  I did, and while the JUNOS
support arrived shortly after my purchase, it required an «advanced
feature licence» with a hefty price tag (which they had neglected to
mention).  Juniper will tell you they have IPv4/IPv6 feature parity in
their licenses (http://www.youtube.com/watch?v=mXMMBrWRnvc#t=63m40s
for instance), but it is simply not true.  So unless you can hold off
your purchase until you can support the support is definitively there in
the base licence, be very careful.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Configuring an untagged native VLAN on an EX in a neat way

[Tore Anderson]

Hi list,

I'm trying to configure a untagged native VLAN on a trunk interface in a
sensible way on an EX switch running JUNOS 10.1R1.8.

If I do:

family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
native-vlan-id 2;
}

...the egress packets from VLAN 2 will be tagged.

If I instead do:

family ethernet-switching {
port-mode trunk;
vlan {
members 3-4094;
}
native-vlan-id 2;
}

...the commit fails with the first undefined VLAN ID:

error: No vlan matches tag 4 for interface ge-0/0/46.0
error: configuration check-out failed

What works is to add all configured VLANs (except 2) to the members
statement.  However that with a several hundred configured VLANs that
configuration statement gets really nasty-looking.  And it'd be easy to
forget to add a newly configured VLAN there, too, so I'd rather avoid
doing it that way if at all possible.  Any suggestions on how to do it
better would be greatly appreciated!

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Configuring an untagged native VLAN on an EX in a neat way

[Tore Anderson]

* Kari Asheim

 You can remove the members from the port and instead use apply-groups
 to add this to all vlans something like this:

Thanks Kari and Cristopher!  :-)

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX 8200 deployment

[Tore Anderson]

* Richard A Steenbergen

 Correct. I actually found some old gripes about this when I searched
 j-nsp after noticing the problem, but it is a big enough issue that I
 think it needs to be repeated again (and again and again, until it
 gets fixed :P).

I'll be happy to join the choir on this one.  I reported the problem
back in March 2009, got PR 435648 opened, but haven't heard anything
more since then.

My workaround is to terminate the customer VLANs that needs counters
for accounting purposes on the EX-es' upstream routers instead, which
are MX-es with standard vlan-tagged family inet sub-interfaces.  That
works well enough but it's not as tidy as I would have preferred.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] J2320 as BGP router

[Tore Anderson]

* TCIS List Acct

 But don't you need the advanced feature license to do BGP on the
 EX3200 series?  That license adds thousands to the cost..

There's also JX-BGP-ADV-LTU, «Advanced BGP License for J-Series», which
almost equals the list price of the smallest J2320.  I'm not sure what
exactly would make a BGP setup advanced enough to require this license,
though.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] J2320 as BGP router

[Tore Anderson]

* Niels Raijer

 Correct, a J2320 can have 2 GB of RAM:

Did you upgrade it to 2 GB yourself?  If so, it would be great if you
could share which RAM manufacturer and part number you used.

The February price list says (like the web site) that the J2320-JH model
ships with 1 GB of RAM.  I can't see any 2 GB alternative either.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper EX-2500

[Tore Anderson]

* Ralph Smit

 I was wondering if anyone has anyone has any (lab) experience with
 the new Juniper EX-2500 switches. We're looking for a high-density
 10GbE switch and our shortlist consists of; the Arista 7124S, Brocade
 TurboIron 24X, HP 6600-24XG and the EX2500. Since we currently have
 Juniper and HP in our network, we're tempted to go for the EX2500.
 This because it beats the HP in power-consumption and latency, and
 both the Arista and Brocade would mean introducing a new vendor in
 our network...
 
 any additional thoughts, info or feedback would be greatly
 appreciated.

I've not played with the EX 2500, but be aware that it's an OEM-ed
product (I believe it's really a BLADE G8124) that does not run JUNOS.
And JUNOS is in my opinion the #1 argument for choosing Juniper gear...

You might also want to look into the Cisco Nexus 5000 series switches.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX-Series JUNOS Version

[Tore Anderson]

* Mark Tinka

 sarcasm
 The world is well again, if your choice of JUNOS gets the E-
 EOL sticker :-).
 /sarcasm

Do you know if the list of E-EOL or recommended JUNOS versions for the
MX is published somewhere, by any chance?  I've not been able to find
any info about it on Juniper's web site (the closest I've seen is the
article that states which versions are recommended for EX-, J-, and
SRX-series).

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200-24f lo0 filter

[Tore Anderson]

Good morning,

* Sven Juergensen (KielNET)

 according to http://bit.ly/9Xn1u9 loopback
 filters on EX switches are supported since
 9.2R1. My box is running 9.5R3.7 and conf-
 iguring something at the [edit firewall]
 context, ends me up with
 
 firewall {
 ##
 ## Warning: configuration block ignored: unsupported platform
 (ex4200-24f)
 ##
 filter REF {
 term snmp {
 from {

Have you tried configuring it under [edit firewall family inet] instead
of straight under [edit firewall]?  That's where I've got it configured
on my switches and it works just fine (running 9.3S7.2 and 9.5R2.7).

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] JUNOS vulnerability with malformed TCP packets

[Tore Anderson]

Hi list,

I think most of you will find this interesting:

http://www.theregister.co.uk/2010/01/07/juniper_critical_router_bug/
http://praetorianprefect.com/archives/2010/01/junos-juniper-flaw-exposes-core-routers-to-kernal-crash/

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Tunnel services on the DPCE-R-20GE-2XGE

[Tore Anderson]

Hi and a happy new year to you all,

Does anyone know if the 1 Gb ports on the DPCE-R-20GE-2XGE can be
(individually) configured with tunnel services?

I currently have only the DPCE-R-4XGE-XFP in use, and in order to use
tunnel services I need to set aside a whole 10 Gb port - which is way
more than I'll ever need.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Tunnel services on the DPCE-R-20GE-2XGE

[Tore Anderson]

* Peder Bach

 Yes, we run the 20 x GE with tunnel.
 
 FPC 0REV 14   DPCE 20x 1GE R EQ

I'm not sure if that's the same card, the DPCE-R-20GE-2XGE has 2x 10GbE
in addition to 20 x GbE.  I think you might have the DPCE-R-Q-20GE-SFP?

But in any case I think they're likely to work the same.  Thanks for
your reply!

 fpc 0 {
 pic 1 {
 tunnel-services {
 bandwidth 1g;
 
 Interface will be: ip-0/1/10

Interesting.  So you're still able to use all physical ports (ge-0/1/0
through ge-0/1/9) as before;  you've actually oversubscribed the PFE by
11:10?

That can't be done on the 10 GbE PFE, enabling tunnel services
deactivates the physical port completely.  :-(

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Tunnel services on the DPCE-R-20GE-2XGE

[Tore Anderson]

* Mertens, Bart (NSN - BE/Herentals)

 You are not oversubscribing that 'pic'. There is a bandwith of 14ge per
 'pic' (per 10x1ge port, or per 1x10ge port).

I see, thanks for clearing that up for me.

 When you then create a tunnel interface on a pic with 10x1ge port, you
 still have more then
 Enough capacity to create a 11th phantom port, without loosing capacity
 or oversubscribing.
 This is also the reason, with a 4x10ge card, that you have to sacrifice
 1 physical port.
 There is not enough spare bandwith to allocate a phantom port...

I would think I should be well within the 14 Gb limit with a 10 GbE
physical port plus a 1 Gb phantom tunneling port.  The configuration
(same as the one Peder Bach posted) committed fine but it simply didn't
work (unless I used bandwidth 10g instead, thereby disabling the
physical port).

Which is a shame, since that's what I would have wanted the most...

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX Routing Throughput

[Tore Anderson]

* Paul Stewart

 Our needs are reasonable simple I think - considering putting in 10
 EX4200 in a virtual chassis configuration using the Virtual Chassis
 Cabling.  This allows us ample copper ports on the front and we can
 use the 4X1GE or 2X10GE ports for our fiber needs.  Total layer3
 throughput would probably be about 1Gb/s average and peak at 2Gb/s.
 OSPF, some small ACL, and IPv6 would be used.

Your throughput requirements are quite modest - you won't have any problems.

The first forwarding performance limitation I believe that one could
realistically run into is the available bandwith between the ASICs - if
I recall correctly, each 48-port EX4200 has three:  one that handles
port 0-23, one for ports 24-47, and one for the uplink module.  They are
daisy-chained with 8x PCIe interconnects so the bandwith between them
are limited to 32 Gbps (full duplex).

Use of the VC ports on the back simply continues the chain.  If you have
a stand-alone switch, on the other hand, you should preferably loop them
back so that traffic from the uplink module to ports 0-23 do not have to
transit the ASIC handling ports 24-47.

One rather annoying thing you should be aware of is that you will need
to purchase a separate license to run OSPFv3 (even though OSPFv2 is
included in the base image).

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JunOS 9.4R1.8 - Memory Leak?

[Tore Anderson]

Hey,

 I'll keep you posted if I learn more, and thanks in advance for doing
 the same...

The fine folks from nLogic and JTAC have a theory now, which is that the
leak is related to a new process introduced in 9.4 called lpdfd.  It's
not something I've been using, so disabling it was not a problem for me:

system {
processes {
local-policy-decision-function disable;
}
}

The process was logging to files in the directory /mfs/var/lpdfd,
which is mounted on a memory-backed block device.  This is the actual
leak, it seems.  I deleted all the logs, but suprisingly enough it
didn't cause the memory utilisation (as reported by show chassis
routing-engine) to drop sharply.  However, it seems like the router now
has stopped leaking!  The memory utilisation is down to 93% - it was at
96% right before lpdfd was disabled and had been slowly but steadily
increasing up until that point.

I had disabled the process on my other MX too, but I have not yet
deleted its log files.  So far it looks like the memory usage on that
one has flatlined.  I suspect that the memory freed up by deleting the
files is reclaimed only when needed, and that's why I see a (small) drop
in memory utilisation on the router where the log files were deleted only.

I'll have to monitor the memory utilisation on the routers for a few
more days before I can be certain that we've nailed the bug, though, but
I'm feeling optimistic.  You'll probably want to try disabling the
process yourself.  Let me know how it goes!

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JunOS 9.4R1.8 - Memory Leak?

[Tore Anderson]

Hi,

* Mark Tinka

 Anyone notice what looks like an RE memory leak/usage growth 
 post a JunOS 9.4R1.8 upgrade?
 
 System here is RE-850 in an M7i with 1.5GB of DRAM. 
 
 cflowd suspected; we've disabled it and appear to have 
 arrested further growth in usage.

I just had a MX 240 with 9.4R1.8 crash hard today, no trace of any
reason in the logs as far as I can see.  When I got to the console it
was in some kind of a debugger, and I had to powercycle it to get it
back online (reset from the debugger just booted up in a single-user
shell or something like that).

We're using cflowd but not IS-IS.  I have two MX-es which are set up
almost identical, but the one that crashed are connected to an IX so it
has in excess of 40 BGP peers while the other one has only 5 - possibly
that caused it to go first?

The one that hasn't crashed (yet?) has very little free memory now:

 show system processes summary
last pid: 11142;  load averages:  0.00,  0.04,  0.08  up 21+07:24:22
17:42:18
116 processes: 4 running, 95 sleeping, 17 waiting

Mem: 1282M Active, 256M Inact, 120M Wired, 308M Cache, 69M Buf, 30M Free
Swap: 2048M Total, 2048M Free


  PID USERNAME  THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
   11 root1 171   52 0K12K RUN499.0H 91.55% idle

While the recently booted one looks much better:

 show system processes summary
last pid:  1571;  load averages:  0.00,  0.03,  0.06  up 0+01:05:11
17:43:37
116 processes: 3 running, 95 sleeping, 18 waiting

Mem: 418M Active, 213M Inact, 108M Wired, 211M Cache, 69M Buf, 1046M Free
Swap: 2048M Total, 2048M Free


  PID USERNAME  THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
   11 root1 171   52 0K12K RUN 59:48 96.19% idle

They had almost identical uptimes prior to the crash, and the last boot
was due to the upgrade to 9.4.  I just opened a case with my local
support provider, haven't heard back from them yet.

I'll keep you posted if I learn more, and thanks in advance for doing
the same...

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP interface index change after upgrade to 9.2

[Tore Anderson]

* Chris Adams

 Never used Cisco I guess?

I have.  As Steinar haug has already pointed out, IOS supports keeping
ifIndexes static.  Fortunately someone had the good sense to enable that
feature, so they've never caused me any problems.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

Re: [j-nsp] SNMP interface index change after upgrade to 9.2

[Tore Anderson]

* Richard A Steenbergen

 Normally I'm the one yelling at Juniper when they do something stupid
 and break things for no reason, but honestly...

I admit that the tone in my first e-mail to this thread was over the
line, and for that I do apologise.  I hope nobody got offended.

It was extremely frusterating to spend much of the day cleaning up the
unexpected graph mess that resulted from the JUNOS upgrade - I certainly
had more interesting tasks planned.  Hearing from Malte that the issue
had already been reported to JTAC, but that they didn't seem to care,
made me quite angry and upset.  I should have kept my breath for ten
seconds before replying, though.

I do appreciate that Patrik is looking into the issue now.

 Any software which relies on static ifIndex mappings between polling
 cycles is fundamentally flawed, period, end of discussion. There is
 absolutely no excuse for this, it is beyond trivial to map data by
 ifDescr, and the SNMP spec even tells you that ifIndex is not to be
 used for this kind of thing.

I realise that now.  However, such pieces of software are in use by many
people (five people in this thread alone as far as I can see), and when
the ifIndex changes, it causes severe breakage for us.

Even though current JUNOS behaviour can be considered spec-compliant I
would still like to see the ifIndexes being kept static - it would be a
great feature enhanchement for those of us that (unwittingly) chose SNMP
software that doesn't handle ifIndexes changing.  As I pointed out in my
first message, it can't be that hard - just reserve some space for the
private ifIndexes and start the public ones from, say, 1000.  (This is
what my Extreme switches does.)

Speaking of Extreme, by the way...  Juniper is the first vendor whose
gear has changed ifIndexes on me, ever.

 I really don't understand why people still can't figure out how to do
 this.

I assume most of the people on this list are not application developers,
but network administrators - at least I am not.  So I/we are stuck with
whatever pieces of software is available, and changing an already-
established setup is probably going to be a big project in most cases.
Considering that not even the ubiquitous MRTG handles changing ifIndexes
by default I think static ifIndexes would be a worthwhile feature for
Juniper to implement in an upcoming JUNOS release.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP interface index change after upgrade to 9.2

[Tore Anderson]

Hi Patrik,

* Patrik Olsson

 I wont speak for EX, since I am not sure. But for M/MX/T/TX the SNMP
 index for interfaces (used for graphing for instance) should not change
 due to reboot. I have not seen that in my small lab at least. 
 
 What JUNOS version do you see this in?

It doesn't happen due to reboots, but due to JUNOS upgrades.  Like I
wrote in my original e-mail, after upgrading from 9.3R1.7 to 9.4R1.8 all
of my graphs stopped working.

(The original poster reported it happened going from 9.1R1.8 to 9.2R2.15.)

The «you'll just have to live with it» answer Malte got from JTAC is
unacceptable coming from a high-end vendor like Juniper.  From a cheap
no-name vendor it would be understandable, but I pay a premium for my
Juniper gear and therefore I expect better.

Regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

Re: [j-nsp] SNMP interface index change after upgrade to 9.2

[Tore Anderson]

* Patrik Olsson

 Did you see this in your MX240s aswell?

Yes.  I'll repeat myself:

 An upgrade of two of my MX 240ies today, going from 9.3R1.7 to
 9.4R1.8, resulted in all of my graphs becoming hosed.

Regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP interface index change after upgrade to 9.2

[Tore Anderson]

* David Ball

   Anyone else notice this?  Am I incorrect in my previous assumption
 that Juniper had solved this issue of SNMP index changes across
 reboots?

They still haven't, unfortunately.  An upgrade of two of my MX 240ies
today, going from 9.3R1.7 to 9.4R1.8, resulted in all of my graphs
becoming hosed.

A major pain in the arse!  Grrr...

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP interface index change after upgrade to 9.2

[Tore Anderson]

* Malte von dem Hagen

 we filed that as a PR for the EX-Series we updated from 9.1 to 9.2 a
 while ago, and got the response from JTAC that this is expected behaviour.

Unbelievable.  This provokes me!  I really hope that the idiot(s) that
made this design desicion are no longer working at Juniper.

Hey, Juniper, if you're reading this:  Do you think that I ENJOY wasting
hours of my to clear up the mess this «feature» has caused, you're sadly
mistaken!  Not only is it fscking annoying - I use the data in my graphs
for accounting too (and I think that's pretty common to do), so now
valuable data used for invoicing customers is lost forever.

And this was only for the MXes!  My EXes have 100s of graphs...  I don't
want to even think about the hassle it would be to fix all of those
manually.

 Public interfaces get snmp ifIndex numbers *after* private interfaces,
 so every time the private interfaces (whatever they exactly are) change,
 the index numbers of public interfaces will change as well. And yes,
 that is big PITA and very lame.

Jesus.  So reserve some room for the private interfaces and enumerate
public ones staring from ifIndex 100 or 1000 or whatever, then.  That
wasn't too hard now was it?

Juniper:  to simpy say that this is just «expected behaviour» is
COMPLETELY UNACCEPTABLE, it's a DEFECT, and it NEEDS to be FIXED.

*fumes*

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

Re: [j-nsp] network engineering

[Tore Anderson]

* keegan.hol...@sungard.com

 My apologies I misunderstood your question. However, isn't ICMP into
 your connector networks a small thing?  I don't think anything
 catastrophic would happen if someone pinged your router and the return
 traffic took your primary link.  The traceroute packets would only be
 discarded if your ISP has some sort of RPF enabled, which is rare on an
 internet link.  Even if they were this would not affect traffic from
 your users or downstreams.  I guess you could do filter based forwarding
 to rectify this behavior, but it seem a little like putting out a match
 with a firehose.

You are right, it is no big deal.  Still, it seems wrong to me, and if
it was an easy way to fix it I'd do it.  It was very easy to do in Linux
back when I used Quagga for eBGP, but I realise now that on JUNOS it's
simply not worth the effort.

Thanks,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] network engineering

[Tore Anderson]

* Justin M. Streiner

 There is a common misconception that asymmetric routing is somehow bad.
 Yes, it can make troubleshooting connectivity problems a bit more
 involved, but asymmetry is a perfectly normal condition.  Also, even if
 you were to enforce symmetry within your network, there is no guarantee
 that the path will remain symmetric once it leaves your network.

There's one case where I believe asymmetric routing is bad, and where
I'd very much like to avoid it - I want packets with a source from the
interface address of my transit ports to be sent out to the provider's
router on that interface.

Consider the following network:

[Transit provider AS123]-123.0.0.1--123.0.0.2-[   My]
  [ Juniper ]
[Transit provider AS321]-321.0.0.1--321.0.0.2-[ router  ]

123.0.0.x is part of AS123's PA space, 321.0.0.x is part of AS321's.
Routes received from AS123 has a higher localpref than those from AS321,
for whatever reason - like simply being cheaper.

If someone on the other side of the internet now sends an ICMP ping or
whatever to 321.0.0.2 I'll end up routing the reply packet out through
AS123, since the route to that particular other side of the internet has
a higher localpref through AS123.  However from AS123's point of view
I'm now spoofing traffic from AS321's PA space, so they might feel free
to drop the packet due to a failing uRPF check or whatever.

So what I'd want is to always route packets with a source of 321.0.0.2
via 321.0.0.1, if the destination isn't found in my IGP.  Likewise for
123.0.0.2.

I suspect it has to be done by using a separate forwarding-type
routing-instance with a static route to 0/0 via 321.0.0.1 combined with
an output filter on lo0 that jumps to that routing instance if the
source address matches, but I was unable to figure out exactly how to
make it work when I played around with it earlier today.  If someone has
an example config to share that accomplishes it, I'd be very grateful.

Regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] network engineering

[Tore Anderson]

* keegan.hol...@sungard.com

 Direct routes always take precedence over BGP unless it's configured
 otherwise so hopefully this address is in your IGP or next hop self is
 configured.  Also, if you talking only about the directly connected
 route used for your peer, wouldn't the return traffic be your fault for
 advertising 123.0.0/30 to AS321 and vice versa?

The direct routes on the eBGP links are only to 123.0.0.0/30 and
321.0.0.0/30 in my example.  What I'm talking about is if someone sends
a ping from, say, 111.0.0.1 in AS111 (an AS to which I'm not connected),
to 321.0.0.2, and I want to reply to that ping.  This is what happens:

The ping packet will reach me through the link to AS321 due to the fact
that 321.0.0.2 is part of AS321's PA space, I have no control over that.
 However, when my router is replying to that packet it'll look up the
route to 111.0.0.1, find that it's available as an eBGP route (_not_ as
a directly connected route) through both AS123 and AS321, and since
routes learnt from AS123 has a higher local preference my router will,
by default, route the ping reply packet using the route through AS123.
Which is in my opinion bad, since the source address of the ping reply
is 321.0.0.2, part of AS321's PA space, not my own.

I believe the same problem will occur if 111.0.0.1 does a traceroute to
somewhere inside my network and the inbound packets come through AS321,
the ICMP TTL exceeded-packets will be routed out through AS123 and
possibly be discarded.

Regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNOS resolves indirect next-hops using other BGP routes

[Tore Anderson]

* david@orange-ftgroup.com

 Yes I understand, you want is to disable recursive lookup, but I
 believe that you can't do that.

Well, yes, but _only for AS-external routes_.  I need recursive lookups
to happen from OSPF-learnt routes, or else my border routers won't be
able to use any other than their own directly-connected transit links.
(Unless I end up using next-hop-self mangling, that is.)

 Just for information could you give me the output of the command :
 
 show route resolution 195.18.241.97 extensive

Sure:

t...@mx240 show route resolution 195.18.241.97 extensive
Tree Index: 1, Nodes 0, Reference Count 1
Contributing routing tables: inet.3
Tree Index: 2, Nodes 274975, Reference Count 1
Contributing routing tables: inet.0 inet.3
Tree Index: 3, Nodes 274975, Reference Count 1
Contributing routing tables: inet.0 inet.2

If I add the uplink network towards AS3307 into OSPF (passive), the
output doesn't change, but the next-hop is then resolved correctly
(using the OSPF route) to the router where the transit link from AS3307
is connected (instead of resolving to another router where the AS12552
transit link is connected).

There isn't any difference in output from the show route resolution
195.18.241.97 extensive command in the two cases, though, except for
the node count, which I assume is expected due to fluctuations in the
routing table size.

Regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

Re: [j-nsp] JUNOS resolves indirect next-hops using other BGP routes

[Tore Anderson]

* Pekka Savola

 This is a feature.  Why should BGP next-hop resolution not be able to
 use BGP routes?  There could be more specifics that give the right
 information.

Because I don't want a route from AS3307 to end up routing packets to
anything but AS3307, not to AS11552 as happened in my test case.
Fortunatly I buy global transit from both of those, so the packets would
reach its end destination anyway, but if AS11552 had only provided me
with, say, European transit I might not have been so lucky.

As I understand it the whole point of indirect next-hop resolution is
for a BGP router to determine which other BGP router in the same AS has
the next-hop of the route directly connected, so that the packet can be
sent there and the route be used as advertised.  At least that's the
most common scenario, and the only one the documentation of next-hop
resolving discusses.

 You can adjust the route resolution policy with 'routing-options
 resolution rib inetX-X import FOO'.  That's what we do to exclude e.g.
 our default discard route from affecting nexthop feasibility algorithm.

Great, thank you!  That was what I was looking for.  The following seems
to have done the trick:

policy-options {
policy-statement accept-igp-only {
term 1 {
from protocol [ ospf ospf3 ];
then accept;
}
then reject;
}
}
routing-options {
resolution {
rib inet.0 {
import accept-igp-only;
}
}
}

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNOS resolves indirect next-hops using other BGP routes

[Tore Anderson]

* david@orange-ftgroup.com

 The protocol next-hop seems to be resolvable : but it is not directly
 known in our IGP. So you have a recursive lookup til you find a
 forwarding next-hop.

Yes, exactly.  What surprises me, however, is that EGP routes is
considered at all when resolving indirect next-hops of iBGP routes.  I
have problems coming up with a scenario where that behaviour would be
desireable, and the JUNOS documentation I quoted is also quite clear on
the fact that it is intra-AS OSPF, IS-IS, RIP, or static routes that are
supposed be used for next-hop resolving.

The behaviour I expect (and want) is for routes that come with a
next-hop that is not resolvable through my IGP should be ignored
outright and _not_ be placed in the PFE, even though the next-hop is
resolvable using a BGP route.

Regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

[j-nsp] JUNOS resolves indirect next-hops using other BGP routes

[Tore Anderson]

Hi list,

I've just noticed that my MXes appears to be happily using external
BGP routes in order to resolve indirect next-hops on other BGP routes.

See the following example.  Due to my own paranoia it's anonymised -
10.0.0.x is my own internal prefix.  195.18.241.97 is the next-hop on my
transit link to AS3307, however I (intentionally) forgot to activate
OSPF on this upstream interface.  So the route to this next-hop is only
visible to other routers in my network through another transit link to
AS12552 on another router.  This is how it ends up looking on an MX 240
with no external BGP sessions:

t...@mx240 show route 60.235.0.0 extensive

inet.0: 274939 destinations, 548848 routes (274938 active, 0 holddown, 1 hidden)
60.235.0.0/18 (1 entry, 1 announced)
TSI:
KRT in-kernel 60.235.0.0/18 - {indirect(1048576)}
*BGPPreference: 170/-51
Next hop type: Indirect
Next-hop reference count: 4
Source: 10.0.0.4
Next hop type: Router, Next hop index: 582
Next hop: 10.0.0.21 via xe-1/1/0.0, selected
Protocol next hop: 195.18.241.97
Indirect next hop: 1ad1e500 1048576
State: Active Int Ext
Local AS: 12345 Peer AS: 12345
Age: 1:06:05Metric2: 20
Task: BGP_12345.10.0.0.4+179
Announcement bits (3): 0-KRT 7-Resolve tree 2 8-Resolve tree 3
AS path: 3307 1299 4134 17633 I
Accepted
Localpref: 50
Router ID: 10.0.0.4
Indirect next hops: 1
Protocol next hop: 195.18.241.97 Metric: 20
Indirect next hop: 1ad1e500 1048576
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.0.0.21 via xe-1/1/0.0
195.18.128.0/17 Originating RIB: inet.0
  Metric: 20  Node path count: 1
  Indirect nexthops: 1
Protocol Nexthop: 10.0.0.1 Metric: 20 
Indirect nexthop: 8e2d140 1048575
Indirect path forwarding nexthops: 1
Nexthop: 10.0.0.21 via xe-1/1/0.0
10.0.0.1/32 Originating RIB: inet.0
  Metric: 20  Node 
path count: 1
  Forwarding nexthops: 1
Nexthop: 10.0.0.21 via xe-1/1/0.0

t...@mx240 show route 195.18.241.97

inet.0: 274922 destinations, 548808 routes (274921 active, 0 holddown, 1 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

195.18.128.0/17*[BGP/170] 9w6d 00:37:47, localpref 100, from 10.0.0.1
  AS path: 12552 3307 I
 to 10.0.0.21 via xe-1/1/0.0
[BGP/170] 2w6d 21:56:15, localpref 100, from 10.0.0.2
  AS path: 12552 3307 I
 to 10.0.0.22 via xe-1/1/0.0

This behaviour appears to run counter to the documentation, which states
only IGP routes is used for this:

 JUNOS software supports the concept of an indirect next hop for all
 routing protocols that support indirectly connected next hops, also
 known as third-party next hops.

 Because routing protocols such as internal BGP can send routing
 information about indirectly connected routes, the JUNOS software
 relies on routes from intra-AS routing protocols (OSPF, IS-IS, RIP,
 and static) to resolve the best directly connected next hop. The
 Routing Engine performs the task of route resolution to determine the
 best directly connected next hop and install the route to the Packet
 Forwarding Engine.

-- 
https://www.junipernetworks.com/techpubs/software/junos/junos93/swconfig-routing/swconfig-routing.pdf

I would have expected the MX to not install the route into the FIB at
all due to the next-hop being unresolvable.  Does anyone know if the
current behaviour is intentional or if it's a bug?  Is there any way to
prevent BGP routes from being used for resolving indirect next-hops?

The JUNOS version is 9.3R1.7, by the way.

Regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

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

[j-nsp] Using third-party VC cables with the EX 4200

[Tore Anderson]

Hello,

I'm deploying EX 4200 swithces in a data centre, putting one in each
rack and combining them all into a Virtual Chassis.  Some places the
racks are placed too far apart so that the 3m cables (the longest that
Juniper supplies) won't reach, however.

I'd like to avoid using wasting the uplink ports in order to connect the
switches.  Seeing that the cables appear to be plain 8-lane PCIe, I was
wondering if anyone has tried using longer cables from third-party
vendors (such as Molex, who have them in lengths up to 7m)?

Regards,
-- 
Tore Anderson
Redpill Linpro AS - Changing the game
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Best practises for BGP/IGP interaction

[Tore Anderson]

Hi,

I'm setting up two data centres that'll look something like this (very 
simplified):

  IGP A1  IGP A2
|   |
|   |
  BGP A1  BGP A2
|   Site A  |
|   |
|   Site B  |
  BGP B1  BGP B2
|   |
|   |
  IGP B1  IGP B2

The routers marked BGP are Juniper MX-es, and terminate transit and 
peering links.  The ones marked IGP are Juniper EX-es, running VRRP on 
edge VLANs or routing things onward to other firewalls/routers/etc.  I 
don't have any route reflectors.  The IGP is OSPF.

I'm wondering if my following plans makes sense or if there's another 
set of best practises I should consider - Juniper is a bit new to me, 
still, and I kind of just picked up things as I went along with Cisco 
too..

Anyway:

1) the BGP routers will all have a 0/0 discard route they'll inject into 
OSPF, to make sure the IGP routers knows how to route to external 
destinations.  (Same as default-information originate in Cisco.)

Is there any other way to accomplish this, by the way?

2) the BGP routers will have configured a very high cost on the 
interfaces connected to the IGP routers.

This is to prevent iBGP sessions between, say, BGP A1 and A2 to be 
routed via IGP A1+A2 if the link between BGP A1 and A2 failed.  If that 
happened, it would cause a routing loop between BGP A1 and IGP A1 for 
packets with external destinations connected to BGP A2 (and vice verca), 
correct?

Better that the packet takes a detour via the BGP speakers in site B 
then, right?

Best regards,
-- 
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Using lo0 address as source in VRRP announcements

[Tore Anderson]

Hi,

I am considering starting using two EX 4200 VCs as the access routers on 
a bunch of server VLANs in my data centre, replacing a pair of 
home-brewn Linux software routers with Keepalived (a VRRP 
implementation).

I've come up with the following configuration for VRRP (similar on the 
other switch, only using 87.238.63.3/28 instead):

[edit interfaces ge-1/0/0 unit 0 family inet]
[EMAIL PROTECTED] show 
address 87.238.63.2/28 {
vrrp-group 0 {
virtual-address 87.238.63.1;
}
}

Now, the bad thing here is that JUNOS apparantly demands that I add a 
static address to the interface (87.238.63.2/28), and that I cannot add 
a netmask to the virtual IP itself (it inherits the mask from the 
static address instead).  This means that every network segment running 
VRRP needs (at least) three addresses is consumed for the virtual 
router:  one static per physical router, and one virtual address.

That seems rather wasteful in these days when IP(v4) addresses are 
scarce.  With the Linux/Keepalived solution I could simply tell it to 
use the loopback address as the source of the VRRP announcements, so 
that I only had to reserve one IP address per network segment (the 
virtual address, that is).

JUNOS won't let itself be fooled by me using a private address for the 
static addresses either, e.g.:

address 169.254.63.2/28 {
vrrp-group 0 {
virtual-address 87.238.63.1;
}
}

...results in the following error during commit:

  'vrrp-group 0'
virtual address must share same mask with interface ip
error: configuration check-out failed

Not all of my server VLANs have two extra unused addresses, so this is a 
showstopper for my plans to get rid of the Linux boxes.  Is there any 
other way round this apparant JUNOS limitation, I wonder?

Best regards,
-- 
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] any way to backup files as cisco

[Tore Anderson]

* chloe K

   I am wandering whether any backup process is in juniper

   in cisco

   copy running-config tftp

Not sure about tftp, but you can use scp to get hold of the config file:

  scp router:/config/juniper.conf.gz /backup-dir/

Or use scp from the router itself:

  file copy /config/juniper.conf.gz backup-host:

You'll probably also be able to use plain FTP to the router to grab the 
file.

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

Re: [j-nsp] Meaning of except in firewall filters

[Tore Anderson]

Hello,

* Dave Diller

  Why not just do the boolean inverse:

 I use this as well, an accept term followed by a reject-all term, as
 it is easier/cleaner for someone not intimately familiar with how the
 clauses match to read this way, so I worry less abut people
 misinterpreting what I've applied on a casual run through.  Myself
 included ;-)  Much easier to debug, too, case in point.

I could've used two terms (as I wrote in the first email), like Kevin 
suggested.  However the fact that except didn't work as I thought 
made me curious, and I wanted to figure it out.  Besides, I personally 
prefer terse config files - why have two terms when I can have one?

 I use

  from {
  protocol tcp;
  port ssh;

 Is there any particular advantage to either method?  I'm matching
 source OR destination port, and I really only need destination, so
 yours IS a bit more fine-grained...

This would allow an attacker to connect to any port on the device, by 
simply binding the source end of the TCP session to port 22.  The 
atttacker would need to have access to the SSH port to begin with, 
which makes it mostly an academic point I guess.

However, if you were to apply this to a device that was running, say, a 
load balancer with port 80 globally accessible, your way of expressing 
it would allow anyone on the internet to connect to the SSH service 
provided that they bothered to bind the source end of the TCP session 
to port 80.  This is a trivial thing to do, so in my opinion it's best 
to have a habit of always be as specific as possible.

Another thing is that «port» isn't supported on my EX series switches, 
there I have to use {destination,source}-port, so I might as well do 
that on my routers too so I can copypaste the term from them.  Another 
thing that sucks about the EX series is that I can't figure out how to 
debug what's dropped in the firewall filters («syslog» isn't 
supported), so if I reject everything in the fallthrough term it's 
really hard to tell if I've forgot about something or not.  If anybody 
knows of a way to debug filters on the EX I'd be very grateful for any 
tips!

 then {
 log;
 reject tcp-reset;

 I've been using discard here.  Sure, it ties up MY resources as well
 as theirs, but I've also got ssh rate-limit 10 so am not overly
 concerned (and I'm fine tying them up as long as possible).  Perhaps
 if it were a DDOS SSH attack I might start to notice...

I don't see how «discard» will tie up your resources?  «reject» (as well 
as «reject tcp-reset») will cause the router to generate a reply packet 
politely telling the client to sod off, so there's a (miniscule) 
processing overhead to it.  «discard», on the other hand, will just 
silently ignore the packet, so that's the option with the least 
overhead.  None of the alternatives will actually cause the RE to 
handle the SSH connection attempt.

 Curious about the effects of the various options, I just tried a few
 of them.

 'Discard' gives a 90 second timeout and a Connection timed out
 error when you open an ssh connection.
 'Reject' also gives a 90 second timeout but a No route to host
 error. 'Reject tcp-reset' gives an instant timeout and a Connection
 refused, which makes sense given the RST.

 So I suppose it's just a philosophical difference - either way will
 keep them from opening a port, but do you want to keep them busy or
 just send them packing...

I don't think it matters much.  However, if you are only aiming to 
restrict SSH access but leave everything else open (like my example 
term), a connection attempt to a random port will yield a TCP reset.  
If a connection attempt to the SSH port yields something else (an ICMP 
destination unreachable or simply nothing), an attacker will be able to 
deduce that there most likely is an SSH service present, but that it is 
filtered.  If a connection attempt to a firewalled port yields the same 
result as a connection attempt to a closed port, you've denied the 
attacker that little piece of information.  Not saying that this is an 
effective attack mitigation strategy, but it might, depending on your 
level of paranoia, help you sleep slightly better at night.  :-)

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

Re: [j-nsp] Meaning of except in firewall filters

[Tore Anderson]

* Tore Anderson

 [edit firewall filter lo0-input]
 term restrict-ssh {
 from {
 source-prefix-list {
 ssh-allowed except;
 }
 protocol tcp;
 destination-port ssh;
 }
 then {
 syslog;
 reject;
 }
 }
 term fallthrough {
 then accept;
 }

 This didn't work as expected, SSH connections was still allowed from
 any host (both from inside networks found inside ssh-allowed as well
 as from outside).  It seems like the restrict-ssh term never matched.

Thanks to everyone that answered!  I needed to add a prefix list with 
0.0.0.0/0 _without_ except in order to get the desired results, as it 
seems by default 0.0.0.0/0 except is implicitly included and the 
presence of another prefix list does not override it - unless that 
prefix list also contains 0.0.0.0/0.

For some reason I only got the replies in private mail, not via the 
list.  I wonder if others saw lots of answers to my mail or not?  The 
question is in any case answered now;  there's no need for further 
replies.

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

[j-nsp] Meaning of except in firewall filters

[Tore Anderson]

Hi,

I'm trying to restrict SSH access on some of my routers to allow 
connections from just a few known source networks (defined in a prefix 
list called ssh-allowed).  I then came up with the following, and 
applied it as an input filter on lo0.0:

[edit firewall filter lo0-input]
term restrict-ssh {
from {
source-prefix-list {
ssh-allowed except;
}
protocol tcp;
destination-port ssh;
}
then {
syslog;
reject;
}
}
term fallthrough {
then accept;
}

This didn't work as expected, SSH connections was still allowed from any 
host (both from inside networks found inside ssh-allowed as well as from 
outside).  It seems like the restrict-ssh term never matched.

If I removed the except, it worked as I would have thought - 
connections from hosts inside prefixes found in the ssh-allowed prefix 
list was denied, while connections from the rest of the internet was 
allowed.  Of course, this is the opposite behaviour of what I want.

I can work around it by making first a term that accepts SSH from the 
known prefixes, then another term that rejects all other SSH 
connections, and finally the fallthrough that accepts the rest.  However 
this behaviour made me really curious...  Isn't except supposed to 
invert the logic of the match?  That's how I understand the help text, 
at least:

except   Match addresses not in this prefix list

It doesn't seem to work that way, though.  Does anyone know how it's 
supposed to be used?

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

[j-nsp] Inhibiting external announcements of routes for which a larger announcement exists

[Tore Anderson]

Hi,

apologies for the bad subject line - couldn't think of a way to condence 
my question into one line in a good ay.  Let me explain what I'm trying 
to do:

I've got 87.238.32/19 allocated from the RIPE NCC, and I intend to split 
it between our existing Norwegian site and our up-and-coming Swedish 
one.  Most likely I will leave 87.238.32/20 and 87.238.48/21 for 
Norway, and have 87.238.56/21 for Sweden.  We'll and have BGP speakers 
with transit providers and IX connections in both countries.

When everything is working fine I'd like to announce the /19 in both 
places, as the link between the sites should be high-speed enough to 
handle it.  However, should the link between the two sites fail, I'd 
like to immediately stop announcing the /19, and instead start 
announcing the Norwegian /20+/21 in Norway and the Swedish /21 in 
Sweden, so that traffic destined for Norway won't enter my AS in Sweden 
and vice verca.  I expect the backup link between the sites not to be 
fast enough to support that kind of traffic.

It should be simple enough to accomplish this by creating aggregate 
routes for the /20 and the /21s on the routers in their respective 
countries, and a /19 in both places that need all the /20 and /21s as 
contributing members to be active.  However that means that in a normal 
situation I'll announce /19 _and_ the longer prefixes at the same time, 
and I'd like not to pollute the global routing table with superfluous 
prefixes unless necessary (ie. if the link between the countries goes 
down).  I want a setup that inhibits the announcement of the /20 
and /21s to external neigbours if (and only if) the /19 is also 
announced to them at the same time.  Is that possible?

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