Re: [j-nsp] Thanks for all the fish

[Chris Morrow via juniper-nsp]

On Wed, 10 Jan 2024 22:10:09 +,
"Giuliano C. Medalha via juniper-nsp"  wrote:

> JUNIPER has 2 very powerful jewels that don't make any sense for HPe to throw 
> them away.

you know every conpany that's acquired things this sort of thing about 
themselves...
RARELY is it the reality that the other party is also imagining...

> One of them is the JUNOS operating system and now the JUNOS-EVO.
> 
> The other thing is related to the JUNIPER NPUs: TRIO and Express (
> to compete with other vendors - cisco, arista, nokia - and now with
> nvidia )

It may be the case that things go as folk on this list hope (me to, I suppose!)
it may also be that the purchaser here sees something completely different
and that the end result is vastly out of the reality discussed.

good times a-comin'!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] About Secure Transport for RPKI on JUNOS

[Chris Morrow]

At Thu, 27 Dec 2018 11:57:54 +0100,
Bjørn Mork  wrote:
> 
> Chris Morrow  writes:
> 
> > tls brings with it cert issues.
> 
> Well.  How bad does it have to be?  Yes, you have to manage private
> keys. That's the same for TCP-AO, SSH and TLS. Or any other transport
> security protocol. No real difference.

you have to at least manage private keys, plus you need to
monitor/manage certificates on the devices, and rotate them over time.
you probably do NOT want to just place a ~forever certificate on your
device(s) and you probably want some unique identification per
device/certificate. you probably want CRL checking as well... and you
need to operate a CA in a semi-secure fashion.

you must be able to revoke certs, check client/server certificate
details upon connection(s) and log out appropriate details so
debugging connection problems is a reasonably quick effort.

the devices must have a reasonable method to manage the actual
cert/key content, with a reasonable method to refresh the
certificate/key in use by the services on the device(s). There is some
work in this area happening on most vendor gear I follow due to the
push(ing) to use gRPC for streaming telemetry (instead of snmp) and
gRPC for config management. (grpc is the new netmod is the new xml is
the new .) The certificate management MAY only work for the 'gRPC'
part of the device/os though :( Looking at one particular vendor (not
juniper) the 'which certificate/key to use' is very 'service' specific
:( without any real mapping (except an uploaded bash script??? wtf?)
of which cert/key to which service(s). it's pretty depressing to watch
the myopic vendor process on this :(

you must keep time sync'd reasonably closely as well.

> I assume the perceived issue with TLS is that private keys have short
> life spans?  But they don't have to in a RPKI setup.  You will want to

no, you want short lifespans, think of a typical lifespan on the order
of 'days'... like less than 7 days in some cases, and perhaps shorter
depending upon which jurisdiction the device lands in.

> manage the CA(s) yourself, and can implement the policies you need. If
> you want keys with "infinite" life spans, then that's possible. The

infinite is.. infinitely naive. please do not do infinite certificate
lifetimes.

> servers validating router certificates can easily check revoked keys,
> using a simple CRL or whatever. So you can issue a certificate to your
> router and just forget about ever updating it, just like you do with all
> your other passwords ;-)

uhm, no. this is perhaps the worst advice evar. Are you also just
injecting your igp into your egp? :)

> The only difference is that there is a way to actually withdraw that
> password.
> 
> TLS is nice. Don't be fooled by all the lousy infrastructure
> implementations.  Certificate management does not have to suck.

agreed, it doesn't... except that basically all implementations for
network gear are sucky (today) and bespoke. hurray, job security? :(

> And there is no reason to believe that TCP-AO key management will suck
> less - until we've seen it implemented.

oh I agree about this... wait there's karp! (https://tools.ietf.org/wg/karp/)
ha, just kidding that ended up as a pile of fail :(

There are key management schemes to be cribbed from in other network
device management things, particularly I think the ISIS/ospf in
particular. I think both juniper/cisco offer 'key tables' as options
there with timed swap from key to key. That's not an unreasonable
option, except managing AO (in the case of BGP) means potentially
managing quite the matrix of neigh/keys/times... and coordinating with
your peers could get entertaining :( It would be better than 'I set my
md5 key to "chocolate" (no quotes) in 1996.. we're still good with
that, right?' :)

For rpki-rtr you should have a smaller matrix of things you actually
control though (2-3 cache's per device with 2-3 keys 'last, current,
next')

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

Re: [j-nsp] About Secure Transport for RPKI on JUNOS

[Chris Morrow]

At Thu, 27 Dec 2018 11:43:58 +0100,
Bjørn Mork  wrote:
> 
> Chris Morrow  writes:
> > On Wed, 26 Dec 2018 14:11:19 -0500,
> > sth...@nethelp.no wrote:
> >> 
> >> Now if Juniper could implement TCP-AO and then donate the implementation
> >> to FreeBSD? :-)
> >
> > This was sort of my point, yes.
> > Thanks, as always for your cogent point(s).
> 
> I don't follow FreeBSD development, but googling for TCP-AO
> implementations a couple of months ago led me to believe they already
> did?  Ref
> https://lists.freebsd.org/pipermail/freebsd-transport/2016-March/000101.html
> 
> I'm sure someone will set me straight now ;-)

'i am also not a freebsd person' but:
  https://wiki.freebsd.org/BjoernZeeb
bjorn had said when last I ran into him that he was still planning on working 
on AO :(
(he happens to also reply to the above thread, no details in reply)

> 
> > -chris
> > (without something to break the ao logjam we'll just keep on having
> > this argument, maybe we can isntead paste-bin this thread and just
> > refer all other callers there? :) )
> 
> The fact that the work was mostly done 10 years ago, but no one has

I figured that: me: "There's no support in the device/code, I still have md5... 
md5 does what I want."
coupled with: vendor(s): "there's no support in base-os for our gear, no one is 
really asking for it..."

> bothered to finish the job, shows us what we should expect of the next
> 10 years:
> 
> https://marc.info/?l=linux-netdev=121642691623828
> https://marc.info/?l=linux-netdev=121642691723832
> https://marc.info/?l=linux-netdev=121642691823836
> 
> I don't know why Adam never pushed this patch set further.  There
> weren't any major objections to it AFAICS. Maybe I'm missing something?
> 

i also don't know and checking my sept conversation he didn't reply,
so I poked that just now.

> Getting traction after losing it is hard.
> 
> The problem now is that even if you took this code, rebased it to
> current net-next and did the necessary fixups, then it would go into
> Linux v4.22 (or 5.whatever) released in April 2019. The feature would
> then go into the next major distro releases *after* the releases which
> are already being prepared for 2019.  This means TCP-AO might be
> available for applications running on plain Debian stable or RHEL
> kernels in 2021.  And that's being a bit of an optimist...
> 

ok, 2021 is better than 'never' or '2yrs after the next conversation'
right? :)

> Yes, another alternative is obviously running TCP in userspace. But I
> will gladly go to certificate hell if I can avoid that.

user-space tcp seems a bit more implementation specific and probably
means similar timeframes to solve... given the spread of OS/Vendor
problems.

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

Re: [j-nsp] About Secure Transport for RPKI on JUNOS

[Chris Morrow]

On Wed, 26 Dec 2018 14:11:19 -0500,
sth...@nethelp.no wrote:
> 
> Now if Juniper could implement TCP-AO and then donate the implementation
> to FreeBSD? :-)

This was sort of my point, yes.
Thanks, as always for your cogent point(s).

-chris
(without something to break the ao logjam we'll just keep on having
this argument, maybe we can isntead paste-bin this thread and just
refer all other callers there? :) )
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] About Secure Transport for RPKI on JUNOS

[Chris Morrow]

On Wed, 26 Dec 2018 13:36:49 -0500,
Bjørn Mork  wrote:
> 
> Chris Morrow  writes:
> > On Sun, 23 Dec 2018 16:15:24 -0500,
> > Melchior Aelmans  wrote:
> >> 
> >> Hi Pyxis,
> >> 
> >> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX  wrote:
> >> 
> >> > Does JUNOS support any secure transports mentioned in RFC6810 for 
> >> > rpki-rtr
> >> > protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?)
> >> >
> >> 
> >> We are discussing internally what secure transport method to support. I'm
> >> happy to hear your ideas.
> >
> > 'tcp-ao' - yes... srsly.
> 
> Huh? Why? No support on any server OS, AFAIK.  Yes, there were patches
> for FreeBSD and Linux a few years ago, but I don't think they went
> anywhere? This will severely limit the usability.

there's no support elsewhere because no one that cares (you, me, network 
people) can get vendors to deploy AO.
There's no support in network devices because there's no support in linux/etc 
...

