Re: [j-nsp] SRX - CPU utilization exceeds

[Phil Mayers]

That's flow based not packet based. You're running it as a firewall rather than 
router therefore any of the typical thinks that overwhelm stateful devices - 
rapid session setup, high levels of ICMP with embedded headers to decapsulate, 
etc - could be causing it.
-- 
Sent from my mobile device, please excuse brevity and typos
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX - CPU utilization exceeds

[Phil Mayers]

Datasheet numbers are often optimistic.

Is the device forwarding in flow or packet mode? If flow mode, what type of 
firewall services (appfw, IDP, etc.) and what is the session rate like? What 
does the bytes/packet distribution look like?

On 19 September 2017 08:47:51 WEST, sameer mughal  wrote:
>Thanks a lot for the reply.
>
>However, as per the available SRX datasheet they can manage 300Mbps
>throughput so why it is showing high CPU in btw 60 to 70 Mbps. This is

-- 
Sent from my mobile device, please excuse brevity and typos
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX 3300 vs EX 3400 for access layer

[Phil Mayers]

On 14/09/17 16:54, John Kristoff wrote:

Friends,

Our engineering team is reviewing and contemplating whether to stick
with the Juniper EX 3300 switch at the edge access layer (to user wired
ports, some VoIP phones, and some wireless APs also connect to these).

Typically these devices can last out in the field for five or more


You haven't mentioned it, but worth noting that the EX3300 cannot filter 
IPv6. This is a hardware limitation, and caused us to reject the EX3300 
in favour of the (frankly rather overkill) EX4300.


I believe this is resolved in the EX3400, but we haven't had one in for 
testing.

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

Re: [j-nsp] EX3200/4200 ipv6 match conditions in family ethernet-switching

[Phil Mayers]

On 10/04/17 02:10, Jason Healy wrote:

I've been burned plenty of times by the (lack of) IPv6 feature
parity, so I'm hoping the list's collective wisdom can save me from a
lot of extra testing and phone calls with JTAC...

TL;DR: are ANY layer 3 match conditions supported for IPv6 in family
ethernet-switching on the EX3200/4200?  The documentation says no,
but the config says yes (at least for certain special cases).


I can't speak to the 3200, but I do know the EX3300 definitely does 
*not* support v6 matches in family ethernet-switching. We went through a 
long discussion about this with Juniper and eventually it was confirmed 
this was a forwarding hardware limitation by both JTAC and our account team.


We stopped buying them as a result (fortunately we had only bought a 
few). Since the 3200s are older than 3300s, I'd guess the answer is no.


My memory is hazy, but I think we saw the CLI accept but ignore partial 
v6 config, same as you are seeing, so I'd guess CLI bug on that score.


FWIW the EX4300 does not have this problem. Haven't tested the EX3400 
yet but I'm hoping they've got parity there, too...


I agree the Juniper docs are confusing on this topic (and many others 
sadly...). I cannot decide if this is just poor writing or a deliberate 
attempt to disguise the lack of feature parity by being as confusing as 
possible... Part of the discussion we had with Juniper on the topic was 
confirming exactly which interpretation of the docs you reference was 
correct, and the answer was "the one without IPv6 support" :o(


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

[j-nsp] EX4300 SFP+ sometimes recognised incorrectly on boot w/ 14.1X53-D40.8

[Phil Mayers]

All,

This is an odd one - we are having a hard time reproducing it on the 
bench, but we've seen it on production hardware quite a bit.


Some portion of the time, with an EX4300 VC running 14.1X53-D40.8, we're 
seeing VC members boot and mis-detect the SFP/SFP+ module in the PIC (4x 
1/10G SFP).


We'll see modules mis-detected as 1G when they're 10G and thus the 
interface fail to come up; an SFP re-seat or PIC restart is required to 
clear the issue.


I have a very, very vague suspicion that it might be corruption of an 
on-flash file due to sudden poweroff (i.e. removing the plug) but this 
is completely unsubstantiated.


Exact same HW combos (switches, SFPs) were working fine on previous 13X 
releases.


We're still trying to repro and are going to open an initial exploratory 
case with Juniper, but just in case, is anyone seeing SFP/SFP+ 
mis-detected on this HW/SW combo?


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

Re: [j-nsp] VC ports on EX4300

[Phil Mayers]

On 14/02/17 11:34, Anthony Johnson wrote:

If you're skirting the 150 meter line, I would HIGHLY recommend going
single mode also. It will save you headaches down the line.


Personally I would recommend singlemode pretty much everywhere. Unless 
you are using a *seriously* large amount of fibre and xcvrs the cost 
savings just aren't worth the distance hassles IME.

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

Re: [j-nsp] VC ports on EX4300

[Phil Mayers]

On 14/02/17 11:17, Valentini, Lucio wrote:

Hi there,

I was wondering what speed  of VC port is necessary if I have 10 Gbps


Well, that depends on your use-case; if you're only moving 100Mbps 
between VC members then you don't need 40Gbps VC ports.


You really need to understand your traffic pattern to make an informed 
choice here.

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

Re: [j-nsp] MX104 capabilities question

[Phil Mayers]

On 07/07/16 02:21, Gavin Henry wrote:


That last sentence is quite a sweeping statement about C.


The underlying basis for the statement - C is a hard language to program 
well - is not at this point a controversial one, IMHO.



You can make great software in any language. I think this argument is
false.


I think the argument has a lot going for it.

C is a difficult language to use well; even developers with decades of 
experience get caught out by the subtleties of things like pointer 
aliasing and integer behaviour. There's a huge research effort by smart 
people to improve that situation - as an example, things like ubsan in 
Clang to detect and warn on use of undefined behaviour. John Regehr's 
blog is a good read on the topic of how gnarly C can be, for those 
interested.


I think it's totally reasonable to argue that other languages can fit a 
problem set better than C, can reduce the cognitive load on the 
developer, and can prove more amenable to things like static analysis 
and automated testing.


Other languages could include, here, a restricted subset of C with 
least-surprise behaviours. But TBH, given the focus on multicore, I 
think a language with better support for concurrency would be a more 
appropriate choice (Erlang was mentioned; it's a shame that never took 
off, it's really ideally suited for the task of network protocol speaker).


Developers are people, and recognising the human limits of the process 
is important. Frankly, I would agree with the notion that C is a very 
poor choice for almost anything outside hardware-level work (kernel, 
driver) these days, simply because CPU is cheap, and human cognition 
expensive, and higher level languages trade costs in former for savings 
in the latter.


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

Re: [j-nsp] EX4600 QSFP+

[Phil Mayers]

On 10/06/16 17:06, Kevin Day wrote:


This is kind of a hack but probably would work:

http://www.10gtek.com/qsfp-extender

One of these on each end with 10G ZR or 80km DWDM optics.


Ha, that's quite clever. Thanks for the link, potentially useful thing 
to have in the toolbox.

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

Re: [j-nsp] EX4600 QSFP+

[Phil Mayers]

On 10/06/16 16:55, Paulhamus, Jon wrote:

Hello Group -

Is anyone aware of any optics for an EX4600 QSFP+ that reach 80km?


I have never seen such a thing. Traditional line-encoding would I think 
need dispersion compensation for that bitrate at that distance; you may 
end up using a DWDM muxponder w/ coherent line-side or similar if you 
really need to reach that distance on 40G.


Interested to hear if anyone else knows of a pluggable that works at 
that bitrate/distance combo, though?

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

Re: [j-nsp] Commit script portability between ELS and non-ELS platforms

[Phil Mayers]

On 07/06/16 21:51, Rob Foehl wrote:

Does anyone have any clever methods for probing Enhanced Layer 2
Software support from a commit script on QFX/EX in order to generate
changes appropriate to the platform?  Specifically looking for something
beyond checking hardware and version numbers, or for pieces of config
hierarchy that might not be present on any given box either way.






...returns substantially different XML b/w ELS and non-ELS IIRC. An EX3300:

http://xml.juniper.net/junos/12.3R12/junos;>
http://xml.juniper.net/junos/13.2X51/junos;>
That's how our off-box Junoscript code decides between ELS and not. 
Should be easy enough from an op/commit script.

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

Re: [j-nsp] SRX 1500

[Phil Mayers]

On 19 May 2016 23:01:31 BST, Dale Shaw  wrote:


srx1500 uses the new disaggregated software model, so it's $11K for
hardware only; you still need to buy software (Junos).



The prices we've seen for the mpls license on the 1500 are an eye 
watering multiple of the hardware cost. Nearly double. Same for the 345.


Slightly less objectionable for the 340. They appear to be charging the 
software license per-megabit/s :o/


This substantially reduces the attractiveness of the range for me.

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

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Phil Mayers]

On 10/05/16 21:47, Aaron wrote:

I have been curious about the cisco catalyst 6800 line… seems that the 6840 
might fit this realm of smaller mpls pe… not sure of price…


The Cat6k including 6840 can certainly do a fair number of MPLS 
features, we use their older brother (6880, sup2T) and for a little 
while longer predecessor (sup720) as MPLS PE in L3VPN (inc. 6vPE), MVPN 
and some small amount of L2VPN (mainly EoMPLS)


IIUC the layer2 and MVPN stuff is lagging the state of the art quite a 
bit on that software train, which might be an issue for you.


The per-port cost will be relatively high compared to a merchant 
silicon-based device, but the features tend to be a bit better. Port 
density is also kind of low on the cat6k sadly.


They also run plain old IOS, with it's paucity of modern comforts (like 
any form of API, or transactional commits, etc.). Slightly weedy CPU, 
especially if you use Netflow on them (do not get me started...)

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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[Phil Mayers]

On 27/04/16 16:58, Per Westerlund wrote:

That is default behavior, but you can access other RI's interfaces by 
explicitly using the RI name. No way to reach all IFs at once via a RI.


I'm a bit confused now.

I just tested (SRX240H running 12.3X48-D15.4) and I can see all 
interfaces when hitting an IP inside a routing-instance, as well as in 
inet.0.


We do *not* have "routing-instance-access" under the "snmp" block, but 
can still make SNMP queries to a routing instance; the docs suggest this 
should not work, so I'm not sure what's going on.

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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[Phil Mayers]

On 27/04/16 16:45, James Bensley wrote:


Does Junos restrict the SNMP output to that which relates to the
routing instance only, when polling in a routing instance?


We have JunOS boxes with routing instances, and see the same when we 
poll them from inet.0 or a routing instance.




username@mxrouter> show configuration snmp
community SecretCommunity {
 authorization read-only;
 routing-instance SNMP-TEST {


You've configured this community string to map to a routing-instance. 
Try removing it this config item, and just putting the "clients" 
directly under the community.

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

Re: [j-nsp] QFX mc-lag and v6 ND

[Phil Mayers]

On 05/02/16 14:40, Adam Vitkovsky wrote:


-that's the only occasion the internet where NDP and MC-LAG in listed
the same sentence, which is not a good sign on its own. But no
explanation about how it is done, especially the part about how the
ND Cache is maintained between the LAG members, which clearly is what
is not happening in your case.


I must be missing something - why would a LAG of any type do any special 
processing of ND (or ARP, for that matter) traffic? All it has to do is 
forward the reply appropriately e.g. across the MC-LAG control link if 
the dest MAC is the peer switch or multi/broadcast.


Obviously if you're doing some sort of active-active L3 forwarding on 
top of the MC-LAG then special things need to happen - but did OP say that?


Or is there some subtlety (dumb-lety?) about the way Juniper do this?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF in Junos

[Phil Mayers]

On 24/12/2015 09:10, Phil Shafer wrote:


The real value is that the API comes for free, since it's using the
same internal plumbing.  This means that when a feature ships in
the CLI, it's immediately available in the API.  No lag.  No
additional cost.  No missing bits.  It's literally all there (with
the exception of terminal-oriented commands like "monitor interface",
etc).


I keep having to explain to other vendors and fellow engineers why this 
approach is so valuable, and so inherently superior to off-box 
middleware "API" solutions or obfuscated "SDK" blobs.


What's the cause of the few/occasional commands where "| dis xml rpc" 
doesn't work (e.g. "show virtual-chassis | display xml rpc")? I'm 
assuming CLI must know how to format it as XML to send it to MGD.


In the example I've given I think that command might be an alias to 
"show virtual-chassis status" as the output is identical and "| dis xml 
rpc" does work there. I've come across a few others, but memory is 
failing me this close to Christmas!



Sorry if this got a bit long, but honestly it was a soft pitch and
I couldn't resist bragging about my baby.  ;^)


You should be justly proud of it. JunOS has its faults, but it's API and 
config model are the best in the industry by a very large margin IMO.


FWIW the only two things I can cite as dislikes are the 
infinite-stream-of-XML for Junoscript (solved in Netconf of course) and 
the somewhat inexplicable embeddeing of the running software version (as 
opposed to a semantic version) into the various /junos-* XML namespaces, 
which makes them a bit of a bore to process with a namespace-strict XML 
library.


But both of those are trivial to resolve, compared to (say) running 
expect against an ever-changing human-readable CLI!


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

Re: [j-nsp] SRX performance

[Phil Mayers]

On 20/12/15 14:16, harbor235 wrote:

Can anyone share real world SRX performance? ?I am looking at the SRX220
or SRX240 for a small website ~150-200Mbps in a co-location environment.
The performance charts state the SRX220 can do 300Mbps with a mix of
traffic and  up to 900Mbps with mostly large packet sizes.


Is this in firewall or packet mode?

We've seen very decent performance from the SRX2xx given their prices; 
I've had one-way l2circuit throughput of >600Mbit/s in packet mode from 
an SRX210, which is frankly astonishing given the price.

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

Re: [j-nsp] Could JUNOS OP Script support generate firewall filter term and added before original one?

[Phil Mayers]

On 17/12/15 14:27, Chen Jiang wrote:


term in the firewall filter, I haven't find any method to insert the new
term before the original last "accept all" term and it will make traffic
never hit the generated new term.


Can't you just add the policy then reorder it using the standard syntax 
before doing the commit:


http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/junos-xml-management-protocol-guide/index.html?topic-49517.html

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

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Phil Mayers]

On 11/12/15 17:16, Chuck Anderson wrote:


For those of us who wish to/need to use commercial NMS software, are
there any that support NETCONF?  And NETCONF isn't the answer yet
anyway to cross-vendor standardization, at least not until standard
YANG models are developed.  At least Q-BRIDGE-MIB exists as a
standard.


On the commercial NMSes, no idea. I would hope that commercial products 
would provide a way to integrate external datasources, but maybe not.


I take your point about Netconf versus SNMP, and I don't disagree with 
you that Juniper should really fix this - "it's been broken for ages" is 
a pretty poor excuse, they could always provide a config knob to toggle 
on the new behaviour.


But I just don't see them fixing it.

Re: YANG - at this point I'd take reliable, comprehensive APIs with 
*any* reasonably sane, documented data models, standard or otherwise. 
We're a long way from being able to rely on standard data models IMO, 
which is unfortunate but a reality.

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

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Phil Mayers]

On 11/12/15 15:11, Ross Vandegrift wrote:


I never ran into this, but it's not too surprising - I had unending
problems with poor Q-BRIDGE-MIB.  We used at least Junos, Procurve, and
a few flavors of IOS 12.  Only HP had a Q-BRIDGE-MIB that was correct
enough to use - and if you poked it wrong, the switch would crash.


Likewise, I've seen problems with the Q-BRIDGE on Extreme and Cisco. 
I've always ended up using some vendor-specific method (except for the 
pre-Huawei 3Com kit, which had excellent SNMP support in full standards 
compliance AFAICT).



On Junos, I got sick of all this and switched to netconf.


+1 (though Junoscript, in my case)

ssh admin@switch 'show ethernet-switching table | display xml'

...is always the poor-mans version ;o)

SNMP was an impressive effort for its time, and it could have been 
great, but it's getting less and less usable as vendors pay less and 
less attention to it. I've seen a number of devices from a number of 
vendors get *worse* SNMP support over the last couple of years / 
software releases.


In addition for something like the P/Q bridge FDB, the requirement for 
the table to be sorted by OID can often be a substantial CPU impact, as 
naive implementations sort the table on every getnext.

___
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

[Phil Mayers]

On 01/12/15 13:21, Tore Anderson wrote:

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

[...]


Yuck. Does it happen if you send the same command over Junoscript rather 
than Netconf? I don't see this on Junoscript talking to 11.4R7.5 or 
13.2X51-D35.3. It might be a Netconf-specific thing.

___
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

[Phil Mayers]

On 01/12/15 14:07, Phil Mayers wrote:


Yuck. Does it happen if you send the same command over Junoscript rather
than Netconf? I don't see this on Junoscript talking to 11.4R7.5 or
13.2X51-D35.3. It might be a Netconf-specific thing.



...but I do see it over netconf. Sigh, looks like another Junoscript != 
Netconf issue :o(

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

Re: [j-nsp] Multi Core on JUNOS?

[Phil Mayers]

On 22/10/15 13:05, Saku Ytti wrote:

On 22 October 2015 at 14:31, Adam Vitkovsky  wrote:

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)


IOS-XR seems to have fair share problems with the IPC :)



In fairness, concurrency is "teh hardz" on any platform, in any framework.

You can use threads and shared memory then problems two you have.

You can bodge it by serialising everything and pushing data between 
threads/processes with queues and using craploads of locking, but you 
typically want fast CPUs for that. Or you can cheat and coop multitask, 
but then you're back at IOS classic / JunOS rpd.


You can write it in a concurrent-friendly language like Erlang (or maybe 
Go) but then you have problem employing developers on the cheap, and 
have to discard your existing codebase (yikes!)


I'm sympathetic to Juniper/Cisco/etc. here - they've got huge codebases 
they can't afford to discard because of the years of accumulated 
real-world behavioural tweaks, but proper concurrency typically involves 
ground-up design principles.


It's not a solved problem yet :o(
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Mayers]

On 22/10/15 15:06, Raphael Mazelier wrote:


The approach to run rpd on one core, and other process on avaibles one
is a quick win. And optimizing the actual code before thinking in
paralelism may be a faster approach to make speed gain ?


Sure, moving the rest of the OS onto other cores is a no-brainer; 
they're already crossing a process boundary.



Btw Junos on intel RE is fast enough for me. But not all on other cpu,
specially on EX/QFX one... Perhaps Juniper should install x86 cpu on
switch too (other vendor do this).


Better CPU choices would help a lot of devices ;o)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4300 and full-duplex-only

[Phil Mayers]

On 28/09/15 11:52, Jackson, William wrote:

The ex3300 does not have this limitation.



FWIW, Juniper have come back and said this is a firmware limitation in 
the PHY. Apparently it's some sort of feature conflict or code space 
issue w.r.t. MACSEC, and there is some vague possibility of a release 
with an either/or MACSEC/half-duplex in the future.


:o/

Agree the 3300 has no such limitation.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4300 and full-duplex-only

[Phil Mayers]

Does anyone know the backstory to this? We just found out this platform 
doesn't support half-duplex - at all - and it was an unpleasant 
surprise, as it means some old SCADA and instrumentation can't link-up 
against an EX4300.


I'm assuming they skimped and left out the hardware for detecting RX and 
queueing TX, but wonder if there's something I'm missing.


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

Re: [j-nsp] EX4300 and full-duplex-only

[Phil Mayers]

On 23/09/15 14:38, Peter Tavenier wrote:


There is only a note of duplex, not about the speed:


Indeed.


Note: On EX4300 switches, the interfaces operate in full duplex mode only.

I do see on a EX4300 some links in 100Mb and 1000Mb, don’t have 10Mb devices 
attached.

Not sure why this is.


If you mean "why it's only duplex limitations", I'm guessing the device 
is missing the collision-detect/retransmit hardware for cost reasons. 
10/half is pretty rare these days and, in theory, they're pitched as a 
datacentre device (though we have an IBM tape library which is 10/half 
on it's management port).


You can force the link up by disabling autoneg, but that comes up 
duplex-mismatched - 10/full at the EX end, 10/half at the device end.


All very disappointing; we did not think to specify "must comply with 
IEEE 802.3" in the RFP :o/

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

Re: [j-nsp] EX4300 and full-duplex-only

[Phil Mayers]

On 23/09/15 14:30, Chuck Anderson wrote:

Really?  So you can't use EX4300 at 10 Mbps (I don't know of any
devices that support 10/Full)?  If this is true, it is a
purchase-stopper for us.


10/full works fine.

10/half (or 100/half) does NOT work:

http://www.juniper.net/documentation/en_US/junos13.2/topics/task/configuration/ex-series-gigabit-interfaces-cli-els.html

"""
Note: On EX4300 switches, the interfaces operate in full duplex mode only.
"""

We've confirmed this by inspecting the autoneg caps advertised from the 
device; all half-duplex modes are absent.

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

Re: [j-nsp] SRX240 for route-reflector?

[Phil Mayers]

On 17/08/15 08:58, Stepan Kucherenko wrote:

No. Just don't.

SRX has 1 weak MIPS CPU for control plane and it's incredibly slow
(commits took ages). Just get a couple of vMX/vRR and use them as a
VM on a non-outdated x86 server, it'll work great.


Agreed. They're nice cheap boxes for a range of use-cases, but I 
wouldn't use one for an RR - way too slow control plane, no dual PSU.