this is a pretty horrid place to be :( so, if folk want to put AO into
junos for this, we can get it for the other vendors and for other
parts of each vendor's problem-space... and along the way we'll get it
for linux/*bsd (I expect).

> Let's have ssh, and optionally tls. We need something we can run on a
> server today.  Not 8 year old foilware.

ssh isn't in the right form on pretty much any vendor's device, so
said the vendor implementers many times during rpki-rtr
development/process. (hannes gredler, jeff haas, several cisco folks
as well).

tls brings with it cert issues.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] About Secure Transport for RPKI on JUNOS

[Chris Morrow]

On Mon, 24 Dec 2018 02:38:35 -0500,
Melchior Aelmans  wrote:
> 
> Hi Chris,
> 
> > Op 24 dec. 2018 om 05:11 heeft Chris Morrow  het 
> > volgende geschreven:
> > 
> > On Sun, 23 Dec 2018 16:15:24 -0500,
> > Melchior Aelmans  wrote:
> >> 
> >> Hi Pyxis,
> >> 
> >>> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX  wrote:
> >>> 
> >>> Does JUNOS support any secure transports mentioned in RFC6810 for rpki-rtr
> >>> protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?)
> >>> 
> >> 
> >> We are discussing internally what secure transport method to support. I'm
> >> happy to hear your ideas.
> > 
> > 'tcp-ao' - yes... srsly.
> 
> Im in favor but why do you think AO is the way to go? It seems SSH
> and TLS have gained more support? Let me know your ideas.

jared/gert covered most of this, but:

I think things like TLS bring along with them certificate management
issues.  Some folk have infrastructure to deal with this, some do not.

SSH is not, often, in the right form for devices to use as a library
versus as 'spin up an ssh connection and tunnel over that' mode.

there's the config management parts jared/gert pointed out as well.

and finally... md5 is dead #sosayssecuritypeople so.. let's do
something to move along AO? I'm not a huge AO fan, but it's 'the only
thing left' in the 'make tcp secure again' space.

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

Re: [j-nsp] About Secure Transport for RPKI on JUNOS

[Chris Morrow]

On Sun, 23 Dec 2018 16:15:24 -0500,
Melchior Aelmans  wrote:
> 
> Hi Pyxis,
> 
> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX  wrote:
> 
> > Does JUNOS support any secure transports mentioned in RFC6810 for rpki-rtr
> > protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?)
> >
> 
> We are discussing internally what secure transport method to support. I'm
> happy to hear your ideas.

'tcp-ao' - yes... srsly.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] deleting ntp server from config, perhaps a bug?

[Chris Morrow]

On Thu, 27 Sep 2018 10:57:43 -0400,
Jared Mauch  wrote:
> 
> 
> 
> > On Sep 27, 2018, at 10:51 AM, Saku Ytti  wrote:
> > 
> > On Thu, 27 Sep 2018 at 16:21, Chris Morrow  wrote:
> > 
> >> there's (of course) the 'you should always deploy a full config' crew, 
> >> but...
> > 
> > Reporting for duty.
>

I should be clear, the 'full config only' thing is good, but not
everyone is capable of getting there in the short-term. It also means
quite a bit of infra needs to exist, so not everyone is willing to
commit to it.

> The ability of routers to use DNS for service names is getting to be
> more of a soft-requirement => hard requirement these days.  I may
> want to configure a DNS name for my BMP/KFAFKA magic and have it
> fail over if we renumber the machine (for example).
>

intersting, what cadence would you expect for re-resolving named
resources though? hourly? at RR ttl expiry? other? Why is it not
acceptable to just run 'services' on a VIP, and not on the physical
machine's IP ? (ie: why would you ever renumber?)

> Cisco/Juniper require IPs for the NTP configuration, and if you type
> in something like a NTP pool name/label it will resolve it and store
> that in the config vs follow based on the pool measurement/accuracy
> over time.

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

Re: [j-nsp] deleting ntp server from config, perhaps a bug?

[Chris Morrow]

On Thu, 27 Sep 2018 07:57:49 -0400,
Olivier Benghozi  wrote:
> 
> Works as expected here (16.1R7)...
> 
> > Le 27 sept. 2018 à 13:43, Drew Weaver  a écrit :
> > 
> > I added 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org to 
> > system ntp on an MX80 running JunOS 15.
> > 
> > [edit system ntp]
> > drew@charlie# show
> > server 216.230.228.242;
> > server 45.79.109.111;
> > server 172.98.193.44;
> > server 69.195.159.158;
> > 
> > I need to deactivate/delete a few of these:
> > 
> > [edit system ntp]
> > drew@charlie# delete server 216.230.228.242
> > warning: statement not found
> > 
> > drew@charlie# deactivate server 216.230.228.242
> > warning: statement not found
> > 
> > Is there any way to do this other than simply deleting the entire block and 
> > starting over?

there's (of course) the 'you should always deploy a full config' crew, but...
can you try deleting the NTP server in question from the top of the config tree?
  delete system ntp server 216

that ought to complete and then work (does for me anyway).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Chris Morrow]

On Thu, 12 Jul 2018 16:04:04 -0400,
Jason Healy  wrote:
> 
> On Jul 12, 2018, at 10:09 AM, Benny Amorsen 
> wrote:
> > 
> > Saku Ytti  writes:
> > 
> > That would be really wonderful. A great start would be if there was a
> > way to get just the /32 (or /128) interface IP addresses in
> > apply-groups.
> 
> I started working on a commit script that would harvest all the
> local interface addresses and dump them in a prefix list so you
> could do just this.  Never got around to finishing it, but it's on
> my ever-growing todo list.

i would have tried to do this with an apply-path, does that not work?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Chris Morrow]

On Wed, 11 Jul 2018 15:23:28 -0400,
Saku Ytti  wrote:
> 
> Hey Chris,
> 
> On Wed, 11 Jul 2018 at 22:16, Chris Morrow  wrote:
> 
> > > a) You can't just limit UDP to 2Mbps on every edge port
> >
> > it's really a limit of 2mbps on each PFE, so ... in some cases that's
> > 2mbps on a port, in some cases not. This is a 'problem' because of the
> > architecture of the MX though, right? not the filter itself... well... :)
> 
> They were doing this to transit traffic, high rate of UDP isn't
> strange, good portion of youtube streaming is UDP.

sorry, i think 'they' here is confusing :( or at least confusing me :)
'they' means: "juniper docs/engineers/etc"
  or
'they' means: "team cymru and their docs"

which ? I was answering in the case of the first ;( which may have
lead us astray here...

> 
> > > b) LO filter matches on 'port'
> >
> > on 'port'.. meaning I can't do:
> >   destination-port ssh
> >   source-port 1024-65535
> 
> You can do that, you can't do 'port X', because then anyone setting
> source port to X, allows them to reach any destination port you have.
> I don't think source-port 1024-65534 matters, just additional resource
> consumption. What does matter, is that you match destination-port
> , source-port , when you want to allow far-end
> to respond to connection you opened.
>

i think that /port/ is a crutch :( and best avoided in the case of
loopback filters.  you know exactly what's ok, permit that, drop all
else.

> > > c) LO filter has wide permit instead of accept 1,2,3,4 drop rest
> >
> > how do you mean? doesn't it just permit/deny what you ask in the filter?
> 
> In the relaxed one, they discard non allowed ssh etc, then have wide
> accept. I.e. they don't know what they should accept and what not.
>

i sense you are talking about the 'they' that is cymru.

> > > d) hardcore doesnt permit traceroute
> >
> > traceroute is permitted TO the box with the right config, and THROUGH
> > the box on the MX without any holes in the loopback filter.
> 
> In this config it is not allowed to the box.
>

ah-ha! that's kooky :) (again this is with respect to the cymru doc) I
think the cymru guide is still good, it certainly gives you a leg up
on 'how do I even start?' and PROBABLY is "ok" for an enterprise
deployment. SP deployment will need more  thought, but the
structure is there to build from.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Chris Morrow]

On Wed, 11 Jul 2018 15:14:40 -0400,
Jay Ford  wrote:
> 
> You might want "payload-protocol" for IPv6, except where you really
> want "next-header".  This is a case where there's not a definite
> single functional mapping from IPv4 to IPv6.

unclear why that's important here though? you MAY (and probably do)
have different security requirements between the 2 families, right? so
you're making a policy in ipv4 and you're making one in ipv6.

just use next-header...

(and for a bootstrap the cymru guides really are pretty straightforward)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Chris Morrow]

On Wed, 11 Jul 2018 15:06:43 -0400,
Saku Ytti  wrote:
> 
> I'd say the filters are all kind of broken.
> 
> Just few issues
> 
> a) You can't just limit UDP to 2Mbps on every edge port

it's really a limit of 2mbps on each PFE, so ... in some cases that's
2mbps on a port, in some cases not. This is a 'problem' because of the
architecture of the MX though, right? not the filter itself... well... :)

> b) LO filter matches on 'port'

on 'port'.. meaning I can't do:
  destination-port ssh
  source-port 1024-65535

something like that? or that you wanted to match on:
  port xe-1/0/1.0
 ?

> c) LO filter has wide permit instead of accept 1,2,3,4 drop rest

how do you mean? doesn't it just permit/deny what you ask in the filter?

> d) hardcore doesnt permit traceroute

traceroute is permitted TO the box with the right config, and THROUGH
the box on the MX without any holes in the loopback filter.

On the EX platform though :( sadness reigns.

> 
> Just very short review, to me just these errors are monumental
> misunderstanding of security and goals of filters. To me starting from
> nothing is superior than starting from those.
> 
> On Wed, 11 Jul 2018 at 21:23, Chris Boyd  wrote:
> >
> >
> >
> > > On Jul 11, 2018, at 1:17 PM, Drew Weaver  wrote:
> > >
> > > Is there a list of best practices or 'things to think about' when 
> > > constructing a firewall filter for a loopback on an MX series router 
> > > running version 15 of Junos?
> > >
> > > I'm slowly piecing it together by just 'seeing what is broken next' and I 
> > > have found some issue specific examples on Juniper.net thus far that tend 
> > > to help with some of the issues but if anyone has ever seen a decent 
> > > comprehensive guide that would be tremendously useful.
> > >
> > > If anyone has seen anything like this let me know, if not no worries will 
> > > just keep fixing the things one by one =)
> >
> > Team Cymru has a “JunOS Secure Template” that I found a good place to 
> > start. It quotes version 4 though.  I think that means it’s well tested?
> >
> > http://www.cymru.com/gillsr/documents/junos-template.pdf
> >
> > ―Chris
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> -- 
>   ++ytti
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] certificates and configuration on MX-like devices

[Chris Morrow]

On Thu, 26 Apr 2018 23:06:12 -0400,
Phil Shafer <p...@juniper.net> wrote:
> 
> Chris Morrow writes:
> >it would have helped a bit of the error was more clear :( helped me
> >anyway.  I think it'd also be nice if I could have loaded the key in
> >one element and cert in another... everyone who requires them jammed
> >together does the ordering differently from the last person :(
> 
> We're calling openssl's validation functions and reporting any
> errors returned, since we want our code (in the UI) to be as
> well-separated from the innards of ssl as possible.  The "load-key-file"
> accepts the key and cert in either order, rewriting them in the
> "standard" openssl format.
> 
> >thnx! it does (as you say next) not include the key (which has to have
> >it's passprhase removed) in the pem file, it uses the load-from-file option 
> >which may
> >not be the preferred manner for the particular operator.
> 
> Yes, assigning the value directly is less forgiving, since it doesn't
> perform validation.  But IIRC the key/cert order still doesn't matter.
> We write the value directly into /var/etc/ssl/local/ (with the "\n"s
> unescaped).

ok. good to know.

> >it also seems to suggest that using self-signed certs is ok (it's not,
> >really it's not... setup your own ca, mint certs from it, verify certs
> >on connect) a note in the docs that: "self signed certs invite people
> >to mitm your control/monitoring comms with your network... it invites
> >people to be you on your network and do what you can do...you don't
> >want that to happen, right?" would be great to see.
> 
> True.  I'll pass this along.
> 

terrific, thanks!

> >I'm unsure how I would  have found this document 'quickly', I did several 
> >searches for:
> >  "streaming telemetry ssl certificate"
> 
> FWIW, I googled "junos ssl local certificates" and got a ton of

google? who uses that old thing.. I was using the search feature on
www.juniper.net :)

> pki-related entries, so did "junos ssl local certificates -pki"
> and the docs were the first item returned.
>

ok

> >spreading the configuration requirements far and wide in the
> >support/docs seems counter-productive to letting people self-help to a
> >solution :( it's a shame that the docs aren't more clear and more
> >centralized.
> 
> Completely agree.
> 
> Thanks,
>  Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] certificates and configuration on MX-like devices

[Chris Morrow]

On Thu, 26 Apr 2018 19:45:35 -0400,
Phil Shafer <p...@juniper.net> wrote:
> 
> Chris Morrow writes:
> >ok, cool! so you want cert then key, great! (not clear on the
> >format... but..)
> 
> The easiest way to add certs to config is with the "load-key-file"
> knob:

sure... but ... that's not what the great-god-of-config-pipeline says we do :)
It turns out that:
  1) you can do them cert/key and key/cert (doesnt' seem matter)
  2) you need to make sure that only end-of-line is \n ... not other spaces :(

it would have helped a bit of the error was more clear :( helped me
anyway.  I think it'd also be nice if I could have loaded the key in
one element and cert in another... everyone who requires them jammed
together does the ordering differently from the last person :(

> >ok.. so that's actually: "Private key and Certificate string" It's
> >also not simple to find docs on this at the juniper support site :(
> 
> Here's a too-late-to-help-this-time URL:
> 
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/ex-series-ssl-certificates-generating.html
>

thnx! it does (as you say next) not include the key (which has to have
it's passprhase removed) in the pem file, it uses the load-from-file option 
which may not be the preferred manner for the particular operator.

it also seems to suggest that using self-signed certs is ok (it's not,
really it's not... setup your own ca, mint certs from it, verify certs
on connect) a note in the docs that: "self signed certs invite people
to mitm your control/monitoring comms with your network... it invites
people to be you on your network and do what you can do...you don't
want that to happen, right?" would be great to see.

> It fails to mention that both sections are needed, though this
> kb article does:
> 
> https://kb.juniper.net/InfoCenter/index?page=content=KB19726==LIST
>

I'm unsure how I would  have found this document 'quickly', I did several 
searches for:
  "streaming telemetry ssl certificate"

tried limiting the results to 'router' things (checkbox in results
page)...  searching the kb/support/docs is harder than it seems like
it should be, oh well.

spreading the configuration requirements far and wide in the
support/docs seems counter-productive to letting people self-help to a
solution :( it's a shame that the docs aren't more clear and more
centralized.

> >If your primary/first interaction with 'documentation' is the
> >command-line usage, then ffs please be precise.
> 
> Apologies for this.

end of a long almost done week...
good times.

thanks for taking the time.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] certificates and configuration on MX-like devices

[Chris Morrow]

here's a funny (not) thing:

# set security certificates local boop ?  
Possible completions:
  Certificate and private key string


ok, cool! so you want cert then key, great! (not clear on the
format... but..)

error: Unable to derive certificate from input

is the error I see from:
 -BEGIN\nCERTIFICATE-\nMIIFxjCCA66gA
 ---BEGIN RSA PRIVATE KEY--- 

ok.. funny there was config on this, show|compare
 says:
  - "-BEGIN PRIVATE KEY-\nMIIJQgIB .

ok.. so that's actually: "Private key and Certificate string" It's
also not simple to find docs on this at the juniper support site :(

If your primary/first interaction with 'documentation' is the
command-line usage, then ffs please be precise.



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

Re: [j-nsp] Forced password resets?

[Chris Morrow]

On Thu, 19 Apr 2018 06:56:41 -0400,
Julien Goodwin  wrote:
> 
> What is on-topic is there are some folk looking at standardising TACACS
> as it's actually implemented, and then potentially an enhancement. I'd
> *REALLY* love if client key negotiation of some form was in the
> standard, so I could simply ssh to any router with key auth without
> needing to statically configure keys on each router.
> 
> Draft:
> https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-10

plug for the draft.. folk should read and comment (though I believe
it's almost in wg-LC att his point?)

I believe the planned enhancements were around protocol security and
not authentication methods. (as an fyi, and that could of course
change)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] tl1 transaction language

[Chris Morrow]

At Mon, 11 Dec 2017 15:21:00 +,
heasley <h...@shrubbery.net> wrote:
> 
> Mon, Dec 11, 2017 at 10:07:22AM -0500, Chris Morrow:
> > > What application are you looking to interface with?
> > 
> > there's a significant portion of the networked world that's still
> > doing tl1 (some version of the 'standard'... which is vendor specific,
> > yay!) none of those things are juniper though.
> 
> This is mostly optical/line h/w though; not that we do not have to
> program them, but even they are evolving, slowly.  at least most
> routers/etc have evolved well past tl1 or BayNetworks' cli.  

yup.. lately the optical folk are asking about grpc/yang as I recall.

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

Re: [j-nsp] tl1 transaction language

[Chris Morrow]

At Mon, 11 Dec 2017 00:07:38 -0500,
Phil Shafer  wrote:
> I don't know of any C libraries for TL1, but my guess is that at
> this stage you'd be better off teaching your NMS to work with current
> technologies (NETCONF and YANG) than to teach your devices TL1.

let's do yang! (which is standardized - almost - but still vendor
proprietary - mostly - yay!)

> What application are you looking to interface with?

there's a significant portion of the networked world that's still
doing tl1 (some version of the 'standard'... which is vendor specific,
yay!) none of those things are juniper though.

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

Re: [j-nsp] Moving onto EX2300

[Chris Morrow]

On Wed, 20 Sep 2017 22:29:44 -0400,
Jason Healy <jhe...@logn.net> wrote:
> 
> 
> > On Sep 20, 2017, at 10:10 PM, Chris Morrow <morr...@ops-netman.net> wrote:
> > 
> > man.. I'd like to take a gander at your setup.. because I'm fairly
> > certain I'm going to send this 3400 back and work out my anger on some
> > firewood. :)
> 
> Mail it my way; I'd be happy to have a spare!  I probably have a few
> 3200s left for trade.  ;-)
>

ha :)

> I misread your earlier email; yes, you would need an irb as the L3
> interface for management where you previously used a vlan... a find
> and replace should take care of that, though.
>

ah! ok, so... that's a bit of a bummer, I didn't see this sort of
thing documented in the release-notes, though I admit to quick-skim :(
I suppose I'm really opposed to a mounds turning into an almond joy on
me without pretty clear notice.

> I haven't bumped into the "default VC" port issue yet, but I guess I
> was lucky and chose xe-0/2/3 as my uplink.
>

our standard config was 0 & 1 .. so we just went with that :(
good thing there's a 2 & 3 though :)

> We had some growing pains when we got a QFX5100 for our all-EX
> network and had to adjust to the ELS stuff.  "port" became
> "interface", "vlan" became "irb", etc.  Plus they moved a bunch of
> stuff around.
>

I think we don't actually do the ELS functions, and at other places
i've run into the QFX I hadn't notice this problem either, but... I
also don't deploy switch stacks (voodoo!) and we happen to treat the
qfx more like a tiny router ... that has a slew of lan ports :(

> Juniper does have a conversion tool where you dump in your non-ELS
> config and it will output the ELS version (requires JTAC login).  It
> wasn't perfect, but if you work through it by hand you can figure most
> of it out:
> 
>   
> https://www.juniper.net/customers/support/configtools/elstranslator/index.jsp
>

ok, cool.. this would be handy for 'not this time' switch installs :)
I think I'll also just update my 'make me a switch!' script to just do
the right thing here... we were over eager and tried to mangle the config
by hand.. oops.

> Since we did the QFX a couple years ago, once the 3400s, I was
> familiar enough that it wasn't a huge deal.
> 
> The commit script I wrote lets you put stuff like this in the config:
> 
>   interfaces {
> ge-0/0/0 {
>   apply-macro sa-portrole {
> role static;   # or trunk/dot1x
> vlan some-vlan;
>   }
> }
>   }
>

oh,that's pretty neat.. i think we just whack on the port types with
an apply-group choice (and then add the vlan, of course). I tried to keep the 
ports 'simple':
  TRUNK-PORT -> carry all vlans, used to link to the core.
  EDGE-PORT -> connect hosts, don't trunk...

we aren't 100% that simple, but.. mostly :)

> I just finished that last month, so I'm still rolling it out.  Happy
> to share if you think it will help.  Unfortunately, it won't paper
> over the other ELS differences for you; just the stuff dealing with
> VLANs, trunk/access, STP, and dot1x.
>

ah. .I'll see how the now-working-ports 3400 fares, hopefully less
headaches than so far ;)

thanks! (for also making me re-think and find the other ports
solution) -chris
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [JUNK] Re: Moving onto EX2300

[Chris Morrow]

On Wed, 20 Sep 2017 20:46:19 -0400,
Jason Healy <jhe...@logn.net> wrote:
> 
> On Sep 20, 2017, at 2:18 PM, Chris Morrow <morr...@ops-netman.net> wrote:
> > 
> > I found the 3400's are painfully different from 3300/3200's.. with
> > respect to vlans, trunks and access port assignment into said
> > vlans.. and actually getting traffic to traverse a trunk port to an
> > access port.
> 
> Amen.  I've finally written a commit script that allows me to assign
> roles to ports and then sets the correct config options depending on
> platform.  That's making my life a little easier.

man.. I'd like to take a gander at your setup.. because I'm fairly
certain I'm going to send this 3400 back and work out my anger on some
firewood. :)

> 
> > this coupled with what seems a requirement to enable an IRB interface
> > to attach the management ip address to seems ... wonky.
> 
> What's this one?  I don't remember having to do that part on my
> switch.  That said, I'm currently hunting down some weird disconnect
> issues on my 3400s so maybe I do...

Since all of our 33/3200's have a mgmt-vlan trunked down to them and
an l3 interface configured like:

# show interfaces vlan unit 1
unit 1 {
description "VLAN 1 (INFRA)";
family inet {
address 192.168.88.150/28;
}
}

and the vlans portion:
INFRA {
description "VLAN 1 (INFRA)";
vlan-id 1;
l3-interface vlan.1;
}


That config doesn't appear to work in the same fashion...
Oh, in dicking around.. it looks like:
FPC 0REV 14   650-0   NX021 EX3400-48T
  CPU BUILTIN  IN   FPC CPU
  PIC 0  REV 14   BUILTIN  IN   48x10/100/1000 Base-T
  PIC 1  REV 14   650-0   NX02  2x40G QSFP
  PIC 2  REV 14   650-0   NX02  4x10G SFP/SFP+
Xcvr 2   REV 01   740-0   FS40  SFP+-10G-LR
Xcvr 3   REV 01   740-0   FS40  SFP+-10G-LR
Power Supply 0   REV 05   640-0   1EDV  JPSU-150W-AC-AF

If I put the sfp+'s in slot 0 and 1 ... I can't get packets up the
trunk and to devices downstream to hosts. If I put the sfp+'s in 2 and
3...works like a charm.

So, it smells like the 0 and 1 are 'virtual chassis ports'... even
though i can't unconfigure them from the VC setup?

Now, when I try to revert the IRB to VLAN L3-interface setup, I see
this in config mode:

{master:0}[edit vlans INFRA]
cmorrow@EX3400-0401# set l3-interface vlan.1 
error: l3-interface: 'vlan.1': Only IRB interface is supported, e.g. irb.10


so... I'm pretty sure i'm not going to be able to have the same config
from 3300->3400 :( unless, of course it's clear I messed something up
to other folk?

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

Re: [j-nsp] Moving onto EX2300

[Chris Morrow]

At Wed, 20 Sep 2017 17:03:21 +,
Raphael Maunier  wrote:
> 
> Not supported at all.
> 
> According to a meeting last week, hardware limitation … EX2200 or
> 3400 but no support of BGP, if bgp is needed EX3300 / 4300
> 

I found the 3400's are painfully different from 3300/3200's.. with
respect to vlans, trunks and access port assignment into said
vlans.. and actually getting traffic to traverse a trunk port to an
access port.

this coupled with what seems a requirement to enable an IRB interface
to attach the management ip address to seems ... wonky.

I don't find the docs online particularly enlightening either :) I
have a 3300 config, it should 'just work' on a 3400.. I would have
expected anyway.

also, I don't think you can disable the VC functions in the
3400:
@EX3400-0401> show chassis hardware 
Hardware inventory:
Item Version  Part number  Serial number Description
ChassisNX0217020007  EX3400-48T
Pseudo CB 0 
Routing Engine 0  BUILTIN  BUILTIN   RE-EX3400-48T
FPC 0REV 14   650-059881   NX0217020007  EX3400-48T
  CPU BUILTIN  BUILTIN   FPC CPU
  PIC 0  REV 14   BUILTIN  BUILTIN   48x10/100/1000 Base-T
  PIC 1  REV 14   650-059881   NX0217020007  2x40G QSFP
  PIC 2  REV 14   650-059881   NX0217020007  4x10G SFP/SFP+
Xcvr 0   REV 01   740-021309   FS40531D0014  SFP+-10G-LR
Xcvr 1   REV  740-021309   FS40531D0015  SFP+-10G-LR
Power Supply 0   REV 05   640-060603   1EDV6486028   JPSU-150W-AC-AFO
Power Supply 1   REV 05   640-060603   1EDV7021509   JPSU-150W-AC-AFO
Fan Tray 0   Fan Module, Airflow 
Out (AFO)
Fan Tray 1   Fan Module, Airflow 
Out (AFO)

(port xe-0/2/0 and xe-0/2/1 are what I'd like to disable)

@EX3400-0401> request virtual-chassis vc-port delete pic-slot 2 port 0
error: interface not a vc-port
@EX3400-0401> request virtual-chassis vc-port delete pic-slot 2 port 1
error: interface not a vc-port

of course, possibly they are not vc-ports, and are only acting like 3300 vc 
ports before I diable VC functionality :)

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

Re: [j-nsp] EX4600 : Ping problem

[Chris Morrow]

SAt Mon, 28 Nov 2016 20:55:04 +0100 (CET),
Deloin via juniper-nsp  wrote:
> 
> 
> Hello, 
> 
> I have 2 EX4600 switchs. 
> They have the same symetric configurations: 
> 
> 
> SWITCH EX4600-1SWITCH EX4600-2 
> 
> interfaces {   interfaces { 
>   xe-0/0/1 { xe-0/0/1 { 
> unit 0 {   unit 0 { 
>   family ethernet-switching {family ethernet-switching { 
> interface-mode access; interface-mode access; 
> vlan { vlan { 
>   members vlan-RESEAUX;  members vlan-RESEAUX; 
> }  } 
> storm-control default; storm-control default; 
>   }  } 
> }  } 
>   }  }
>  
>   irb {  irb { 
> unit 0 {   unit 0 { 
>   family inet {  family inet { 
> address 10.101.0.4/16; address 10.101.0.5/16; 
>   }  } 
> }  } 
>   }  } 
> }  } 
> 
> 
> routing-options {  routing-options { 
>   static {   static { 
> route 0.0.0.0/0 next-hop 10.101.0.1;   route 0.0.0.0/0 next-hop 
> 10.101.0.1; 
>   }  } 
> }  } 
> 
> 
> vlans {vlans { 
>   default {  default { 
> vlan-id 1; vlan-id 1; 
>   }  } 
> 
>   vlan-RESEAUX { vlan-RESEAUX { 
> vlan-id 98;vlan-id 98; 
> l3.interface irb.0;l3.interface irb.0; 
>   }  } 
> }  } 
> 
> I put an optic fiber between xe-0/0/1 from a switch and xe-0/0/1 from the 
> other switch.
> And I can't ping the @ 10.101.0.3 and 10.101.0.4 from each switchs.

you appear to have 2 interfaces connected, with a single fiber and a
/16 netblock assigned.  Then you ping .3 which is on neither
interface, so ... 'no route to host' normally means 'did not get an
arp reply, could not deliver packet'.

this sounds like it's working exactly as expected?

> I obtain :
> root@EX4600-01# run ping 10.101.0.3
> PING 10.101.0.3 (10.101.0.3): 56 data bytes
> ping: sendto: No route to host
> ping: sendto: No route to host
> ping: sendto: No route to host
> ping: sendto: No route to host
> the same for the other.
> 
> Can you help me. Can you tell me where is the mistake, or what I forget ?
> 
> Thank you !
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[Chris Morrow]

At Mon, 28 Nov 2016 19:17:41 +,
"Alex K."  wrote:
> 
> Thank you Tim and Chris,
> 
> But correct me if I'm wrong - those are not quite the same thing.
> 
> There's no doubt packets are reaching the box (I have PC connected directly
> to the switch).
> 
> The difference between traffic monitoring/mirroring and Ciscos' debug, is
> that with debug you follow the path a packet takes.
> 
> Traffic monitoring can be a really helpful first step (as I've said, there
> virtually no doubt the packets are reaching the RE), but my question is
> about - what's next?
> 
> Assumed you see only echo requsts and no replies (by "monitor traffic", for
> example), is there is a trace option to show why an EX decided it shouldn't
> answer with reply (from its own address)?

honestly it's not that hard to tell what went wrong:
  1) route back to the source is broken/unknown
  b) loopback filter dropped inbound packet
  z) ... that's it.

or that's been my experience.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[Chris Morrow]

At Mon, 28 Nov 2016 18:43:02 +,
"Alex K."  wrote:
> 
> Hello everyone,
> 
> By any chance - is there an equivalent for Ciscos' "debug ip packet"
> command in Juniper?
> 

monitor packet ...

or start shell - su - tcpdump
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Limit on the number of BGP communities a route can be tagged with?

[Chris Morrow]

At Tue, 23 Aug 2016 14:04:35 +0100,
James Bensley  wrote:
> 
> Hi,
> 
> Hopefully not completely hijacking this thread; I'm interested to know
> if there is a way I can limit a peer to a maximum number of
> communities?

term LIMIT-COMMUNITIES {
from {
  protocol bgp;
  community-count 50 orhigher;
}


salt and pepper and use as appropriate... note you might break yourself.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chris Morrow]

On 05/08/2015 03:15 PM, Colton Conor wrote:
 use multiple cores

please define this better.
Does their version of rpd actually get multi-threaded? and end up using
more than 1 core at once? does the 'rpd' get stuck to a single core and
everything else floats around on several more?

this is what, in a sense, newer junos does... nothing you care about is
multithreaded (or just straight smp), but the underlying fbsd is so
somethings run on other cores.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chris Morrow]

On 05/08/2015 02:08 PM, Colton Conor wrote:
 So are the other vendors, Brocade, Cisco and ALU all single core in
 software as well, or is this just a Juniper thing? Whats the point of

yes, mostly (not xr I think, if I recall correctly)

 having all these cores on the RE's if you unable to use be one of them?

can't buy a single core intel/amd chip anymore?



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

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

[Chris Morrow]

On 05/08/2015 04:05 PM, Alastair Johnson wrote:
 Yes, routing protocols on SR OS use multiple cores (within protocols, and 
 across protocols).
 
 Feel free to contact me off-list, or on alcatel-nsp, for further discussion.

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

Re: [j-nsp] Juniper authorization with tacacs+

[Chris Morrow]

On 04/13/2015 11:01 AM, Eduardo Barrios wrote:
 When I tested this a while back I could not get the allow-commands
 attribute to work. The deny-commands attribute does work however. So
 our ACS shell-profile read only group we had to start with a junos
 login with a super-user class then use the deny-commands attribute
 to strip the access ...request, restart, configure, etc.
 

it might help you to look in /var/tmp on the juniper when the affected
user is logged in.. there will be a file named per the user's login PID
which has their access requirements outlined. You can probably reverse
engineer the right answer from that data.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Discard Interface

[Chris Morrow]

On 04/07/2015 01:46 PM, harbor235 wrote:
 Correct, I see rpf failures, however the firewall log specified on the
 dsc.0 interface is the reporting filter of the discarded traffic? Is there
 a solution to correct the problem?
 

I'm not a juniper engineer, but I believe most of their decisions are
made (for acls) on input, so I bet they can't do what you want... unless
you remove the dsc.0 deny and let the traffic flow out the dsc.0
interface (of course it won't go anywhere, but it might start counting
on the interface for you).

it's been a while since I looked at this in particular.

 
 Mike
 
 On Tue, Apr 7, 2015 at 1:29 PM, Chris Morrow morr...@ops-netman.net wrote:
 


 On 04/07/2015 01:23 PM, harbor235 wrote:
 I am having issues updating interface stats via the discard interface,
 dsc.0

 I have successfully setup a trigger router for injecting routes I need
 discarded at the edge.
 The Edge router is a J series router (J2350) I have configured S/RTBH
 routing and I am using dsc.0 for discarded traffic, coloring, and
 logging.

 My problem, traffic is discarded correctly, the output filter configured
 on
 the dsc.0 interface correctly logs and discards the traffic. This is
 verified via the :show firewall log cmds, but, I see no stats updates
 via
 show interface dsc.0 extensive  for the dsc.0 interface. The route for
 the discarded prefix(s) correctly points to the destination address of
 the
 dsc.0 interface.  What am i missing here? Should I expect traffic stats
 on
 dsc.0 and the firewall log output?

 I bet you see discards on the input interface.
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Discard Interface

[Chris Morrow]

On 04/07/2015 01:23 PM, harbor235 wrote:
 I am having issues updating interface stats via the discard interface, dsc.0
 
 I have successfully setup a trigger router for injecting routes I need
 discarded at the edge.
 The Edge router is a J series router (J2350) I have configured S/RTBH
 routing and I am using dsc.0 for discarded traffic, coloring, and logging.
 
 My problem, traffic is discarded correctly, the output filter configured on
 the dsc.0 interface correctly logs and discards the traffic. This is
 verified via the :show firewall log cmds, but, I see no stats updates via
 show interface dsc.0 extensive  for the dsc.0 interface. The route for
 the discarded prefix(s) correctly points to the destination address of the
 dsc.0 interface.  What am i missing here? Should I expect traffic stats on
 dsc.0 and the firewall log output?

I bet you see discards on the input interface.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper MX and VZ FIOS question

[Chris Morrow]

Think their edge for FiOS is still erx, no?

And I think the Mac stuff is from the Alcatel olt, not the upstream erx.

Its Ethernet to you but gpon to them, eh?On Mar 5, 2015 2:34 PM, Chris Evans 
chrisccnpsp...@gmail.com wrote:

 I'm a FIOS user and they use Juniper MX in many locations (along with E 
 series in older installs) and I'm curious of a typical configuration they'd 
 be using. WIth FIOS I just have a straight ethernet connection, no logging 
 in, no providing user information, etc.. 

 So since i'm not logging in would that still be a BRAS configuration? 
 Also they have a feature enabled that poisons ARP entries if you try to put 
 a box on the wire that has a different IP than what your DHCP lease is 
 given you. What feature would that be? 

 Very curious how they'd do this. I've only worked with JUNOS boxes in the 
 enterprise so I don't have experience with features like this. 
 ___ 
 juniper-nsp mailing list juniper-nsp@puck.nether.net 
 https://puck.nether.net/mailman/listinfo/juniper-nsp 
___
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..

[Chris Morrow]

On 02/13/2015 05:02 AM, Harald wrote:
 On 13.02.2015 13:06, Phil Mayers wrote:
 On 13/02/15 10:34, Harald wrote:
 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?
 I haven't tried it on EX3300 yet, but I have tested it on EX2200 and
 judging from the tests I did it is working fine there.
 

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.

also, is traceroute through an EX fixed for loopback filtering yet? no.
___
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..

[Chris Morrow]

On 02/12/2015 04:08 PM, 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 nice... still unhappy (though it's not purely a docs problem,
clearly) with the fact that the commit is silently death, AND fixing
that requires on/off the interface gymnastics.

 
 
 Le 12 févr. 2015 à 22:55, Chris Morrow morr...@ops-netman.net a écrit :

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

 read this:
 The maximum number of terms allowed per firewall filter for EX Series
 switches is:

 512 for EX2200 switches
 1,436 for EX3300 switches


 Uhm.. 1436 looks like the number of TCAM entries, NOT the number of
 terms. great. thanks.

 Also:
 Note: On EX3300 switches, if you add and delete filters with a large
 number of terms (on the order of 1000 or more) in the same commit
 operation, not all the filters are installed. You must add filters in
 one commit operation, and delete filters in a separate commit operation.

 Really?? it silently doesn't work?? what?? and this is probably not
 'terms' but 'tcam entries' I bet, which the average user probably
 doesn't know either. Great.

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

 EX2200 switch
 EX3200 switch
 EX4200 switch
 EX4500 switch
 EX8200 switch
 You can apply port, VLAN, or router firewall filters to only IPv4
 traffic on these switches:

 EX3300 switch
 EX6200 switch

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

 Also, in case that your firewall filter is over-spec and can't be
 committed to TCAM the user has zero idea of this... Then once you fix it
 (if you figured it out) you have to remove the filter from the interface
 THEN reapply it?

 This is ... very, very poor. The docs need work, the operational model
 is broken ... Do you operate your own gear in actual networks and NOT
 see these as problems? Could you ask your IT folks about this sort of
 operational model and see how they react?

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

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

[Chris Morrow]

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

read this:
The maximum number of terms allowed per firewall filter for EX Series
switches is:

512 for EX2200 switches
1,436 for EX3300 switches


Uhm.. 1436 looks like the number of TCAM entries, NOT the number of
terms. great. thanks.

Also:
Note: On EX3300 switches, if you add and delete filters with a large
number of terms (on the order of 1000 or more) in the same commit
operation, not all the filters are installed. You must add filters in
one commit operation, and delete filters in a separate commit operation.

Really?? it silently doesn't work?? what?? and this is probably not
'terms' but 'tcam entries' I bet, which the average user probably
doesn't know either. Great.

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

EX2200 switch
EX3200 switch
EX4200 switch
EX4500 switch
EX8200 switch
You can apply port, VLAN, or router firewall filters to only IPv4
traffic on these switches:

EX3300 switch
EX6200 switch

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

Also, in case that your firewall filter is over-spec and can't be
committed to TCAM the user has zero idea of this... Then once you fix it
(if you figured it out) you have to remove the filter from the interface
THEN reapply it?

This is ... very, very poor. The docs need work, the operational model
is broken ... Do you operate your own gear in actual networks and NOT
see these as problems? Could you ask your IT folks about this sort of
operational model and see how they react?

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

Re: [j-nsp] BGP error with optional attribute

[Chris Morrow]

On 12/19/2014 10:30 AM, thiyagarajan b wrote:
 Hi everyone,
 
 I have a problem in iBGP between Cisco 7301 and juniper mx series router
 where the BGP got flapped throwing the following error in cisco end:
 
 %BGP-3-NOTIFICATION: received from neighbor 119.227.0.65 3/9 (unsupported
 option specified) 0 bytes
 %BGP-5-ADJCHANGE: neighbor 119.227.0.65 Down BGP Notification received
 
 %BGP-3-NOTIFICATION: received from neighbor 119.227.0.65 6/5 (cease) 0 bytes
 
 and found the following log in juniper
 
 rpd[1296]: bgp_read_v4_update:9690: NOTIFICATION sent to 210.18.0.181
 (Internal AS 9583): code 3 (Update Message Error) subcode 9 (error with
 optional attribute), Reason: peer 210.18.0.181 (Internal AS 9583) UPDATE -
 NLRI inet6-unicast not negotiated
 rpd[1296]: Received BAD update from 210.18.0.181 (Internal AS 9583), family
 inet6-unicast(16), prefix 2a02:2158::/32
 
 So is this problem caused by the prefix 2a02:2158::/32 because of it
 invalid attribute? or is it because of any mismatch SAFI update between the
 routers?

the error sounds like the peers negotiated afi/safi stuff for 'not ipv6
unicast' and then the peer stuffed a v6 nlri down the pipe to you... So,
their implementation boarked up.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DDOS_PROTOCOL_VIOLATION_SET: Protocol Reject:aggregate

[Chris Morrow]

On 12/10/2014 09:54 PM, Wojciech Janiszewski wrote:
 Hi,
 
 Make sure that you have a discard next-hop instead of default reject in
 your aggregate routes.
 That should help.

ick, that ddos protection stuff in JunOS is broken...you should just
disable it:
system {
ddos-protection {
global {
disable-routing-engine;
disable-fpc;
disable-logging;
}
}
}



 2014-12-10 23:16 GMT+01:00 Brendan Mannella bmanne...@teraswitch.com:
 
 Just wondering if anyone has ever seen these DDOS messages before and
 what i should be looking at to resolve.

 Dec 10 11:10:24  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 931 times, from 2014-12-10 11:05:23
 EST to 2014-12-10 11:05:23 EST

 Dec 10 11:23:44  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
 Protocol Reject:aggregate is violated at fpc 1 for 932 times, started
 at 2014-12-10 11:23:43 EST

 Dec 10 11:28:49  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 932 times, from 2014-12-10 11:23:43
 EST to 2014-12-10 11:23:43 EST

 Dec 10 12:50:55  re0.edge2 xntpd[2681]: kernel time sync enabled 6001

 Dec 10 13:08:00  re0.edge2 xntpd[2681]: kernel time sync enabled 2001

 Dec 10 15:01:34  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
 Protocol Reject:aggregate is violated at fpc 1 for 933 times, started
 at 2014-12-10 15:01:33 EST

 Dec 10 15:06:34  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 933 times, from 2014-12-10 15:01:33
 EST to 2014-12-10 15:01:33 EST
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] DDOS_PROTOCOL_VIOLATION_SET: Protocol Reject:aggregate

[Chris Morrow]

On 12/10/2014 11:21 PM, Giuliano (WZTECH) wrote:
 Chris
 
 The best option is to disable the feature ?
 

I think it's the best option.. juniper tried to do something 'nice' for
you by setting some low (I think) limits on things you might actually
care to see and deal with elsewhere...

 And about to configure it ?
 
 If you have a protect-re firewall filter applied in loopback ... Can this be 
 done ?
 

all devices on the public network should have clear policies in place to
protect themselves from the rest of the world. Your juniper loopback
filter should permit the routing protocols you care about and your
management access... and everything else should be discarded. Cymru's
templates are decent for this actually.

-chris

 Is it safe ?
 
 Some documents from juniper showing the best way ?
 
 And about to disable the process ?
 
 Thanks a lot
 
 
 
 Sent from my iPhone
 
 On Dec 11, 2014, at 01:20, Chris Morrow morr...@ops-netman.net wrote:



 On 12/10/2014 09:54 PM, Wojciech Janiszewski wrote:
 Hi,

 Make sure that you have a discard next-hop instead of default reject in
 your aggregate routes.
 That should help.

 ick, that ddos protection stuff in JunOS is broken...you should just
 disable it:
 system {
ddos-protection {
global {
disable-routing-engine;
disable-fpc;
disable-logging;
}
}
 }



 2014-12-10 23:16 GMT+01:00 Brendan Mannella bmanne...@teraswitch.com:

 Just wondering if anyone has ever seen these DDOS messages before and
 what i should be looking at to resolve.

 Dec 10 11:10:24  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 931 times, from 2014-12-10 11:05:23
 EST to 2014-12-10 11:05:23 EST

 Dec 10 11:23:44  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
 Protocol Reject:aggregate is violated at fpc 1 for 932 times, started
 at 2014-12-10 11:23:43 EST

 Dec 10 11:28:49  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 932 times, from 2014-12-10 11:23:43
 EST to 2014-12-10 11:23:43 EST

 Dec 10 12:50:55  re0.edge2 xntpd[2681]: kernel time sync enabled 6001

 Dec 10 13:08:00  re0.edge2 xntpd[2681]: kernel time sync enabled 2001

 Dec 10 15:01:34  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
 Protocol Reject:aggregate is violated at fpc 1 for 933 times, started
 at 2014-12-10 15:01:33 EST

 Dec 10 15:06:34  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 933 times, from 2014-12-10 15:01:33
 EST to 2014-12-10 15:01:33 EST
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Authentication Keys

[Chris Morrow]

On 07/23/2014 08:56 AM, Mohammad Khalil wrote:
 Thanks for the great help
 
 
 On Wed, Jul 23, 2014 at 3:41 PM, Alexander Arseniev arsen...@btinternet.com
 wrote:
 
  http://www.password-decrypt.com
  allows you to decrypt Juniper $9$ passwords and Cisco 7 passwords.

is putting your hashed passwd into a form on the web a really good idea?

Kevin Brintall wrote a perl (and ported it to python though I can't find
that right now) bit that does this encrypt/decrypt for you, here's his
perl module:

http://search.cpan.org/dist/Crypt-Juniper/lib/Crypt/Juniper.pm

please don't put your passwd into some web form :(
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] configuration archival, commit comments

[Chris Morrow]

On 03/20/2014 09:50 AM, Mike Williams wrote:

Hi all,

Random thought for the day.

You can archive the entire config after each commit (archival configuration
transfer-on-commit).
You can apply a comment to each commit (# commit comment blah)

How do you archive that comment?



/var/db/commits seems to have the content you care about
/var/db/config/juniper.conf.##.gz - seems to be the historical configs


It's not included in the config.


Thanks


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

Re: [j-nsp] NTP Reflection

[Chris Morrow]

On 01/14/2014 09:19 AM, Chris Adams wrote:
 Once upon a time, Olivier Benghozi olivier.bengh...@wifirst.fr said:
 Because if you don't do it, you'll obtain some nice Server Timeout if you 
 want to issue a show ntp status or show ntp associations.
 So:
 - Junos doesn't use 127.0.0.1 to locally communicate with ntpd
 - In you filters you're obliged to manually authorize internal private IP 
 traffic used by the CLI and that doesn't even leave the RE

 Another fine design...
 
 Seems like a good case for a commit script to auto-build the filter
 rule from configured NTP servers and configured loopback addresses.

set policy-options prefix-list local-interfaces apply-path  \
interfaces * unit * family inet address *

set policy-options prefix-list local-v6-interfaces apply-path \
interfaces * unit * family inet6 address *:*

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

Re: [j-nsp] Format of SHA1 Passwords

[Chris Morrow]

On 12/03/2013 11:31 AM, Chip Marshall wrote:
 I'm trying to write a utility for generating JUNOS-compatible
 password hashes outside of JUNOS, and I've hit a bit of a
 stumbling block with JUNOS SHA-1 passwords. They don't seem to
 follow the normal crypt() pattern of $format$salt$hash and I
 can't seem to find the format documented anywhere.
 
 I get things like $sha1$19418$aoTClyGU$cix8MhZsXwG6OrwUgeHAoOA8f.AX
 where it appears to have the format, some number, what I think is
 the salt, and then the hash.
 
 Anyone know how these things are calculated?
 

we do this calculation I believe your intended format is:
  $1$salt$hash

or that seems to be what our code does.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Format of SHA1 Passwords

[Chris Morrow]

On 12/03/2013 11:46 AM, Chip Marshall wrote:
 On 2013-12-03, Chris Morrow morr...@ops-netman.net sent:
 I get things like $sha1$19418$aoTClyGU$cix8MhZsXwG6OrwUgeHAoOA8f.AX
 where it appears to have the format, some number, what I think is
 the salt, and then the hash.

 Anyone know how these things are calculated?

 we do this calculation I believe your intended format is:
   $1$salt$hash

 or that seems to be what our code does.
 
 That's for MD5 passwords. I have a requirement to use SHA-1.

oh, ha! :( hrm... so, I set a passwd of 'flipfl0p!' for a user after
setting the passwd format to sha1 ... and I see:

$sha1$19295$mROzSQ4a$SFnJ1fAbP4cHqw/16.xDV4s1LpMA

and yea the format isn't as simple as:

 import hashlib
 p = 'flipfl0p!'
 s = 'mROzSQ4a'
 hashlib.sha1(p+s).hexdigest()

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

Re: [j-nsp] Keeping firewall rules synced on two edge routers, multihomed setup?

[Chris Morrow]

On 10/11/2013 08:24 PM, Frank Sweetser wrote:
 
 I'd definitely look at setting up an external source that pushes to both
 routers.  You can either use the netconf or junoscript API yourself, or
 if you have any in-house linux experience you can check out the ansible
 based automation that Jeremy Schullman has been putting together:
 
 https://github.com/jeremyschulman
 

would a python based, multi-threaded juniper/cisco/force10/brocade able
system be helpful to the OP? we happen to be polishing up some
additional bits to release with:
  http://code.google.com/p/capirca
which we use for this sort of thing at work...

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

Re: [j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

[Chris Morrow]

On 08/02/2013 04:26 AM, Sebastian Wiesinger wrote:
 So, it's friday and there is PSN-2013-08-987. Am I overlooking
 something or is that only a problem for people who speak OSPF with
 other parties (customers, strangers,...)? I don't see the big attack
 vector in comparison to speaking OSPF with others in the first
 place...

or maybe people that mistakenly turn it on on 'external' (not network
facing) interfaces... like lan interfaces.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

[Chris Morrow]

On 08/02/2013 05:17 AM, Sebastian Wiesinger wrote:
 Yes, that could be possible but that would allow the external party
 to mess with OSPF anyway...

doesn't mean it doesn't happen :)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QoS - to share a network control queue or not?

[Chris Morrow]

On 01/11/2013 05:08 PM, Eduardo Barrios wrote:

 Is it ok to mix a customer's NC with our MPLS NC? How do service
 providers handle this?

that seems bad... now their bgp overrides your bgp (maybe) choking out
the management and control of your network elements, leading to an
outage of not just that one customer but all customers (or more than 1
at the least).

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

Re: [j-nsp] EX Switch Question

[Chris Morrow]

On 01/10/2013 10:21 AM, Paul Stewart wrote:
 Thank you - yes, both of those issues you highlighted have created problems
 for us  especially lack of tcp established

note also that (i believe still) packets which would pass through the
box (when it's doing L3 things) but expire on the box... must be
accounted for in the loopback filter, if you want to see ttl-expired
messages.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DDOS and MX-240's

[Chris Morrow]

On 01/08/2013 04:43 AM, Christian wrote:
 I confirm Alcatel has also implemented flowspec on their device.
 On our side we also use it moderately on our backbone ; it is very easy
 to implement and much more powerful than rtbh.

  ^just

never is there only a single tool...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DDOS and MX-240's

[Chris Morrow]

On 01/08/2013 04:47 PM, Darius Jahandarie wrote:
 On Tue, Jan 8, 2013 at 3:30 PM, Richard A Steenbergen r...@e-gerbil.net 
 wrote:
 I did warn Terry about this issue before he gave that presentation, but
 note that their performance requirements are MUCH lower than mine. The
 graphs in this presentation show 100-1000Mbps attacks and 45kpps
 attacks, which doesn't require much in the way of router resources. Line
 
 It shows a 45Gbit/s 14Mpps attack in that presentation. Pretty
 sizable, for me at least.
 

not a single interface, probably... since terry doesn't have a 45gbps
interface. richard's numbers were for a single interface, right?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DDOS and MX-240's

[Chris Morrow]

On 01/06/2013 11:14 PM, Richard Gross wrote:
 Dear List,
 
 I am seeking advise.  If you wanted to block 800K /32's from your inbound
 pipes, how would you do it?

you might be able to do this with routes... but, ouch... depending on
the RE you'll be straining the limits :(

 Would you null route?   Put up multiple stanza firewall filters?   Which
 way has the least amount of hit on router resources?

you might not want to put in 800k route entries in your config :) but
you could do it with simple bgp session to a quagga/etc box instead.

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

Re: [j-nsp] Migration from IGP to e-BGP

[Chris Morrow]

On 12/30/2012 12:31 PM, tim tiriche wrote:
 I didn't mean confederations.
 

yes you did, according to your diagram...

 May be a diagram would be better.
 
 Current design: (ASN: 1234)
 
 (Customer-A) --(ebgp) --[[ (Area 10) --- (Area 0) --- (Area 20) ]]--
 (ebgp)-- (Customer-B)
 
 IGP is running in Area 0 for P2P and loopbacks.
 Area10, Area0 and Area20 are part of one Administravie domain
 representing ASN: 1234.
 Area10, Area20 has its own customers.
 
 
 New Proposed design:
 
 Remove Area10 and Area20 and instead use E-BGP.

this sort of sounds like the wrong hammer to be using... to me at least.

 Area10 would become ASN65010, Area20 would become ASN65020 and run
 their own IGP.

why? don't you want the edge device(s) in 20/10 to be able to benefit
from the whole IGP knowledge across your domain? breaking things up into
different igps seems more complicated than it needs to be, to me.

 ASN65010 would be a customer of ASN1234.
 

yea.. no.
I really think you mean that the confed-as is 1234 and
65010/65020/65core are all parts of the confederation. If done this
way your customers continue to be peered with 1234 and you just migrate
things to a more stable/scalable solution over a few weeks work.

 Problem:
 If Area10 becomes ASN65010, what happens to the customer who peers with 
 ASN1234?
 I still want the customer to peer with ASN1234 and customer should not
 be aware of ASN65010.

right, that's what confederations are for (well, one purpose of them).

The OTHER option is to use some of the whackitude that is 'peer-as' in
the juniper world and hide your ASN change from the customers... this
has longer term maintenance headache implications, and most uses of it
are for MA situations: We just bought AS12, let's make them part of
our AS: AS1, and slowly convert all customers we can talk to, meanwhile
'peer-as' all customer sessions so they appear to still connect to AS4,
while the edge devices are re-homed into AS1

it's messy and will cause operations problems in the long term...

-chris


 
 Sincerely,
 -Tim
 
 
 
 On Fri, Dec 28, 2012 at 10:33 PM, Christopher Morrow
 morr...@ops-netman.net wrote:
 (Android mail sucks, sorry)

 I think the OP means confederation not 'private islands' And they'll 
 have to do some planning to move to confederations.

 More importantly, why get rid of your igp? Are you not already doing route 
 reflection and/or ibgp full mesh ?

 Justin M. Streiner strei...@cluebyfour.org wrote:

 On Fri, 28 Dec 2012, tim tiriche wrote:

 We have multi area OSPF and would like to migrate the multi area to
 private ASN BGP islands.

 How are you defining an 'island'?

 Main ASN:1234

 Problem:

 In the current OSPF areas there is an e-BGP Peering and Transit with 
 customer.
 After migration, how can i ensure that customer peer using the Main
 ASN:1234 and transport it over the core?

 Peering and Transit mean two different things to a number of people
 who read this mailing list.  I'm guessing you mean one or the other (most
 likely transit)?

 If the customers speak eBGP with you today, and your end of the session is
 in AS1234, then the customer's traffic will transit AS1234, depending on
 what you do with the traffic while it's on your network.  If I'm
 understanding your intentions correctly, what do you hope to gain, or what
 problem are you trying to solve by creating 'private ASN BGP islands'?

 If the issue is reducing the number of IBGP sessions on your backbone,
 have a look at route reflectors and BGP confederations.

 How have others done it?

 In my past life, we spoke eBGP with our downstream customers.  Either the
 customers had their own public ASN, or we used another public ASN that we
 had available at the time.  Private ASNs were used in a few corner cases.
 The latter two approaches impose limitations that might not be acceptable
 for some customers.  YMMV.

 jms

 Loops, local-as? Would independent domain help?

 Looking for suggestions.

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

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

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

Re: [j-nsp] Http/1.1 404 to block on juniper Srx (Humair Ali)

[Chris Morrow]

On 10/24/2012 03:44 PM, Humair Ali wrote:
 I have juniper srx 240 want to block http

how about just deny destination port 80?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Woot. Updated MX software recommendation

[Chris Morrow]

On 04/11/2012 12:09 PM, Alexandre Snarskii wrote:

 PS: to whom it may concern: SNMP counters in 11.4R2 broken even worse 
 than in 11.4R1. Looks like the same PR/731833, 
 http://puck.nether.net/pipermail/juniper-nsp/2012-February/022369.html

counting is hard... let's go shopping?? wtf?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Woot. Updated MX software recommendation

[Chris Morrow]

That's what net flow is for! Wait... doh!

Richard A Steenbergen r...@e-gerbil.net wrote:

On Wed, Apr 11, 2012 at 01:19:01PM -0400, Chris Morrow wrote:
 
 counting is hard... let's go shopping?? wtf?

Yeah, it's not like we need to bill customers with these routers or 
anything. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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

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

[Chris Morrow]

On 12/14/2011 04:56 PM, Morgan McLean wrote:

How does that kind of code even pass QA to start? I really don't understand.


to be clear here... you are talking about the EX series devices, you'd 
have to start that part of the conversation about 200 steps back in the 
process at: how did this device get past QA? :(



On Wed, Dec 14, 2011 at 1:45 PM, Jeff Wheelerj...@inconcepts.biz  wrote:


Dear List, and Juniper lurkers!

The EX4200s we have been purchasing lately are coming with Junos


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

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

[Chris Morrow]

On 12/09/2011 12:58 PM, Keegan Holley wrote:
 Can you post the filter and a sh int extensive?  You might have the burst
 rate too small.  What kind of load are you generation?  Do you see the ff
 counters incrementing?

firewall filters cause extra lookups... so it's reasonable that even a:
  filter foo {
term boo {
   then accept
}
  }

will cause problems... Depending on what you match, and where in the
filter, and lots of other bits (packet sizes, packet rates, etc - which
are more of a problem than packet sizes!) of course there are problems :(

Also, for most cases the PFE is the shared resource that matters, so if
your PFE is very busy doing something else, less resources are available
for packet forwarding/acl-processing.

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

Re: [j-nsp] Summarize Global Table

[Chris Morrow]

On 10/26/2011 12:10 AM, Shane Amante wrote:
 With respect to S-VA, it appears you would need to play games with
 carrying either a default route or less specifics (aggregates) with
 NO_EXPORT, etc. around your network and having the potential to
 accidentally leak them beyond your network.  However, what's more
 concerning is clearly some prefixes (more specifics) are going to be
 responsible for carrying *a lot* of traffic, (think: popular CDN's,
 portals, etc.), which you want to ensure are optimally routed.  The

in any case that you remove some of 'all the data' the routing table,
more stretch for some prefixes is introduced, right? So this isn't
particularly unexpected.

 problem is, AFAICT, S-VA makes you identify _and_ maintain those
 'popular prefixes' on your own to ensure that you optimally route
 them.  In theory, one might use Netflow to periodically determine and

sure, same for all instances of the 'remove some routing data' solutions.

 adjust the list of popular prefixes, but what happens when you
 experience a sudden influx of traffic?  How fast are you going to be
 able to react?

the real trick, as you highlight, is to figure out a method to identify
and maintain and TE (properly) prefixes which are hot at some point in time.

One argument is that sloshing some traffic on less optimal paths which
are not overloaded isn't really bad, it may even be less costly to
upgrade the links than to run around upgrading fib/rib/cpus on aging
hardware, right?

-chris

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

Re: [j-nsp] Summarize Global Table

[Chris Morrow]

On 10/26/2011 02:07 AM, Robert Raszuk wrote:
 Chris,
 
 Have you read draft-ietf-grow-simple-va-04 ? There is nothing in the
 draft nor in the implementation reg route to the left.

it's a joke, essentially: Remove lots of granularity, make someone else
in the network more capable of handling the granularity decide where to
route things ('someone else' is hopefully inside your routing-domain,
since you won't want to hand traffic off to an external party to just
re-accept it on the same port :) )

 As described to Shane semantically this is identical in default
 behaviour as installing all prefixes into RIB and FIB. However I would
 argue that if you do it within the POP you can do much better savings
 that the default behavior. But this is perhaps out of scope of this
 thread ;-)

right, all of the 'remove granularity' solutions can be modeled all the
way from: Drop all the /24's to Drop everything except the
manufactured 0/0... Depending on the spin you want to induce you talk
about one side of the pendulum swing or the other.

As I've said in the grow-wg sessions several times (and at nanog and
other places) VA, and other solutions like it, may be fine in some
deployments, they may even save you some cycle time on RP/RE/linecards,
each operator that uses these solutions needs to decide for themselves
what level of loss in granularity is acceptable and on which platforms
in their network they will still need to carry full routes in rib + fib.

-chris

 
 Cheers,
 R.
 
 
 On 10/25/2011 10:09 PM, Mark Tinka wrote:
 On Wednesday, October 26, 2011 05:12:09 AM Richard A
 Steenbergen wrote:

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

 I've been chatting with a major vendor about their interest
 in implementing S-VA:

 http://tools.ietf.org/html/draft-ietf-grow-simple-va-04

 'route to the left' ... you can do this today, VA only wraps a
 'protocol' and (maybe) 'operational modality' around 'route to the left'.

 There may be hope yet.

 sure, 'route to the left' (tm: schil...@uu.net)
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Summarize Global Table

[Chris Morrow]

On 10/26/2011 03:06 AM, Robert Raszuk wrote:
 Hi Pavel,
 
 Robert, is there any non-production implementation of simple-va, which we
 could play with?
 
 The only implementation I am aware of is cisco ios component code. Yes
 there are non-production EFT images you could perhaps get from cisco to
 play around with it.
 
 Since I have switched recently and I am not longer a vendor, but an
 operator you will need to ask your cisco colleagues to get you some test
 images.

supposedly hwuawei has some code for their platforms you could use, if
you happen to swing that way, of course.

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

Re: [j-nsp] Summarize Global Table

[Chris Morrow]

On 10/26/2011 09:56 AM, Pavel Lunin wrote:
 
 The removal of a large aggregate (say 4/8) and the subsequent required
 addition of all of the subnets under 4/8 could certainly be
 'interesting' to observe.
 Interesting as well is that 4/8's origin doesn't have to be the flapper,
 just your network (or an intermediate) changing attributes (or exit
 path!) could be enough to induce this problem, no?
 Right! This's why it's not bad to play with it around and see whether
 this simple idea really works as expected in real-life.
 
 On one hand 4/8 withdrawal or change should not be worse than installing
 some part of the full table. Very-very roughly, /8 is about 1/200 of the
 full table, which is ~2000 prefixes by now (can be checked but I'm too

keep in mind that the +/- of 2k prefixes is IN ADDITION to all the other
work going on in the routing table... so how many (and how often) +/- 2k
hits can you take?

 lazy). Not so few but looks acceptable in case a /8 flaps. On the other
 hand, I personally wouldn't try to predict, how often this can happen
 with longer aggregate prefixes for the full table overall, and whether
 it's acceptable. If someone thinks it's obvious — I'd like to hear the
 explanation.

the data (some of it at least) is available in MRT dumps from
ris/routeviews, right? so some modeling of this could be done
quickly/easily.

Now, the fun part... in your internal aggregates, if those change,
what's the impact? or do you have to keep all customer prefixes in your
local table all the time? (and in va-terms not mark them for suppression).

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

Re: [j-nsp] Summarize Global Table

[Chris Morrow]

On 10/26/2011 10:24 AM, Mark Tinka wrote:
 On Wednesday, October 26, 2011 09:26:11 PM Chris Morrow 
 wrote:
 
 As I've said in the grow-wg sessions several times (and
 at nanog and other places) VA, and other solutions like
 it, may be fine in some deployments, they may even save
 you some cycle time on RP/RE/linecards, each operator
 that uses these solutions needs to decide for themselves
 what level of loss in granularity is acceptable and on
 which platforms in their network they will still need to
 carry full routes in rib + fib.
 
 For networks that may be feeling pressure in the core (and 
 if the core is especially large that the problem is 
 magnified), this really is where MPLS can have real 
 application, as opposed to just being a buzz word for folk 
 that think it's cool.

this is a LOT of overhead though, where 'how about we just supress these
/24s k?' could work 'as well'.

 If removing BGP from your core will save you tons of $$ in 
 core router upgrades, then MPLS is certainly worth 
 considering. Of course, this assumes the network is 

again, overhead/tradeoffs... it's not a 'bad thing' just something to
keep in mind, it's not as blithe as 'sure, turn on that em-pee-ell-ess'
as I've heard many times :)

 currently already running MPLS, or does not find deploying 
 to be rocket science. If neither of those pre-conditions is 
 the case, then it's not such a hot idea, of course.
 
 Also, it assumes your edge (particularly the Aggregation 
 nodes) can still handle a full table, which may also not be 
 the case for some networks.

yup... good thing people removed those 7500's from the edge! and
12008's! (and m40's)... oh, wait :(
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Summarize Global Table

[Chris Morrow]

On 10/25/2011 10:09 PM, Mark Tinka wrote:
 On Wednesday, October 26, 2011 05:12:09 AM Richard A 
 Steenbergen wrote:
 
 c) Vendors would much rather sell you new cards wih more
 FIB capacity than find a way to implement a free
 solution in software (big shocker, I know). :)
  
 I've been chatting with a major vendor about their interest 
 in implementing S-VA:
 
 http://tools.ietf.org/html/draft-ietf-grow-simple-va-04

'route to the left' ... you can do this today, VA only wraps a
'protocol' and (maybe) 'operational modality' around 'route to the left'.

 There may be hope yet.

sure, 'route to the left' (tm: schil...@uu.net)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Firewall filter for system service ssh on outside interface?

[Chris Morrow]

On 10/13/2011 09:40 AM, Daniel M Daloia Jr wrote:
 Hi Folks,
 
 Is there any reason why I shouldn't allow ssh access to a remote SRX
 with a firewall filter only allowing a single network on an untrust
 (reth) interface? Maybe should create a loopback instead, allow
 system-services ssh,  and apply the filter there? My thought for
 using a lo interface is why force all traffic through the filter just
 for a system service?

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

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

[Chris Morrow]

On 10/13/2011 04:23 PM, David Ball wrote:
 On 13 October 2011 13:53, Paul WALL pauldotw...@gmail.com wrote:
 You'll never be able to get a full table on your current cards, they're
 defective, and will never be able to perform as advertised. The only
 solution is to buy all new (and more expensive) cards, or stop carrying
 full tables.
 
   I can't help but wonder if perhaps Juniper just expects us to
 buyI dunnoroutersto do routing.  I'm not trying to justify

this is a flavor of the 'its only a TOR switch' discussion, but...

http://www.juniper.net/us/en/local/pdf/datasheets/1000261-en.pdf

talks about mpls capabilities, as well as bgp, ipv6, isis so, it
kind of fits the bill for a larger network device with routing
capabilities, eh?

 their alleged embellishment of its v4/v6 route capacities,
 but.right tool for the job and all that

marketing aside

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

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

[Chris Morrow]

On 10/13/2011 05:51 PM, David Ball wrote:
 On 13 October 2011 14:41, Chris Morrow morr...@ops-netman.net wrote:

   I can't help but wonder if perhaps Juniper just expects us to
 buyI dunnoroutersto do routing.  I'm not trying to justify

 this is a flavor of the 'its only a TOR switch' discussion, but...
 
   Should it not be ?

eh, just pointing out where the conversation was headed (and has been
before)

 http://www.juniper.net/us/en/local/pdf/datasheets/1000261-en.pdf
 talks about mpls capabilities,
 
...roadmapped, though I haven't a clue how old that PDF is..perhaps
 it supports MPLS now.  NSR was also listed as roadmapped, which I
 would consider a requirement of a dual-RE device which will be
 performing a significant amount of routing.

sure... point being they put it on brochures.

 as well as bgp, ipv6, isis
 
   ...all 3 of which require Advanced Feature Licenses (just to
 'enable' a feature which is absolutely required).  Same PDF indicates

supposedly at least v6 is 'not encumbered by a license'... don't know
about isis/bgp though. They probably are since enterprises think bgp is
'hard' and thus are ok with paying extra for something they perceive
they don't need.

 * Shared route table—actual capacity depends on prefix distribution
 when referring to IPv4 unicast routes.  I'm not doubting that it was a
 bad implementation as Paul described, but they do make mention of it.

sure, in a funny and useless-for-capacity-planning manner.

 so, it
 kind of fits the bill for a larger network device with routing
 capabilities, eh?
 
   Clearly YMMVlet's ask the OP.  Or, ask your Juniper RE at the
 Goog if they would recommend it for such a purpose.  I haven't tried
 to push full tables to enough switches to know how many of them are
 good at it, so please forgive both my ignorance and smugness (yeah,
 that's a word).

smugness is fine, my point here is it's marketed at more than it (far
more) can accomplish, that's going to engender some anger from folks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] out of band management - real OOB

[Chris Morrow]

On 09/19/11 16:59, Jonathan Lassoff wrote:

 BTW, can anyone give a good real-world example of a_routed_  OOB management
 network usage?

 As far as I understand the whole concept of OOB MGT IP interface was
 invented to make the management network totally isolated from any transit
 traffic. For security concerns, at the days when firewalls were not trusty
 enough, when lack of Internet connection was not that big issue. If you
 really need to implement this, you won't run into any routing conflict,
 since it's a really separated network, will you?



how about like management networks on ss7 deployments?

It's really not that hard to conceive of a 'management card' on a 
network device that can twiddle all of the network device's parts and 
maintains a separate routing world from the production side of the hardware.


Hell, you could even envision something like this in the world of 
servers: ilom (sun), drac (dell), hp-whatever-the-hell...


-chris

in 2011, we CAN have more than routing table on a single device, yes?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] good filter to protect RE

[Chris Morrow]

On 08/08/11 21:38, OBrien, Will wrote:
 Hey guys, I need to spend some time putting together a good filter to
 protect my REs. Does anyone have a canned one I can start from?

cymru.com ... search for their juniper secure template (also search this
mailing-list for the same topic)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 10.0 or 10.4?

[Chris Morrow]

On 03/15/11 13:57, Steve Feldman wrote:
 On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote:
 
 ...
 We recently spent a fair bit of time trying to decide between 10.3R3 and
 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the
 conclusion that 10.4R2 was significantly buggier.
 
 What sorts of bugs did you see in 10.4R2?
 
 JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in
 10.1R4) where some of our firewall filter rules were being silently
 ignored.

ex + firewall ... 'silently ignored' is the norm no? ;(

here's a fav of mine. Loopback filters drop traceroute THROUGH the
device (unless you permit all traceroute of course) because, you know..
separating the 'control plane' traffic from the 'data plane' traffic is
something we all figured out 10 years ago. :(

(to be fair, this 'bug' is fixed in 11.X... 'please load this daily code
image on your production network, kthxbi!')

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

Re: [j-nsp] Qfabric

[Chris Morrow]

On 02/24/11 12:24, Chris Evans wrote:
 Yeah and that's great.  As 90% of the installs are still gige copper where
 is that offering? :)
 On Feb 24, 2011 12:17 PM, Doug Hanks dha...@juniper.net wrote:
 A lot of our customers require low latency: financial, higher education,
 HPC environments and utility.

 Juniper has taken the time to solve more than just the low latency
 problem. We're trying to solve larger problems such as how do you manage an
 entire campus or data center as one logical device; that's able to scale;
 and delivers performance and low latency.

coughit's 2011, where's my v6 firewall on the loopback?/cough
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anycast

[Chris Morrow]

On 01/18/11 14:58, Frank Sweetser wrote:
 On 1/18/2011 1:45 PM, Johan Borch wrote:
 Hi,

 This is not a specific Juniper question, but there seems to be a lot for
 knowledge on this list so I will give it a shoot :)

 Would web traffic be suitable to use with anycasting? The applications in
 question is a standard website with database backend that I need to load
 balance (active-active) between multiple sites. I've never worked with
 anycast before but as I understand it the anycast-part is merely me
 announcing the server addresses from multiple sites in my IGP?
 
 Short answer: no, it's not suitable.

on the other hand...
with enough stability in your IGP and predictability in your ingress
paths/traffic ... I've seen this be perfectly workable for a very large
scale IP network.

 In the long run, you'll be much happier just getting a product designed
 to handle your needs, like an F5 or A10 load balancer.

I agree with this though, anycast brings along some interesting
troubleshooting scenarios. If you don't already have a handle on them,
don't make things more complicated for yourself.

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

Re: [j-nsp] Anycast

[Chris Morrow]

On 01/18/11 16:25, Johan Borch wrote:
 Thanks for all replies.
 
 My IGP is not very large and changes are small.Load balancers are expensive
 and the commercial products don't really fit in the budget. The idea is that
 the sites should be active-active and take over for each other if one of
 them fail, but this sound like a challenging task :)

you could just do bind views (with a view of your view of the internet
split as you think makes sense) to get the same effect as a GSLB, that's
all akamai's dns solution is anyways... and use different localpref'd
routes at each location to prefer a master at that site... dropping
bgp announcements at a site if the service is offline there.

-chris
(yes, akamai's dns is more complicated, but at the end of the day ipX
gets answerY ...)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chris Morrow]

On 12/17/10 14:03, Jack Damn wrote:

 Anyone wants to join me here and urge Juniper to do something about
 this ? Please reply and express your discontent, they are monitoring
 this list.

I wish you hearty good tidings in your endeavor... I don't see movement
from Juniper on this front, at all.

 It seems to me they are not taking this matter very seriously. Time
 flies and nothing changes.

The EX, for some reason, is never required to meet the same
functionality testing and results as the other Juniper routing platforms
are... It's quite sad that Juniper put this product out ignoring ~10
years of industry best practices/standards/experience/knowledge.

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

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

[Chris Morrow]

On 12/17/10 15:09, Richard A Steenbergen wrote:
 On Fri, Dec 17, 2010 at 02:37:03PM -0500, Chris Morrow wrote:

 It seems to me they are not taking this matter very seriously. Time
 flies and nothing changes.
 
 FWIW I've already done an epic amount of bitching about this issue, and 
 they ARE aware and working on improving it. Its always nice to have more 
 voices though, so they don't think it's just that ras guy whining about 
 something nobody cares about. :)

yea, same here with the PLM and such :( so far... look we still can't
rate-limit to the box, w00t! :( fail.

 The EX, for some reason, is never required to meet the same
 functionality testing and results as the other Juniper routing platforms
 are... It's quite sad that Juniper put this product out ignoring ~10
 years of industry best practices/standards/experience/knowledge.
 
 Insert standard disclaimer about it's an enterprise class box, where 
 enterprise is codeword for doesn't actually have to work right because 
 enterprise people are stupid and don't know any better, and you can 
 always pay a lot more money and buy an MX if thats a problem here. :)

yea, so... from:
http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf

AFL includes licenses for IS-IS, BGP, MPLS and IPv6 routing
 
Extend Virtual Private LANs  with MPLS
 

You put ISIS and MPLS in a 'this is a Top-of-Rack switch' ... and the
messaging gets a tad 'confusing'. Is this a TOR or is this a small MPLS
capable device to deploy in the field termination of FTTH-type deployments?

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

Re: [j-nsp] EX4200 filter buggy?

[Chris Morrow]

(ex-platform causes death/dismemberment/pain/anguish)

On 12/15/10 09:18, Charlie Allom wrote:
 On Sun, Dec 12, 2010 at 09:49:02PM -0600, Richard A Steenbergen 
 r...@e-gerbil.net wrote:
 On Mon, Dec 13, 2010 at 10:51:26AM +0800, Gavin Tweedie wrote:


 I also have a case open with JTAC.

 For 
 example, if you configured a single term to match on 0.0.0.0/8, 
 1.0.0.0/8, or 3.0.0.0/8, the firewall compiler would try to optimize 
 that match into 0.0.0.0/6  !2.0.0.0/8. The problem is the NOT match 
 wasn't supported on the EX, so it would ignore that operation and match 
 the 2.0.0.0/8 packets anyways, even though you didn't configure that 
 range in your filter.
 
 Richard how did you come to this realisation? Was this a JTAC case or do
 you have a way to look at the filter optimization?

juniper doesn't normally release this sort of data, you can run some
command to dump the optimized code out though... it's kinda ugly :(

 I think I have seen similar outcomes, but don't know how to match it up
 with proof.

try this fun experiment:
  1) apply loopback filter, permit ssh/bgp/ospf (things you include
normally in your loopback filter)
  2) if you permit 'icmp' or 'traceroute' to the device (use the device
interface ips in the from clause, potentially with a prefix-list built
from an apply-path expression
  3) traceroute to something behind/beyond the device

note that the device doesn't show up in the traceroute? ;( packet
processing/firewalling fail.

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

Re: [j-nsp] BGP Blackhole communities

[Chris Morrow]

On 10/20/10 10:45, David Ball wrote:
   There use to be a great page up at www.secsup.org that provided examples
 of exactly this, but I can't seem to load the page anymore.

former co-worker shutdown the server i think :( boo.

I have a rough copy:

http://docs.as701.net/tmp/CustomerBlackhole.txt

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

Re: [j-nsp] BGP Blackhole communities

[Chris Morrow]

On 10/20/10 15:24, Richard A Steenbergen wrote:
 On Wed, Oct 20, 2010 at 05:03:19PM +0200, Jonas Frey (Probe Networks) wrote:
 Hi,

 its easy:

 - you need multihop on internal bgp sessions
 
 On external BGP sessions you mean. The issue is that by default JUNOS 
 doesn't let you arbitrarily rewrite next-hops on regular EBGP learned 
 routes, which is how you would implement network wide BGP blackholing 
 (rewriting the nexthop to a value that is routed to discard on every 
 router). There are three main ways you can work around this:
 
 1) Configure multihop on all of your customer EBGP sessions, so that you 
 can rewrite next-hop when a blackhole community is matched. The biggest 
 downside here is that this breaks fast external failover (or whatever 
 term Juniper uses for the behavior), where if link state on the external 
 interfae drops, the EBGP session is immediately dropped. Without this 
 feature you may be blackholing traffic for 60 seconds or more, while you 
 wait for BGP hold-timers to expire.
 
 2) Configure accept-remote-nexthop, a recent feature specifically 
 designed to address this issue. But, be very careful with this one, as 
 there was a bug in early implementations which caused rpd to crash under 
 some conditions when an interface with a configured EBGP neighbor using 
 this feature flapped. We hit this one a few times, it was PR 500062 
 (though it seems to still be marked hidden). Supposedly fixed in 9.6S5 
 and newer.
 
 3) Use dedicated EBGP multishop sessions for customers to inject BGP 
 blackhole routes, usually to a centralized route server. This is the 
 method we use, as it still has a few major advantages.

4) reset next-hop as you ship the route internally to IBGP neighbors
(see ... the Wayne Gustavus's (verizon) talk from NANOG32 in Reston:
http://www.nanog.org/meetings/nanog32/presentations/soricelli.pdf)

there are, as RAS is pointing out, many ways to skin this cat.

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

Re: [j-nsp] BGP Blackhole communities

[Chris Morrow]

On 10/20/10 17:03, Richard A Steenbergen wrote:
 On Wed, Oct 20, 2010 at 04:23:23PM -0400, Chris Morrow wrote:

 4) reset next-hop as you ship the route internally to IBGP neighbors
 (see ... the Wayne Gustavus's (verizon) talk from NANOG32 in Reston:
 http://www.nanog.org/meetings/nanog32/presentations/soricelli.pdf)

 there are, as RAS is pointing out, many ways to skin this cat.
 
 Well, that would work if you're adding a local static route to discard 
 and then reannouncing it into IBGP... But if you're receiving the route 
 from a customre EBGP session that wouldn't install the null route on the 
 local box, potentially leaving you open to one customer flooding another 
 customer on the same router.

yup, customers can still get 'local' traffic, and yes every device has
the same dsc0 or discard route setup for the next-hop address.

 I also had some people point off offline that you could build a single 
 prefix-list policy, then allow null routes to be accepted, and THEN 
 begin your regular customer border policies. This is also true, but I 
 forgot to mention that I've also found value in having separate max 
 prefix limits for null route vs regular routes, which you couldn't 
 implement via a policy over a single session. This entire discussion 

I actually like the 'use a new session' model, it does clarify things
for everyone... though there are potentially some scaling issues with
this dimension as well.

 needs a giant disclaimer that says Warning: The number of BGP speaking 
 customers out there who aren't really masters of route-map and who will 
 accidentally try to null route their entire bgp session is higher than 
 you might expect. Making them actually take the time to configure a 

hahahaa, bell canada... yes, there are lots of people who don't grok bgp
from the customer side :( handing them a templated config (and templated
change set) is helpful.

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

Re: [j-nsp] Solarwinds Monitoring Problem

[Chris Morrow]

On 06/06/10 11:37, sth...@nethelp.no wrote:
 Is there default rate limiting of ICMP traffic in JunOS?

 monitoring systems and stuff we've developed ourselves. Mind you, we
 don't have any EX switches.

ex's have a default (unchangable) 1kpps limit toward the RE...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX 3200 - no arp entries after power failure

[Chris Morrow]

On Tue, 9 Feb 2010, Paul Waller wrote:



I'm wondering if anybody has seen this issue before.  We have a EX 3200 
running JunOS 9.2R2 release.  Everytime the switch looses power it boots 
back up OK but no ARP entries are seen.  I haven't had a chance to see 
the logs yet but I'm informed this has been happening for sometime  a 
2nd reboot of the switch fixes the problem.


Once I look at the config  get the logs then I might post some more but 
I thought I'd just post this question just in cast somebody had seen


is there a loopback filter on the device? apparently prior to 
9.5something on the ex juniper thought filtering ARP in an L3 filter was 
'acceptable'...

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

Re: [j-nsp] EX Routing Throughput

[Chris Morrow]

On Wed, 7 Oct 2009, Havard Eidnes wrote:


Now one thing I feel compelled to add, because I ran into it the other
day, is that the ex DOES have IPv6 firewall filter support, although
it seems hidden.


Yes, it's able to parse the config, but the config when applied
gets prepended with this comment block:

## Warning: configuration block ignored: unsupported platform (ex4200-24t)
##

So much for that.


which is completely sensible since ipv6 has been 'production' for... 10 
years now? weee!

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

Re: [j-nsp] EX Routing Throughput

[Chris Morrow]

On Wed, 7 Oct 2009, Richard A Steenbergen wrote:


EX has a ton of missing features which are blocked like this. Which is


yes


actually better than how it used to be, where they would commit and then
the box would crash and require a physical powercycle to recover.


wee... I guess? :(


The sad part is that IPv6 support (to say nothing of firewall support,
which is still extremely lacking on all fronts) isn't roadmapped until


check out snmp support as well, good times and spinlocked snmpd, weee! ( 
forget the order but something like snmpwalk the standard v2 accessible 
mib tree and boom snmpd spins itself into the ceiling, until 
9.5something code)



2011 on big EX. Why Juniper doesn't want this platform to have a


'big ex' means?? 8XXX? isn't the idea with the EX you get a lower end 
routing platform in the 32/4200 and can scale it up with VC's until you 
want to grab an 8200?



chance to succeed is beyond me, I guess they figure it's no fun if they
don't wait for the competition to catch up.


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

Re: [j-nsp] router protect policy

[Chris Morrow]

On Thu, 6 Aug 2009, Pekka Savola wrote:


On Wed, 5 Aug 2009, Chris Morrow wrote:
as a base-level question... why are these 'standard firewall filter' 
features NOT supported on what is a 'standard juniper' platform?


if you need/want these, open bugs. it's silly that these aren't supported.


JTAC folks will just refer you to some obscure page that mentions this (or 
should mention this but currently doesn't and suggest you file a doc PR that 
will be implemented in 9 months) and ask you to open an ER case or talk to 
your sales guy.  This isn't supported but it should be doesn't seem to fly 
well in JTAC at least based on my experience.


Sorry, I should have phrased my statement differently:
(thanks Pekka for making me re-think my statement)

I have opened bugs against this lack of feature. Juniper will likely (and 
has mostly) said: 'You are the only nut asking for this.' So, please if 
you want these features open your own PR's and complain that becoming 
Cisco isn't a smart move for Juniper. (you can of course be more 
diplomatic about it... but unless more people who spend money with 
Juniper ask for this we all are out of luck.)


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

Re: [j-nsp] router protect policy

[Chris Morrow]

On Wed, 5 Aug 2009, Sean Clarke wrote:


Hi Bill

the keyword except is what is not allowed on the EX .. maybe you need to 
write one to accept only the NMS-NETWORKS prefix list and deny the rest ... 
it should do the same job

i.e.


as a base-level question... why are these 'standard firewall filter' 
features NOT supported on what is a 'standard juniper' platform?


if you need/want these, open bugs. it's silly that these aren't supported.

-chris



  filter ROUTER-PROTECT {
  term SEQ-100-accept {
  from {
  source-prefix-list {
  NMS-NETWORKS;
  }
  destination-port [ telnet ssh ftp ftp-data snmp ntp ];
  }
  then accept;
  }
  term SEQ-100-deny {
  from {
  source-address {
  0.0.0.0/0;
  }
  destination-port [ telnet ssh ftp ftp-data snmp ntp ];
  }
  then {
  syslog;
  discard;
  }
  }
  }

cheers
Sean

Bill Blackford wrote:
I'm trying to form a router protect policy on an EX3200 that is being used 
as a layer3 border device receiving default routes only (temporary until 
it's replaced by an M series). I was able to create a policy that works 
fine for EX series running layer2 only services. Are there any examples or 
templates to look at?


Another engineer offered this:
ROUTER-PROTECT
term SEQ-100 {
 from {
 source-address {
 0.0.0.0/0;
 }
 source-prefix-list {
 NMS-NETWORKS except;
 }
 destination-port [ telnet ssh ftp ftp-data snmp ntp ];
 }
 then {
 syslog;
 discard;
 }
}
term SEQ-200 {
 from {
 source-address {
 0.0.0.0/0;
 }
 source-prefix-list {
 BGP-NEIGHBORS except;
 }
 destination-port bgp;
 }
 then {
 discard;
 }
}
term SEQ-300 {
 then accept;
}

My problem is that the EX is barfing on the source-prefix-list command. As 
such:

firewall {
family inet {
filter ROUTER-PROTECT {
term SEQ-100 {
from {
source-address {
0.0.0.0/0;
}
##
## Warning: configuration block ignored: unsupported 
platform (ex3200-24t)

##
source-prefix-list {
NMS-NETWORKS;
}
destination-port [ ssh telnet snmp ftp ftp-data ntp ];
}
then accept;
}
term SEQ-200 {
from {
##
## Warning: configuration block ignored: unsupported 
platform (ex3200-24t)

##
source-prefix-list {
BGP-OSPF-NEIGHBORS;
}
protocol ospf;
destination-port bgp;
}
then accept;
}
term SEQ-300 {
then accept;
}
}
}


So in essence, I'm looking for a policy that will achieve the same goal 
that can actually be placed on a ex series.


Thank you

-b

--
Bill Blackford Senior Network Engineer 
Technology Systems Group   Northwest Regional ESD 
my /home away from home



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



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


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

Re: [j-nsp] IPv6 best practice

[Chris Morrow]

On Mon, 25 May 2009, Jared Mauch wrote:



On May 25, 2009, at 8:32 AM, Matthias Gelbhardt wrote:


Hi!

Today we received our IPv6 prefix from RIPE. There are many projects in the 
pipeline, so we would like to enable our network with IPv6 and would like 
to start new projects with default deployment in IPv6.


What would be the best practice to bring our backbone to IPv6? Would one 
use a virtual router for this? Or is it doable to configure IPv6 in 
parallel to my other configuration?


You can configure IPv4 and IPv6 on the same wire and is the method that I 
personally recommend.  If you keep your IPv6 and IPv4 topologies identical it 
will avoid many problems.


Perhaps some of these 'many problems' are outlined somewhere that Matthais 
can review? :)


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