As others have said, vMX/vRR or CSR 1000v for route-reflectors are IMO 
the obvious choice now; we'll move to that when our M7i REs run out of 
steam.

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

[j-nsp] vstp/pvst interop issues with non-Cisco

[Phil Mayers]

All,

Has anyone run into problem with vstp/pvst interop with non-Cisco 
vendors, specifically Extreme XOS?


We have a legacy STP-based environment that will be going away soon, and 
putting an EX 4300 running 13.2X51-D26.2 into it caused a loop.


It appears the Extreme sends PVST PDUs with a trailing \x00 byte, which 
is reflected in the Ethernet length (a.k.a. ethertype) field.


Cisco seem to ignore this, but the Junipers seem to be dropping it. 
Worse, they're not logging/counting the drops - it's silent, even with 
flag all traceoptions on the vstp instance.


I'm not really interested in who is right and who is wrong with the 
on-the-wire format of the PDUs, but the silent drop thing is irritating...


Anyone else seen this?

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

Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports

[Phil Mayers]

On 14/07/15 13:18, Mark Tinka wrote:



On 14/Jul/15 14:12, Luis Balbinot wrote:

Take a look at the EX4550. Just pay attention on the number of routes it
supports and see if that suits you. It's not a core router, but neither is
the ME3600.


OP is looking for a 1U switch that is really a router with full IP/MPLS
capabilities, but has reasonably dense 10Gbps port assets.

The EX4550 falls very short of that re: full IP/MPLS capabilities.


QFX 5100?

Juniper cited that to us as a collapsed MPLS L3VPN P/PE and claim pretty 
good features. Not tried one yet.

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

Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports

[Phil Mayers]

On 14/07/15 14:36, Richard Hartmann wrote:

On Tue, Jul 14, 2015 at 2:54 PM, Phil Mayers p.may...@imperial.ac.uk wrote:

QFX 5100?


My experience with that platform and 14.1 has been very unpleasant.
13.2 does not support MPLS PE.


Yikes. That's good (well, bad, but you know what I mean) to be aware of.





Juniper cited that to us as a collapsed MPLS L3VPN P/PE and claim pretty
good features. Not tried one yet.


Interesting; not for L2VPN?


L3VPN was our use-case; it may or may not do L2VPN, we don't have much 
use for it locally.


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

[j-nsp] RTPERF_CPU_THRESHOLD_EXCEEDED on SRX3600

[Phil Mayers]

All,

We've seen a constant, very infrequent background of these messages on 
our SRX 3600. This is apparently expected - brief spikes in load.


In the last few days, we've started to get these constantly.

The offered load in terms of bits/sec, pps, sessions/sec, concurrent 
sessions and other metrics hasn't changed - in fact it's dropped 
slightly as our term ends - but obviously something has.


Port mirroring of the interface facing the firewall along with netflow 
analysis of the upstream routers doesn't show any standout traffic, but 
the volume and diversity is so large that it could be a single thing 
that we can't see in normal metrics.


There's no particular config change - just the usual addition of hosts 
to/from groups.


Our reseller has given us no useful information on how to diagnose the 
cause of this sudden step change - just the usual useless show chassis 
routing-engine, apparently failing to understand the distributed nature 
of the SRX.


What do people generally do to track even the most basic info about the 
source of this kind of thing? I'm thinking even an attribution to input 
interface and functional area (policy processing, appid, traffic 
forwarding, policy logging, etc.)


The volume of traffic makes a flow trace unworkable.

show security monitoring ... doesn't show much, except the CPU spikes - 
no session spike, no obvious issues.


Any ideas? Any way to attribute FPC CPU usage by functional area and 
time window?


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

Re: [j-nsp] Juniper SRX3600 have a bug i think

[Phil Mayers]

On 15/05/15 20:27, Cahit Eyigünlü wrote:

root show security monitoring performance


This came across mangled for me; all wrapped into one line, so unreadable.


SRX start dropping packets after 500k pps of the udp attack.


That sounds about right.

The 3600 spec sheet claims ~270k sessions/sec for TCP 3-way handshakes. 
So, I'd expect the policy inspection speed to be about that, so 500k PPS 
UDP seems about right for the box to fall over, for relatively unique 
5-tuples.


Firewalls are not routers. They don't perform well in this kind of 
scenario, IME.



We can not use threshold limit because it drops the real connections too while 
under attack.


What is threshold limit. Do you mean the screen options?


we cannot use session limit because the attack does not create session


Do you mean that you have a deny policy, hence no sessions? Or you 
have a permit policy, but the session isn't being created for some 
other reason?


The solution to your problem will depend on what the traffic looks like. 
What does the distribution of source and dest IP/port look like in your 
UDP flood?


You could consider using S/RTBH in front of the firewall, driven by 
something like netflow/sflow; have a router eat the traffic statelessly 
before it hits the expensive stateful processing.


We actually use the screen function in logging-only mode, and process 
the logs in realtime to do trigger S/RTBH. This allows us to whitelist 
some stuff that tends to false-positive the screens, as well as 
implement better timeout/backoff behaviour, while still using the SRX to 
do the counting.


TBH you haven't really given enough information.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos BGP update generation inefficiency -cause for concern?

[Phil Mayers]

On 18/05/15 12:49, Saku Ytti wrote:


I'm personally not too excited about templates in IOS, as I tend to
have only like 3-5 peer-groups in IOS, and if I translate the config
to template based, the amount of lines in my config increases. I think
the break-even would require rather large amount of groups.


Yeah, the templates aren't as nice as they could be in IOS; the 
particular syntax they chose makes the config messier, not cleaner. We 
dropped back to peer-groups when I re-visited our BGP configs.

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

Re: [j-nsp] SRX3600 Problem

[Phil Mayers]

On 22/04/15 13:20, Farrukh Haroon wrote:

Hi Cahit

Your assumption about the order of operations seems to be wrong. If the
screen is before the filter, then how come the pings are blocked before
you start your attack script? Since your initial pings are blocked this
means the filter is working (at least during normal loads)..

It is more likely that your are either hitting a bug or the box is
incapable of the DOS generated from your script (which is running on a
high speed LAN network) and packets are getting slipped/missed from the
filter and leaking to the screen check...


Cahit sent me some information off-list which I encouraged him to 
re-post here so others can contribute.


From what I understand, they're finding the screen options are not 
working, presumably because it's a DDoS and there are too many sources 
for source-based to work; and destination-based of course blocks the 
target victim.


As such, they're trying to use IDS/IDP rules to block the traffic, but 
the box is falling over under the load.


Cahit, is this correct?

We've reached the limits of my experience; it sounds like a big DDoS, 
and stateful filtering may not be able to handle the load. It's probably 
a question for JTAC.


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

Re: [j-nsp] Helo Juniper, your docs need work..

[Phil Mayers]

On 12/02/2015 21:55, Chris Morrow wrote:


EX3300 switch
EX6200 switch

Uhm, this is the year 2015, the device was built and designed in ~2013 ?
and no ipv6 ? WHAT?


Yes, we shouted at them about that. Hardware limitation. Can't be fixed, 
we were told. Made the EX3300 unsuitable for our needs since you can't 
do any form of RA guard, which is unfortunate as it's otherwise a nice box.

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

Re: [j-nsp] Helo Juniper, your docs need work..

[Phil Mayers]

On 13/02/2015 00:08, Olivier Benghozi wrote:

By the way in current JunOS 12.3 it looks there's at least one fix; in:
http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html
 
http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html

they write that You can apply port, VLAN, or router firewall filters to both IPv4 
and IPv6 traffic on these switches:
[...]
• EX3300 switch
• EX6200 switch
[...]


That's an extremely misleading bit of text that I had a very grumpy 
conversation with Juniper about.


You can indeed apply the firewall filters to IPv6 traffic. But you can't 
specify any IPv6 protocols fields as matches.


So w00t a default deny or ethertype deny will apply to IPv6 as opposed 
to skipping it entirely.


EX3300 apparently has no IPv6 field matching capability in hardware. 
Which is almost unbelievable for a current-gen switch, but that's what 
Juniper told us, repeatedly.


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

Re: [j-nsp] Helo Juniper, your docs need work..

[Phil Mayers]

On 13/02/15 15:14, Chris Morrow wrote:


my guess is that this works because it's implemented as a loopback
filter... so really it's a filter on the CPU on the ex3300 and NOT done
in the hardware at the forwarding parts.


If it claims to be RA/ND guard, it can't be.

My guess is that they're punting based on layer2 MAC range, which has 
interesting implications for CPU performance.


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

Re: [j-nsp] Helo Juniper, your docs need work..

[Phil Mayers]

On 13/02/15 14:14, Olivier Benghozi wrote:


that you could use next-header on EX including 3300, but only on
layer3 interfaces, not port or vlan...


Sure - no family ethernet-switching support.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Helo Juniper, your docs need work..

[Phil Mayers]

On 13/02/15 10:34, Harald wrote:

On 13.02.2015 11:13, Phil Mayers wrote:

Yes, we shouted at them about that. Hardware limitation. Can't be
fixed, we were told. Made the EX3300 unsuitable for our needs since
you can't do any form of RA guard, which is unfortunate as it's
otherwise a nice box.

RA-guard was implemented in 14.1X53D10 on EX2200 and EX3300 along with
ND-inspection, IPv6 source-guard and DHCPv6 guard/snooping.


I vaguely recall them saying they were going to do this. Have you tried 
it? Does it work ok?


If that was all we needed, that might be sufficient, but we were 
reluctant to buy a device which would be in service for 3 years or more 
without the ability to block on IPv6 address / UDPv6/TCPv6 ports.

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

Re: [j-nsp] RTPERF_CPU

[Phil Mayers]

On 29/10/14 18:40, Paulhamus, Jon wrote:



Seeing this on firewalls with very little throughput up through more than 2Gps 
of throughput.


Are you doing any AppXXX e.g. AppID, AppFW, etc.?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF vs SNMP for monitoring

[Phil Mayers]

On 30/08/14 17:30, Tyler Christiansen wrote:

SNMP is less resource-intensive and faster than NETCONF.  I would use SNMP
for the things you can and NETCONF for the things you can't.  If you


I would agree with this, based on our extensive playing. We tend to 
monitor with SNMP, configure with Netconf/Junoscript.


Couple of additional points:

 1. Sometimes the SNMP MIB is really horribly organised either from a 
performance point of view (OIDs shall be ordered by prime factorial of 
birth date - hateful if you need to fetch a whole table of 10k rows to 
get one item) or needing to fetch a jillion separate tables to get the 
final result. In this case, Netconf *may* be faster but...


 2. ...you need to account for the overhead of setup/teardown of the 
Netconf session, particularly the SSH/HTTPS key exchange. On low-end 
devices (EX3300) the CPU were sluggish enough that we opted for plain 
TCP transport Junoscript, relying on the firewalled management VLAN for 
security. Try to catch everything in one Netconf session - Tyler's point 
about async/threading is very relevant here.


 3. Occasionally you'll find things not exposed over SNMP; obviously 
then Netconf


 4. Finally, you may find that bulk data collection - e.g. all the 
counters, all the ARP / ethernet switching table entries - is quicker 
over Netconf. SNMP results need to be OID-sorted which can be slow, but 
also the TCP transport can end up being faster than UDP. Test and see 
which works, but also beware faster collection may mean higher CPU on 
the monitored device.

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

Re: [j-nsp] 12.1X for SRX

[Phil Mayers]

On 22/08/14 23:44, Quoc Hoang via juniper-nsp wrote:

Hi, JTAC recently updated their recommendation for SRX to 12.1X which
specifically supports the security platform. We are currently on the
11.4  train (for both branch and HE) but evaluating the latest 12.1X
as a possible next rev.  Any stability concerns or major bugs that we
should be aware? Would be interested in hearing everyone's
experiences.


As others have said, running X46-D10.2 on SRX3600, no real problems. 
Some minor issues with earlier X4x release, mostly cosmetic aside from 
SPC crash-bug with request support info on X45.

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

Re: [j-nsp] juniper switch ex2200 how to find port from ip address?

[Phil Mayers]

On 26/08/14 12:22, Evangelos Kanarelis wrote:

Hello everybody

I am relatively new to networking and I am currently managing a few
EX2200 switches.

I need to find to which port a machine is connected to, but all I
have is an IP Address. I know that I can use show ethernet-switching
table brief but unfortunately I do not have the MAC address.

Any help would be greatly appreciated.


When you have time, consider looking into running something like 
Netdisco against your switches and routers.


Without a MAC, it's not straightforward.

It's not really difficult either, but if you're new to networking all 
the suggestions I can think of (put an IP address on the ports vlan, 
ping the host, look in the ARP table; put a logging firewall filter in, 
look for matches; enable DHCP/ARP snooping) carry a risk of breaking things.


It would be a lot easier if you could find the MAC address from the 
router. Can you really not do that?


Or if you can get to the host, just unplug then re-attach the host, then 
look in the switch logs for which port just came up.


If not, the safest thing is probably to modify the switch to have an 
IP address on the port VLAN and ping the host, then find the MAC from 
the ARP table like so:


== Add the IP to the vlan ==

configure
set vlan name l3-interface vlan.tag
set interfaces vlan unit tag family inet address ip/mask
commit

== Find the IP/MAC/port ==

run ping ip count 1
run show arp no-resolve hostname ip
run show ethernet-switching table | match MAC from the ARP output

== Undo adding the IP

rollback 1
commit

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

Re: [j-nsp] Netconf namespaces

[Phil Mayers]

On 25/06/14 02:32, Phil Shafer wrote:

Phil Mayers writes:

The fundamental question is: are namespaces used incorrectly all over
the place in Netconf?


JUNOS has some namespace issues, suffering from both pre-rfc
implementation problems and attempts to re-use the underlaying
Junoscript XML API code.  PR 826463 is addressing these.


That's useful to know. Whether other vendors accept that these are 
issues (cough cisco cough) is another matter... ;o)



Namespaces are a two-edged sword, and while they are great for
telling you _exactly_ what data you are seeing, this exactness
is often painful.


I guess.

OTOH I've seem XML come back from some devices like this:

rpc-reply
  namspaced:tag
 ...

i.e. no xmlns for the namespace on a tag. This is just broken, and 
really hard to deal with using normal XML libraries.


I don't think netconf wants to end up like XMPP where you have to use a 
custom XML parser and serialiser just to make it go, at which point you 
might as well not have used XML. We're still early enough into Netconf 
that we might be able to dodge that, if enough people push back on it.



 ns junos = http://xml.juniper.net/junos/*/junos;;


Yeah, that's kind of annoying... I do wonder why you didn't rev the 
version number on dialect changes rather than software version cahnges, 
but I guess it's too late to go back on that one.


Anyway thanks for the feedback - it's always reassuring to know people 
at the vendor side are paying attention.


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

Re: [j-nsp] Netconf namespaces

[Phil Mayers]

On 18/06/14 07:52, Balasankar Rajaguru wrote:


[balasank]  This is a bug in JUNOS. This has been reported already
and the fix is available from 13.1.


Awesome good to know.


[balasank] JUNOS doesn't validate the namespaces in 'rpc' as it goes
by the postal principle which says be conservative in what you send,
but liberal in what you receive. Thereby we receive the RPC requests
happily without namespaces..


I guess. What about rpc payloads, thinking in particular config XML blocks?


[balasank] Apart from hello, There are quite a few places where Junos
deviates from spec, we have bugs filed up for the same.


Cool, thanks for the feedback.

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

[j-nsp] EX3300 IPv6 filtering

[Phil Mayers]

All,

tl;dr - don't be misled by the release notes item for 12.3R6, EX 3300 
*still* cannot match IPv6 fields in ethernet-switching filters.


Some of you may have spotted the following:

http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html


You can apply port, VLAN, or router firewall filters to both IPv4 and 
IPv6 traffic on these switches:

...
EX3300 switch


...and also the 12.3R6 release notes which mention PR954496 and say:


Starting with Junos OS Release 12.3R6, you can configure new match 
conditions, actions, and action modifiers for IPv6 firewall filters on 
EX2200 and EX3300 switches



For the avoidance of doubt; it is NOT possible to write an 
ethernet-switching firewall filter which matches IPv6 header fields on 
12.3R6.6, and this is confirmed as expected behaviour by JTAC.


The above release notes item (according to JTAC) refers to loopback 
firewall filters, and the aforementioned URL apparently means filters 
you write will apply to IPv6 packets, not you can write filters 
matching on IPv6 fields.


So you can block IPv6 packets by MAC address... w00t...

JTAC were not forthcoming on whether this is a current or forever 
limitation, and our account team have not yet been able to give us an 
answer.


2014 and it can't match an IPv6 address. Great going Juniper! /sarcasm
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netconf namespaces

[Phil Mayers]

On 17/06/14 14:49, Keegan Holley wrote:


I've looked at the PyEZ and ncclient code, and basically they seem
to take the approach of just throwing away all namespace
information. This seems icky to me, and make me wonder if Netconf
is going to be another SOAP - so many implementation errors that
interop ends up being a mess of special casing and workarounds.



Do you really need the namespaces?  If different vendors use the same
tags for different things you’ll still have to write code to deal
with it whether you have a namespace to warn you or not.  Maybe I’m
missing something.


It's not really a matter of need. They're mandatory per the Netconf 
spec. It's not some optional thing you can dispense with if you don't 
like it, or because your COBOL libraries don't do them properly or some 
other reason.


If vendors are generating XML without required namespace declarations, 
you can't validate the returned XML against the schema for the protocol, 
or for example against their published Yang data model.


If you can't do that, you can't be sure it's well-formed semantically. 
You end up embedding all kinds of turn your head and squint 
workarounds, and we're back to being only slightly better off than 
parsing Cisco IOS configs by looking at the indent and using regexps...


(I exaggerate here...)

Obviously disposing of the namespace info is possible. But it might 
surprise you how complicated that makes certain things.


For example, one thing I've found myself doing is pulling the config as 
XML from JunOS, annotating and mutating the document locally according 
to template and database info, then sending it back in the other 
direction. If I've thrown away namespaced tags and attributes, I might 
have received this:


junos:commentLink to provider/junos:comment
interface
  namege-0/0/0/name
  ...
/interface

...but I send back:

commentLink to provider/junos:comment
interface
  namege-0/0/0/name
  ...
/interface

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

Re: [j-nsp] EX4550 apparently dropping IPv6 RA

[Phil Mayers]

On 14/06/14 22:24, John Neiberger wrote:


The EX4550 is just layer two. There is no routing configured on it, so it
should just be passing the RAs from the router to the hosts on the second
switch, but that doesn't seem to be happening.


Is it RA/RS specific, or is forwarding to fe80::1 and related groups broken?


Have any of you ever seen anything quite like this?


On other platforms, I've seen IPv6 link-local multicast fail to flow as 
some tiny table, sized with IPv4 assumptions, overflowed.

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

[j-nsp] Netconf namespaces

[Phil Mayers]

All,

We've got some code to talk junoscript, but it's run into problems 
because the XML parser turns out to not reliably deliver start/end tag 
events to upper layers - it is dependent on the chunking of input data :o(


To sidestep this difficulty, I started to look at Netconf, which of 
course is separate XML documents rather than one long-lived one, so 
flushing the parser at the  delimiter is easy.


Literally the very first thing I noticed is that JunOS doesn't put a 
namespace on the hello tag:


!-- No zombies were killed during the creation of this user interface --
!-- user admin, class j-super-user --
hello
  capabilities

This of course fails to validate against the .xsd schema in Appendix B 
of RFC4741 or 6241, and makes me sad. Similarly, it'll happily take 
rpc documents without the correct namespace, though it seems to always 
namespace rpc-reply


(
Other vendors do different variations - Cisco IOS never namespaces 
anything, NX-OS namespaces everything, and so on.


What, honestly, is the point of XML namespaces? No-one ever gets them 
right,

)

Anyway, the actual question - is anyone using Netconf in anger against 
JunOS, and if so, how do you handle namespaces? Do you just ignore the 
fact that JunOS is broken for hello? Are there other places where the 
namespaces aren't handled according to spec?

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

Re: [j-nsp] Netconf namespaces

[Phil Mayers]

On 12/06/14 16:38, Tyler Christiansen wrote:

What are you trying to accomplish?  It may be easier to use the Juniper


I am trying to integrate our new EX switches into our existing, 
extensive, automation and provisioning systems.


I've already got it working with Junoscript, but as noted had a few 
problems (currently successfully being worked around) so took a look at 
Netconf, and found namespace issues.


The fundamental question is: are namespaces used incorrectly all over 
the place in Netconf?



Netconf Ruby gem or the Python junos-eznc module depending on your
background and goals.


I'd rather stab myself with a rusty fork than use Ruby.

I've looked at the PyEZ and ncclient code, and basically they seem to 
take the approach of just throwing away all namespace information. This 
seems icky to me, and make me wonder if Netconf is going to be another 
SOAP - so many implementation errors that interop ends up being a mess 
of special casing and workarounds.


In any event, our existing tooling uses Python  Twisted, so 
synchronous/blocking libraries don't integrate well.


I'll look at the Ruby code to at least see what they do about 
namespaces; I bet ignore them. Makes me wonder why we even bother with 
XML, sigh...

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

Re: [j-nsp] Netconf namespaces

[Phil Mayers]

On 12/06/14 17:48, Tyler Christiansen wrote:


I honestly couldn't tell you--but it wouldn't surprise me.  Data formats
like XML aren't very good data formats.


Maybe, maybe not. But they're what we've got, so...


I'd rather stab myself with a rusty fork than use Python.  :)  To each
his own, I suppose.


Indeed.


Data formats are going to have this problem forever.  It's not specific
to NetConf or SOAP.  Standards in general have this
problem--implementation for a vendor's version of a standard starts, and
then the standard changes or is improved and the vendor doesn't move
forward (or at least not as quickly as we would like).


Point taken, though here XML is being used as the transport layer 
encoding, and that's a really unfortunate place to have to code in 
crufty workarounds, particularly given that the *payload* is part of the 
same XML document as the transport :o(


We'd all be a lot better off if Netconf had used HTTP I suspect...


If you're really into Python/Twisted, you may want to look at Trigger


I've seen trigger. It has some neat stuff, though it doesn't currently 
do anything we need. I keep meaning to see if there are bits I can 
either use locally or adapt our stuff to it and contribute it back.


But AFAIK trigger doesn't use Netconf - it has a Junoscript 
implementation (very similar to the one we have - convergent evolution 
etc.) and a generic telnet/expect-alike.


Still, a neat project. If we ever need ACL automation of that type, I'll 
look into it.

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

Re: [j-nsp] Junos 12.3 more strict about 3rd party optics?

[Phil Mayers]

On 11/06/14 15:01, Chuck Anderson wrote:


Jun 10 11:40:54  ex4200 chassism[1293]: XCVR: Unit 0, SFP+ of type 0 EEPROM is 
Mis Programmed!!


Yeah, this was the one that caught my eye. I wonder if it's choking on 
unknown values in the EEPROM.

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

Re: [j-nsp] Junos 12.3 more strict about 3rd party optics?

[Phil Mayers]

On 10/06/14 14:14, Chuck Anderson wrote:

Is Junos 12.3 more strict about 3rd party MSA optics than 11.4?  I've
been using 3rd party MSA optics in EX without troubles, including DOM
support working fine.  I just deployed a new EX4200 VC with 12.3R6,
and the DOM isn't working on the 3rd party MSA optics (but the link
comes up and works), but those same optics work with DOM on an MX
running 11.4.  Interesting that it says unknown cable whereas my
other 3rd party CWDM SFP+ optics say 10GBASE-LR there.


We have working DOM for 3rd party 1G LR, 10G LR, and 10G DWDM ER, but no 
DOM for 3rd party 1G BX (bi-di) and 10G DWDM ZR.


This is on EX3300 running 12.3R6.6 and the DOM reports ok.

I wonder if it's the optic type, rather than vendor, that's in play here?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos 12.3 more strict about 3rd party optics?

[Phil Mayers]

On 10/06/14 16:17, Chuck Anderson wrote:


Moving this same exact optic from the QFX5100 to an EX4200 running
11.4R8.5 it fails, so this seems to be an issue with how the optic is
programmed vs. the specific switch/router hardware, rather than
Junos-version specific:


There are some suggestive entries in /var/log/messages now that I look; 
do you see anything there?

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

[j-nsp] Config ordering of security address-book and address-set members

[Phil Mayers]

Does anyone know why JunOS on SRX doesn't apply alphabetical ordering 
for address-book members and address-set members? It seems rather 
pointless to have them ordered by insert order, since they don't have 
precedence - that all happens inside the policies.


(We care because we have similar configs on multiple firewalls and a 
check/compare diff; so I had to write a Junoscript job to reorder them 
via a commit in order for the diff not to slowly grow)

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

Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU

[Phil Mayers]

On 05/03/14 16:23, Andy Litzinger wrote:

Chris, can you elaborate on why low TTL on multicast frames will
cause high CPU?

Sebastien, as Chris pointed out anything in the 224.0.0.0/24 will hit
the CPU, but so will a few other ranges that fall into the Link-Local


There's no inherent reason these packets need to hit the CPU on a purely 
layer2 vlan, any more than broadcast or unknown-unicast packets have to.


It might be that the architecture of the device - either by necessity, 
choice or neglect, and either hardware or software - means these packets 
hit the CPU, but just being link-local or multicast doesn't imply it.


TBH, most vendors have similar behaviour in similar product ranges e.g. 
the recent discussion on cisco-nsp re: layer2 multicast and Cisco 3xxx 
range, and I've seen Foundry/Brocade and Extreme switches do it as well.


I've always chalked it up to laziness of implementation; the forwarding 
hardware just isn't setup and/or capable of being set to forward these 
in hardware for VLANs where the CPU doesn't need to see them.


Even IGMP snooping should only be punting IGMP packets to CPU, not all 
multicast!

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

Re: [j-nsp] Juniper Product against DDoS

[Phil Mayers]

On 18/02/14 14:46, Samol wrote:

Hi Experts,

Does Juniper provide any DDoS solution ? would you please recommend the
product line for this solution if there is?


Funnily enough I was just talking to our Juniper account team about 
various things, and they mentioned this:


http://www.juniper.net/as/en/products-services/security/junos-webapp-secure/ddos/

No idea if it's any good; haven't used it, but I know it has been 
deployed in front of some large sites.

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

Re: [j-nsp] Setting RTBH next-hop at RR for L3VPN routes

[Phil Mayers]

On 09/02/2014 05:34, Mark Tinka wrote:

On Sunday, February 09, 2014 01:30:20 AM Phil Mayers wrote:


So, what I'm asking is: how can I override an inet-vpn
next-hop at a route-reflector, when the next-hop is not
a real PE.


I'm guessing this is dedicated route reflector - not running
MPLS - and you have no problems reflecting regular l3vpn
routes, yes?


It is a dedicated route-reflector i.e. not in the traffic path, and I 
have no problems reflecting regular l3vpn routes. But it is running MPLS 
(ldp  family mpls on core ifs), as to me this seems marginally cleaner 
than a 0.0.0.0/0 static in inet.3.


This made me wonder if a static for the RTBH next-hop in inet.3 would 
help - no joy. Nor does adding the RTBH next-hop as a secondary on 
loopback, presumably because JunOS isn't allocating a label for it, or a 
couple of different variations of getting the route into inet.3, this 
time with valid labels (advertised by a 3rd router).


Since the error message all along is:

  BGP label allocation failure: protocols mpls not enabled on interface

...I'm wondering what interface it's referring to. MPLS is defintely 
enabled on the core-facing interfaces, so which interface is it 
referring to? Time to break out traceptions methinks.

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

Re: [j-nsp] Setting RTBH next-hop at RR for L3VPN routes

[Phil Mayers]

On 09/02/2014 11:44, Phil Mayers wrote:

On 09/02/2014 05:34, Mark Tinka wrote:

On Sunday, February 09, 2014 01:30:20 AM Phil Mayers wrote:


So, what I'm asking is: how can I override an inet-vpn
next-hop at a route-reflector, when the next-hop is not
a real PE.


I'm guessing this is dedicated route reflector - not running
MPLS - and you have no problems reflecting regular l3vpn
routes, yes?


It is a dedicated route-reflector i.e. not in the traffic path, and I
have no problems reflecting regular l3vpn routes. But it is running MPLS
(ldp  family mpls on core ifs), as to me this seems marginally cleaner
than a 0.0.0.0/0 static in inet.3.


Doh! But I did *not* have:

set protocols mpls interface lo0.0

...which made it spring to life. Thanks for the useful prod.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Setting RTBH next-hop at RR for L3VPN routes

[Phil Mayers]

All,

We're wanting to deploy RTBH, and I'm running into issues because when 
the route is injected into an L3VPN, the next hop is set to the 
advertising PE, not the RTBH discard next-hop.


I figure I can change this with a route-map on the other PEs facing the 
RR, but that seems clumsy, so I tried to set it on the RRs instead using 
a policy like so:


[edit routing-options]
+   rib inet.0 {
+   static {
+   route 192.0.2.1/32 {
+   discard;
+   no-readvertise;
+   }
+   }
+   }
[edit protocols bgp group RR-client]
+export BGP-rr-out;
[edit policy-options]
+   policy-statement BGP-rr-out {
+   term t1 {
+   from community RTBH;
+   then {
+   next-hop 192.0.2.1;
+   accept;
+   }
+   }
+   term t2 {
+   then accept;
+   }
+   }
[edit policy-options]
+   community RTBH members 64580:666;

...however the routes are not being advertised to the RR clients, reporting:

* 192.168.0.0:1:x.x.x.x/32 (2 entries, 1 announced)
 BGP group RR-client type Internal
 Route Distinguisher: 192.168.0.0:1
 BGP label allocation failure: protocols mpls not enabled on interface
 Nexthop: Not advertised
 Flags: Nexthop Change
 MED: 0
 Localpref: 100
 ...

I'm assuming that what's happening here is the JunOS RR is trying to 
allocate a label to put into the inet-vpn update, but can't. Is there 
any way I can force this to happen? The actual label doesn't matter I 
guess, since the RTBH next-hop will be routed to null0/discard on all 
the RR clients.


Note that the RR doesn't have routing-instance statements for the L3VPN; 
it's just reflecting inet-vpn. Presumably if I did define the 
routing-instances, and if I put the discard route in each instance, it 
would work but that again seems clumsy. Maybe I'm just being too choosy ;o)

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

Re: [j-nsp] EX3300 family ethernet-switching IPv6 matches?

[Phil Mayers]

On 10/01/14 00:47, Han Hwei Woo wrote:

I believe you're looking for next-header


Yes, I am looking for that, but it's not supported on this platform. As 
the thread should have made clear...

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

[j-nsp] EX3300 family ethernet-switching IPv6 matches?

[Phil Mayers]

All,

The release notes for the EX3300 are a little vague on this, but 
strongly imply that as of Junos 12.3, IPv6 firewall filters are 
supported. However:


[edit firewall family ethernet-switching filter FPP term deny-ra]
admin@sh-299y# set from ip-version ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
 ipv4 Define L3/L4 match items to match IPv4 packets

Note: no IPv6.

I can match on the IPv6 ether-type, but not any L3/L4 items:

[edit firewall family ethernet-switching filter FPP term deny-ra from]
  'protocol'
ipv4 match item not allowed when ether-type is ipv6
[edit firewall family ethernet-switching filter FPP term deny-ra from]
  'icmp-type'
ipv4 match item not allowed when ether-type is ipv6

Is this expected to work? Or is the ipv6 support for routed packets 
only, and not for ethernet-switching?

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

Re: [j-nsp] EX3300 family ethernet-switching IPv6 matches?

[Phil Mayers]

On 08/01/2014 19:33, Chuck Anderson wrote:


and likewise for 13.2, and you'll notice that your last statement is
correct.

Platform Support for Match Conditions for IPv6 Traffic


That's a damn shame. Up to that point, they'd been looking like really 
nice devices, but I'm afraid in 2014, any device lacking IPv6 parity in 
such a critical area goes back in the box and fails evaluation.


Sigh. Why are enterprise L2 switches all so near, yet so far?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX3300 family ethernet-switching IPv6 matches?

[Phil Mayers]

Please, everyone contact your Juniper team and ask them about this.  I
just poked my team again.

Oh, rest assured. Juniper will be hearing this from me loud and clear!
-- 
Sent from my phone with, please excuse brevity and typos
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Resetting link-state and PoE on EX3300

[Phil Mayers]

All,

We're trialing the EX3300 as an edge switch and there are a couple of 
things we do on our current devices that I can't find an easy way to do 
without making a (relatively slow) config change, commit, undo, commit 
cycle - namely, blipping the ethernet link and the PoE.


The former we use to encourage devices to get a new DHCP lease, and the 
latter to fix hung/crashed wireless APs and VoIP phones.


I can't see any way to do these without disabling the port or PoE via a 
config change, which seems awkward - our existing kit has 
operational-mode reset/clear commands for both. Any suggestions?

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

Re: [j-nsp] Resetting link-state and PoE on EX3300

[Phil Mayers]

On 06/01/2014 13:00, Paul S. wrote:


As far as I know, the sanest way in Junos to do both of those is
configuring them, and then using a commit confirmed 1 to commit it.


Bleh. That wouldn't be quite so bad if commits weren't pretty slow on 
EX3300. But I still don't think it's very clean.


(Fortunately the most important to us, flapping the link, can be done 
with a RADIUS CoA if you are doing dot1x or macauth, which we are, so I 
can probably live with that)




This way, it commits and auto removes your disable a minute later --
saving you the hassle of doing it yourself.

I'm not aware of any operational mode commands for either.


The lack of a PoE restart seems in particular a bit of an oversight. 
Oh well, never mind - thanks for the reply.

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

[j-nsp] Performing a junos-style diff offline

[Phil Mayers]

Does anyone know of a tool or code to do this? I'm writing some 
Junoscript to maintain the security config on our SRX from a database, 
and would like to be able to compare pairs of devices which should, 
after the updates, be identical but may end up with slight unmanaged 
differences.


Getting it in junos-style, rather than plain old diff, would allow the 
differences to be resolved by operator intervention and load patch.


Alternatively, is there a Junoscript RPC which can be used to diff 
against a remote URL? I don't want to have to load the other config 
via load-configuration as some of these are (very) large, and that's 
relatively slow.

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

Re: [j-nsp] J series packet mode

[Phil Mayers]

On 19/12/13 14:25, Tom Storey wrote:

Hi everyone.

Whats the general consensus about using a J series entirely in packet
mode?


We do it with no problems on both J-series and branch SRX (210H, FWIW).

Some people are annoyed about the amount of RAM consumed (wasted) by 
starting the flow daemon. Whether that matters will depend on how much 
RAM you need.



Are there any gotchyas to be wary of, like missing features,


Basically anything flow-related; no ipsec, etc.


performance hit? It looks like you can configure 3 address families
for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
reading, enabling MPLS packet mode forces the whole box in to packet
mode, including inet4.


Yes.


FWIW the situation I am picturing would not require NAT or IPSEC or
other services like that, just packet shifting with ACLs, some
routing protocols (IS-IS/BGP), and something like VRRP for gateway
redundancy.


This is exactly what we do, with MPLS L3VPN and PIM multicast on top. It 
works fine.



As I understand it the J series were originally a packet mode box
until Juniper switched the default behaviour to flow based. Has
there been any major architecture changes that would rule out packet
mode operation?


Not as far as I'm aware; current JunOS on our J-series is 11.4R7.5 and 
we're running packet-mode no problems.

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

Re: [j-nsp] J series packet mode

[Phil Mayers]

On 19/12/13 15:06, Tom Storey wrote:

On 19 December 2013 14:39, Phil Mayers p.may...@imperial.ac.uk wrote:


performance hit? It looks like you can configure 3 address families
for packet mode (iso, inet6, mpls) but not inet4. But, from what Im
reading, enabling MPLS packet mode forces the whole box in to packet
mode, including inet4.



Yes.


Just want to clarify, are you saying there is a performance hit? Or
just that enabling MPLS packet mode forces the entire box in to packet
mode?


The latter.

We've not seen any unexpected performance issues from being in packet mode.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SPUx jmpi mbuf stall on SRX3600 w/ routed multicast

[Phil Mayers]

On 26/11/13 04:25, Chris Cappuccio wrote:

Phil Mayers [p.may...@imperial.ac.uk] wrote:


cpp0 swanhill10: SPU10 mbuf stall exceed 80%, p 0% h 0% j 82%, set alarm.
alarmd[1152]: Alarm set: FPC color=RED, class=CHASSIS, reason=FPC 10 Major
Errors
craftd[1153]:  Major alarm set, FPC 10 Major Errors

The chassis alarm can't be cleared without a reboot.

Anyone run into anything similar? Any way to fix this without a reboot?


Run better JunOS code.


I'm not entirely sure if this was intended as humorous or helpful, but 
as it happens you're pretty close to the mark. Apparently this is 
present in the X45 but not X44 or 11.4 code, and is known under PR 
918415. It will be fixed in X45-20, apparently due in January.


FWIW we're running the 12.1X series code as we have the combined NP-IOC 
cards which need it. I can't remember if the NP-IOCs are supported in 
X44, but aside from this bug (which is pretty easy to avoid - don't 
remove a policy permitting multicast traffic) the X45 code has been OK 
so far, so we'll probably live with it.

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

[j-nsp] SPUx jmpi mbuf stall on SRX3600 w/ routed multicast

[Phil Mayers]

All,

(I've got a case pending about this, but no response yet, which is 
really annoying...)


We have a pair of SRX3600. They're due to go live shortly, but during 
testing I've discovered an issue - when passing routed multicast 
traffic, if I remove the policy matching the multicast, the device 
starts logging:


cpp0 swanhill8: SPU8 jmpi mbuf stall 53%.
cpp0 swanhill10: SPU10 jmpi mbuf stall 56%.
cpp0 swanhill11: SPU11 jmpi mbuf stall 58%.

...and then:

cpp0 swanhill10: SPU10 mbuf stall exceed 80%, p 0% h 0% j 82%, set alarm.
alarmd[1152]: Alarm set: FPC color=RED, class=CHASSIS, reason=FPC 10 
Major Errors

craftd[1153]:  Major alarm set, FPC 10 Major Errors

The chassis alarm can't be cleared without a reboot.

Anyone run into anything similar? Any way to fix this without a reboot?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SSD disks high failure ratio ?

[Phil Mayers]

On 10/08/2013 12:58 AM, Pierre-Yves Maunier wrote:


Does anyone knows what is the 'software solution' that 'has also been
developed to correct the affected REs in the field' as said in the KB ?



Yes, that bit of the PR is annoyingly coy, isn't it?

JTAC told me:


So, you need to perform the secure erase of the contents on the SSD to 
fix this issue.
This secure erase is done by TAC and I will work with service manager of 
this account to check how to move forward on this.



This is just weird; it's not like a secure erase is some kind of 
super-secret thing - just break into the shell from alternate boot media 
and run the command - so why not document it for customers to self-perform?


I have to wonder if there's more to it than that.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SSD disks high failure ratio ?

[Phil Mayers]

On 08/10/13 13:57, Paul Stewart wrote:

Did you confirm by serial number that you were effected?  The reason I ask
is we had a pair of RE1800's that matched on part number but after JTAC
ran the serial numbers they re-assured us that we were not actually
effected (which is kind of scary in itself).


They told me something contradictory; I was assured I was OK because 
they were bought after date X but I pointed out the HW rev was 04 and 
the KB said =05 was affected, at which point they decided I *was* affected.


Seems they're a bit confused...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SSD disks high failure ratio ?

[Phil Mayers]

Saku Ytti s...@ytti.fi wrote:
On (2013-10-03 18:08 -0400), Paul Stewart wrote:

 Article is in review and not yet ready for viewing

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


http://kb.juniper.net/InfoCenter/index?page=contentid=S:TSB16164smlogin=

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

Thanks, this is very useful - does look like our new REs are affected :o(

Will contact support to get the fix implemented.
-- 
Sent from my phone with, please excuse brevity and typos
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] DHCP snoop/DAI/IPSG and mac-based vlans?

[Phil Mayers]

Does anyone know if the layer2 security features in $subj work at the 
same time as dynamically-allocated vlans via 802.1x/macauth and RADIUS?


I know of a few platforms from other vendors where this isn't the case - 
the DHCP/ARP/IPSG punts are bound to the static combo of portvlan 
defined in the config - and am wondering if this is true on the EX 
switches. The docs don't really specify, and I don't have a unit to test 
(but if it *does* work, may get one ;o)

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

Re: [j-nsp] expected multicast forwarding behavior with igmp-snooping and local igmp querier

[Phil Mayers]

On 09/18/2013 12:47 AM, Andy Litzinger wrote:


This does not appear to always be true.  I obviously haven't tested
every multicast address, but it seems that pretty much all multicast
traffic directed to 224.0.0.0-239.0.0.255 will cause the switch to
flood traffic to all ports in the vlan.

But addresses from 239.0.1.0 and up seem to work as I expect.


Sounds like you're running into the fact that 1 multicast group range 
maps to 1 multicast MAC range because there's not enough room to fit the 
28 bits into the multcast mac lower-half.


239.0.0.0/24 maps to the same MAC address range as 224.0.0.0/24 and the 
latter is defined as no snooping because it's the link-local/control 
range, hence both flood.


It's a cisco document, but see here:

http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml#wp1002391

Some newer equipment (e.g. Cisco Sup2T) does IP-based multcast snooping 
- it reads into the IP header, rather than relying on the multicast mac 
- which solves the problem. No idea if the EX4xxx can do this, but I 
doubt it somehow.


Basically, don't use (224-239).{0,128).0.0/24 for multicast.


also- what I'm trying to do is relatively simple but maybe I'm going
about it the wrong way.  I have groups of servers in the vlan that
use multicast packets as a periodic heartbeat to keep track of each
other.  I'd like to make sure the multicast heartbeat only goes to
other servers that subscribe to the same multicast address- not send
it to every server in the vlan.  does my config seem like a valid way
to do this?  I don't need to route the multicast across subnets.


FWIW we've had big problems with apps that do that. IMHO a 
broadcast-discovery / unicast-keepalive is superior to those kinds of 
multicast solutions. App developers often fail to test in realistic 
environments, and don't account for the myriad of ways that multicast 
can go wrong (e.g. the above issue!). We discourage multicast heartbeats 
for that reason.

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

Re: [j-nsp] Rationale behind set chassis aggregated-devices ethernet device-count

[Phil Mayers]

On 23/08/13 17:14, Michael Loftis wrote:

Part of it probably has to do with SNMP.  Pre-allocating the count
keeps the SNMP index ID's from changing when devices are
added/removed.  ae0 is always index blah.  A lot of tools are very
dependent upon the SNMP index ID.


I don't think so TBH. Having just snmpwalk'ed a JunOS box, the aeX 
interfaces and sub-ints ifindex values appear allocated sequentially:


IF-MIB::ifDescr.521 = STRING: ae0
IF-MIB::ifDescr.522 = STRING: ae0.32767
IF-MIB::ifDescr.524 = STRING: ae1
IF-MIB::ifDescr.529 = STRING: ae0.1
IF-MIB::ifDescr.530 = STRING: xe-1/0/0.1
IF-MIB::ifDescr.531 = STRING: ae0.11
IF-MIB::ifDescr.532 = STRING: ae0.10
IF-MIB::ifDescr.533 = STRING: ae0.9
IF-MIB::ifDescr.534 = STRING: ae0.8
IF-MIB::ifDescr.535 = STRING: ae0.7
IF-MIB::ifDescr.536 = STRING: ae0.6
IF-MIB::ifDescr.537 = STRING: ae0.5
IF-MIB::ifDescr.538 = STRING: ae0.4
IF-MIB::ifDescr.539 = STRING: ae0.3
IF-MIB::ifDescr.540 = STRING: ae0.2
IF-MIB::ifDescr.541 = STRING: xe-1/0/0.11
IF-MIB::ifDescr.542 = STRING: xe-1/0/0.10

So, unless I'm misunderstanding what you mean, it's not doing anything 
interesting here.

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

Re: [j-nsp] Rationale behind set chassis aggregated-devices ethernet device-count

[Phil Mayers]

On 23/08/13 18:04, Doug McIntyre wrote:


But imagine the case, where you start with needing 4 LAGs, so that is
what you set. Then you add in 10 SFPs for various things, and then you
add in 4 more LAGs, then you remove 4 SFPs for some other project.

What do your SNMP indexes look like now? And hopefully your
/var/db/dcd.snmp_ix file doesn't get corrupt and the indexes have
to be recomputed at that point..


Sorry, but I've not understood what point you're trying to make here. 
That adding and removing interfaces will change which ifindex values are 
allocated? Well yes, obviously ;o)


(IMNSHO, software that assumes persistent ifindex values is broken and 
should be thrown away)



Back to the original question, there probably is some resources taken
up by having the LAGs there. And if you just do max # right away, you do
have all those new interfaces to gather stats on if your SNMP queries
just do a bulk walk of all interfaces.


That might be a reasonable explanation, but you could equally well argue 
that putting the interface into the IF-MIB when it's not defined under 
the interfaces stanza (as JunOS does) is dumb.

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

Re: [j-nsp] Config archive subtleties

[Phil Mayers]

On 08/07/2013 08:25 PM, Phil Shafer wrote:

7 aug 2013 kl. 18:03 skrev Phil Mayers p.may...@imperial.ac.uk:
Recently this fell apart on us, as the SSH key on the server changed and the 
archival
transfers started to silently[1] fail.


Ick.  Silence is deadly.  This (and the other issues) is now PR 910647.


Cool.




All of which has me wondering if the feature is more trouble than it's worth.


We definitely should be making it more robust and stable, but to
me the value of catching each commit as a distinct delta is a win.
It should also have the commit time, user, and commit comment, if
given.  Having this in a repo means one can ask questions like who
has changed config in my network since last Friday? or when did
this statement get added in the first place?.


Agreed; preserving the separate commits and metadata is a big win, IMO, 
and I really like the feature. It was surprising and disappointing to 
find it had hung up!


(To the many people who suggested RANCID - thanks, but we already have a 
config backup system. The question was specifically about strategies to 
integrate the JunOS commit archive feature with such systems *given* the 
failure modes I noted. This is a somewhat non-trivial problem to solve 
in the general case; sure you can have a scheduled fetch hourly 
beltbraces job, but that is both racy and discards data in some failure 
modes)




What else can we do to make this more worthwhile?


Trigger a chassis minor alarm if archive has failed for X minutes? 
(Configurable, of course). The PR may say that, but I can't see it yet ;o)

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

[j-nsp] Config archive subtleties

[Phil Mayers]

All,

For several years, we've used system archival configuration in 
on-commit mode, to backup each commit to a separate file on an 
sftp/scp server, then check them individually into subversion.


Recently this fell apart on us, as the SSH key on the server changed and 
the archival transfers started to silently[1] fail.


While trying to write a nagios check for outstanding archive transfers, 
I then discovered that in some circumstances, the archival config will 
give up and discard a file - I had assumed it would queue them forever, 
but apparently not in some cases (e.g. 3 successive failures with bad 
username/password).


All of which has me wondering if the feature is more trouble than it's 
worth.


What do other people do? It seems like it would be a nice feature to 
preserve the commits and so forth, but if it's not robust, maybe it's 
just misleading.


Cheers,
Phil

[1] It did log en entry into /var/log/messages, but TBH JunOS logs so 
much crap there, we don't do anything with those logs...

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

Re: [j-nsp] Correct config for SRX port channel - Cisco

[Phil Mayers]

On 25/07/13 20:16, OBrien, Will wrote:

Here's a full working example that I pulled off my production link.
It's comprised of a pair of 10gb links. I renumbered things to


Presumably you either don't have vlan dot1q tag native enabled, or 
it's on a platform/version which doesn't (erroneously) tag the LACP 
packets with the native vlan?


Can I ask which cisco device/OS version?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Correct config for SRX port channel - Cisco

[Phil Mayers]

On 24/07/13 17:11, Phil Mayers wrote:

On 24/07/13 17:01, Olivier Benghozi wrote:

Hi Phil,

what is the Cisco model  IOS?


It's actually an Nexus 7009 running NX-OS.



Did you create the vlan in the vlan database in your Cisco switch? :)


Yep



Maybe try switchport nonegotiate...


No such command on NX-OS, there's no DTP.



In case people are curious, this seems to be a bug on the Cisco side.

If the port-channel is in trunk mode, the Cisco is sending the LACP 
PDUs tagged with the native vlan, as we have vlan dot1q tag native 
enabled. This an error IMO, as LACP is not part of a VLAN (it is doing 
the same for LLDP, FWIW)


The SRX, correctly I believe, is ignoring the tagged LACP PDUs.

I can work around this by using sub-interfaces on the Cisco side, but 
it's yucky. Oh well.


Thanks all for the input.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Correct config for SRX port channel - Cisco

[Phil Mayers]

If I have a single SRX3600 device (NOT a cluster), what config (if 
any...) can I use to match a config on the Cisco side:


int member
  lacp rate fast
  channel-group 20 mode active
int Po20
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 999
int Vlan999
  ip address 192.168.1.1 255.255.255.254

I would have thought it would be something like:

chassis {
aggregated-devices {
ethernet {
device-count 2;
}
}
}
interfaces {
xe-1/0/0 {
gigether-options {
802.3ad ae0;
}
}
xe-1/0/1 {
disable;
}
xe-4/0/0 {
gigether-options {
802.3ad ae0;
}
}
xe-4/0/1 {
disable;
}
ae0 {
vlan-tagging;
aggregated-ether-options {
lacp {
active;
periodic fast;
}
}
unit 999 {
vlan-id 999;
family inet {
address 192.168.1.2/31;
}
}
}
}

...but this never comes up. I've seen this before, and I think it's 
because there's something in the LACP PDUs which disagrees about 
trunk/access mode. The config works if I set the Cisco side to access, 
but obviously that's not what I want.


Can you even do this on SRX? I see lots of documents talking about reth 
interfaces, but AFAICT those are all for chassis clustering, which we 
don't want to use.

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

Re: [j-nsp] Correct config for SRX port channel - Cisco

[Phil Mayers]

On 24/07/13 15:48, Stacy W. Smith wrote:

In general, I see no problems with your AE configuration.

Could you define never comes up? Is it the ae0 interface, or the ae0.999 unit 
that is in a down state?



Both (see below)


The output of show interfaces terse (at least for the member and ae 
interfaces)



admin@srx-3600-1 show interfaces terse
Interface   Admin Link ProtoLocal Remote
xe-1/0/0upup
xe-1/0/0.999upup   aenet-- ae0.999
xe-1/0/0.32767  upup   aenet-- ae0.32767
ae0 updown
ae0.999 updown inet 192.168.1.2/31
   multiservice
ae0.32767   updown multiservice



and the output of show lacp interfaces might be helpful.



admin@srx-3600-1 show lacp interfaces
Aggregated interface: ae0
LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout 
Activity
  xe-1/0/0   ActorNo   YesNo   No   No   Yes Fast 
  Active
  xe-1/0/0 PartnerNo   YesNo   No   No   Yes Fast 
 Passive

LACP protocol:Receive State  Transmit State  Mux State
  xe-1/0/0Defaulted   Fast periodic   Detached




FWIW, the two ends of your link are in different subnets. 192.168.1.1/31 and 
192.168.1.2/31 are not in the same subnet.


That's a typo on my part.

I've seem something similar to this before, where a port-channel 
wouldn't come up between a Cisco IOS and IOS-XR box if one end was 
switchport trunk and the other switchport access. This confused me 
slightly - I didn't know LACP was aware of the trunk/access nature of 
the upper interface.

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

Re: [j-nsp] Correct config for SRX port channel - Cisco

[Phil Mayers]

On 24/07/13 16:07, Phil Mayers wrote:

On 24/07/13 15:48, Stacy W. Smith wrote:

In general, I see no problems with your AE configuration.

Could you define never comes up? Is it the ae0 interface, or the
ae0.999 unit that is in a down state?



Both (see below)


Interestingly, this comes up if you use sub-ints on the Cisco side:

interface port-channel20

interface port-channel20.999
  encapsulation dot1q 999
  ip address 192.168.1.1/31
  no shutdown

...as opposed to

interface port-channel20
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 999

int Vlan999
  ip address 192.168.1.1/31
  no shutdown

Clearly there's some sort of LACP-layer parameter that corresponds to 
trunk versus not - can this be influenced by the specific style of 
ae0 config on the SRX side?

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

Re: [j-nsp] Correct config for SRX port channel - Cisco

[Phil Mayers]

On 24/07/13 17:01, Olivier Benghozi wrote:

Hi Phil,

what is the Cisco model  IOS?


It's actually an Nexus 7009 running NX-OS.



Did you create the vlan in the vlan database in your Cisco switch? :)


Yep



Maybe try switchport nonegotiate...


No such command on NX-OS, there's no DTP.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] commit script to prevent duplicate service def' on SRX?

[Phil Mayers]

To save me the work, does anyone know of a commit script that will 
prevent people defining services which duplicate the JunOS or existing 
user-defined ones?


Are the built-in defs (under 
groups/junos-defaults/applications/application/$name) in the candidate 
XML config? In which case it's easy, but if not, what the best way to 
get them?

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

Re: [j-nsp] BOOTP helper on MX vrf

[Phil Mayers]

On 13/06/13 12:03, Sebastian Wiesinger wrote:

Hello,

as I'm hearing conflicting information regarding bootp helper on MX
routers in a vrf routing-instance, has anyone a working configuration?

What I need:

Forward DHCP broadcast requests from one vrf interface to a central
DHCP server in the same VRF (classical bootp helper functionality). I
don't want bootp helper on *every* interface, just a few.


It's a J-series, not MX, but should be the same:

forwarding-options {
helpers {
bootp {
interface {
ge-0/0/2.2021 {
server x.x.x.x routing-instance BLAH;

...and


routing-instances {
BLAH {
instance-type vrf;
interface ge-0/0/2.2021;

Basically, you have to put the routing-instance on the server option, 
matching the routing instance of the interface.

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

Re: [j-nsp] SRX Reliability

[Phil Mayers]

On 12/06/13 10:47, Andrew Gabriel wrote:

Hi,

We are evaluating the SRX 3000 series firewalls for our datacenter, and
would appreciate some feedback from folks who are already using/deploying
the SRX platform.

I understand that the initial software versions had a large number of bugs
and features that just wouldn't work reliably. Juniper claims that they
have addresses most of those and that the current releases are stable and
well received by customers.

How true is that, and would you recommend the SRX platform as a core
datacenter firewall at all?


We recently evaluated an SRX 3600, and modulo some minor cosmetic bugs 
and one major one (PSN-2012-10-754, fixed in later software) they seemed 
solid to me. We tested IPv4  IPv6 layer4 firewalling, AppFW, dynamic 
routing with BGP and multicast. It all seemed to work ok, and we have 
gone ahead and purchased.


It might help if you could specify what sort of things you want to do on 
them e.g. IPsec, IDP, inline AV/web filtering (which the 3000s can't do) 
and so forth.

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

Re: [j-nsp] SRX Reliability

[Phil Mayers]

On 12/06/13 13:41, Andrew Gabriel wrote:

On Wed, Jun 12, 2013 at 3:58 PM, Phil Mayers p.may...@imperial.ac.uk
mailto:p.may...@imperial.ac.ukwrote:

We recently evaluated an SRX 3600, and modulo some minor cosmetic
bugs and one major one (PSN-2012-10-754, fixed in later software)
they seemed solid to me. We tested IPv4  IPv6 layer4 firewalling,
AppFW, dynamic routing with BGP and multicast. It all seemed to work
ok, and we have gone ahead and purchased.

It might help if you could specify what sort of things you want to
do on them e.g. IPsec, IDP, inline AV/web filtering (which the 3000s
can't do) and so forth.


Hi Phil,

Thanks, we are mainly looking at basic FW, VPN, and routing capability,
which we need to be rock solid. We do not intend to use the IPS and UTM
type features at the moment.


The basic firewalling seemed solid, as did the dynamic routing - it is 
JunOS after all - but I didn't test VPN, so can't comment on that.


We were running 12.1R6.5.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] What is this ethernet switching trace telling us?

[Phil Mayers]

On 06/09/2013 04:59 PM, John Neiberger wrote:


We have several of these throughout our network and we're only seeing this
problem in a couple of cases. The rest work just fine. Most of the SBCs are


Obvious question: are you sure those two aren't configured different 
(wrongly) compared to the others, or running different software?


Reading between the lines it sounds like a different group runs these 
devices, and in my experience, kit like this with odd network interface 
capabilities can be misconfigured by staff that don't fully understand 
networking - and it can be exacerbated by vendors using odd terminology 
(e.g. PHY used in a non-standard way) and confusing people.


Are you sure they haven't just setup these two devices in active-active 
mode? Or more likely, something that *sounds* like an active-passive 
mode in the UI, to a non-expert, but is really some kind of weird 
active-active spatchcock.


Our storage team did this with a couple of NetApps and the symptoms were 
pretty much identical. It only really brought things crashing down when 
they started sending 1Gbit/sec of performance testing traffic from them...

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

Re: [j-nsp] What is this ethernet switching trace telling us?

[Phil Mayers]

On 06/08/2013 08:35 AM, Gavin Henry wrote:


your email to /etc/aliases. We found that the Linux kernel doesn't
send the same arp response out of the same interface. For example, one
interface was a public IP and one was a private IP. The kernel would
send a I'm on MAC blah for the private IP out of the public IP port!

arptables is the solution, but in 10 years it's the first time I'd


The behaviour you describe can be disabled by sysctl, which is rather 
cleaner than arptables IMO; our cfengine config puts the following 
/etc/sysctl.conf:


# These values make linux be sensible about making and replying
# to ARP requests - specifically they force ARP requests to come
# from an in-subnet IP, and ignore ARP replies for out-of-subnet
# addresses
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

AIUI the Linux behaviour is intentional, claiming to be the letter of 
the relevant RFCs, but it's certainly problematic in a number of 
scenarios, including multihoming, transparent load-balancing and anycast 
routes. There's more documentation in the kernel source for the above 
sysctls.


I have no idea if this is actually the OPs problem.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SLAX script, redefining variables

[Phil Mayers]

On 07/06/13 09:54, Tom Storey wrote:


But without being able to redefine a variable, and with variables defined
inside an IF block not being accessible outside of that IF block, I will
need to reproduce my output code numerous times.


Move the output code to a function?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX 3600 dropped packets - how to debug?

[Phil Mayers]

On 28/05/13 14:57, Phil Mayers wrote:


I have my suspicions about what exactly the ALG is (mis)counting as a
drop, and will be trying to reproduce it on the bench now it's been
taken out of service.


All,

Just to confirm that, as tested on the bench on SRX 3600 and JunOS 
12.1R6.5 *all* packets processed by the DNS alg count as a drop in the 
output of show security flow statistics, even though they're forwarded 
correctly.


The SUNRPC alg seems to do the same; presumably the all do.

So, if you have any ALGs enabled, that counter is misleading, and if you 
don't, DNS packets will consume a lot of your sessions.


This is demo model so I can't open a support case, but when the real kit 
arrives, maybe I will...

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

Re: [j-nsp] SRX 3600 dropped packets - how to debug?

[Phil Mayers]

On 29/05/2013 20:24, Morgan McLean wrote:

Side note on the DNS ALG, RHEL 6 doesn't like the SRX DNS ALG. RHEL 6
makes both A and  lookups for each name resolution in the same
connection, resulting in two requests being sent out, one response being
received and the session closing, cutting off the second response. This
causes a 5-10 second time out for every name resolution on the server.


That's not RHEL6-specific. glibc has done A/ lookups like this for a 
while now, and I've had problems with other stateful devices (load 
balancers in front of DNS recursive servers) as a result.


See also https://bugzilla.redhat.com/show_bug.cgi?id=505105

In addition, my testing boxes *were* RHEL6 and the DNS alg seemed to be 
forwarding them fine - indeed, during my testing I saw other hosts 
sending tens of DNS requests down the same socket pair, and all were 
forwarded fine.


Are you running an older JunOS - maybe they fixed it?



There is a flag you can set under the resolv.conf to require a new
socket per query, or you can turn off the DNS ALG. Could also custom
define a DNS service that times out in 10 seconds or something?


Even a 10 second timeout results in a significant rise in sessions - we 
tested exactly that.

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

Re: [j-nsp] SRX 3600 dropped packets - how to debug?

[Phil Mayers]

On 28/05/13 14:40, Julien Goodwin wrote:

On 28/05/13 19:40, ashish verma wrote:

That said, I can't believe the firewall was *actually* dropping 1500pps of
DNS traffic; we'd have widespread problems reported, surely. So, it seems
that maybe ALG-processed traffic is being counted under packets dropped
for show security flow statistics?


eDNS fallback perhaps?


IME eDNS is pretty much exclusively confined to server-server DNS 
traffic (modulo newer stuff like in-app DNSSEC resolvers) and these are 
ordinary clients, which don't tend to make eDNS requests. A SPAN of the 
link(s) into the SRX tends to support this - no eDNS traffic in a 32Gb 
capture.


I have my suspicions about what exactly the ALG is (mis)counting as a 
drop, and will be trying to reproduce it on the bench now it's been 
taken out of service.



I never understood the use of DNS ALG's, unless it's to perform a NAT
translation on addresses (which is a really bad idea) they just seem
like a waste of valuable resources. Far better to ACL down so that DNS
queries can only go to trusted DNS servers which can run something that
doesn't break on a malformed query.


I'm not a fan of ALGs, and in principle I agree with you.

However, if you disable the DNS ALG, you might see a sharp increase in 
session utilisation, as the UDP session stays open for the UDP timeout, 
as opposed to the fraction of a second that the DNS request/response 
takes. With even moderate load, this can be tens or hundreds of 
thousands of sessions wasted, particularly because clients tend to use 
different UDP source ports - I know this because I tried it, both on our 
real Netscreen 5400s and on this SRX, and sure enough - big jumps.



The best solution here is to avoid the DNS traffic hitting the firewall 
altogether. If you use L3VPN (as we do) this involves the well-known 
services VRF solution using appropriate route-targets, or simply 
multi-homing your DNS servers into each security zone.


But this only gets *your* DNS servers. If you have people using Google 
DNS, Open DNS or whatever, you are faced with either blocking access to 
those services and eating the support costs (I have a roomful of VIPs 
and 3 of them can't access the internet) or worse, intercepting traffic 
to those services and pretending to be them.


I'm not wild about the upswing in public DNS resolvers and their 
apparent popularity amongst customers, but they're a fact of life now, 
particularly in more open networks (such as universities). The idea of a 
malfunctioning client with 8.8.8.8 as a DNS server consuming 250,000 
sessions on our firewall is not attractive :o(

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

Re: [j-nsp] SRX 3600 dropped packets - how to debug?

[Phil Mayers]

On 28/05/13 14:51, OBrien, Will wrote:

The primary use of the dns alg is to reduce session count. This is
very apparent on net screens. I reduced 500k sessions down to 400k by
turning it on. That said, you can achieve similar results by setting
dns specific policies with short timeouts.


Out of interest, how short a timeout have you experimented with?

We set our Netscreen 5400s to 10 seconds at one point, but the extra 
session table use was still considerable by comparison with an 
ALG-enabled setup.

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