Re: [j-nsp] Flow-Taps on MX80-48t

[Jonathan Lassoff]

It's hardly a polished Lawful Intercept feature, but there's this:
http://juniper.cluepon.net/index.php/Remote_port-mirror

On Wed, Nov 20, 2013 at 12:04 AM, Alex D.  wrote:
> Hi guys,
> is it possible to use flow-taps for lawful interception on MX80-48t ?
> Does it require a MS-MIC-16G ?
> Thanks in advance...
> Regards,
> Alex
> ___
> 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] Junos ospf question

[Jonathan Lassoff]

Seems doable to me, so long as there are prefixes for both the storage
gear hanging off of router "A" and "B". If, for example, your storage
gear hanging off of "B" is using a default route to reach the gear off
of "A", then you can't do it.

Add a term to your applicable OSPF import policy on all three routers
that matches the next-hops of the low-speed GigE paths, and the
prefixes applicable for your storage application. Then, reject the
route.

On Wed, Sep 25, 2013 at 1:39 AM, R S  wrote:
> basically I've a triangulation A - B - C - A
>
> single area 0
>
> A-B link is 10Gbs
> A-C and B-C is 1 Gbs
>
> since in A-B run a very high volume of traffic (storage), I do not want if 
> A-B fails this traffic goes through C
>
> C redistribute as well statics into OSPF
>
> Hope it clear now
>
> Subject: Re: [j-nsp] Junos ospf question
> From: p...@westerlund.se
> Date: Wed, 25 Sep 2013 10:23:39 +0200
> CC: ipv6fre...@gmail.com; juniper-nsp@puck.nether.net
> To: dim0...@hotmail.com
>
> Can you give some more details? I'm not sure I understand all of your 
> requirements.
> Are you trying to influence something native to OSPF, or are you talking 
> about setting metrics for routes redistributed (Cisco-speak) from another 
> protocol?
> /Per
> 25 sep 2013 kl. 10:09 skrev R S :I understood the same 
> and I need to be able to drop network announcement in a very granular way...
>
> ___
> 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] Aggregate interface AE issue

[Jonathan Lassoff]

What is the media management interface of which you speak?

Do you mean a Layer 3 / IP interface on the router itself? I ask because
you mention a "management VLAN" as being part of the trunk.

It's not clear what's breaking here for you.

Cheers,
jof


On Thu, Apr 26, 2012 at 2:56 AM, Ala' Amira wrote:

> Dear Friends,
>
> ** **
>
> I have applied AE interface between 2 MXs and it is working fine  but I
> have lost the connectivity to the Media Management units only which is
> behind AE interface  although the Management Vlan already exist in the
> trunk,
>
> ** **
>
> 
>
> ** **
>
> This is the configuration on one of the routers  :
>
> set interfaces ge-2/0/0 gigether-options 802.3ad ae1
>
> set interfaces ge-2/1/3 gigether-options 802.3ad ae1
>
> set interfaces ae1 flexible-vlan-tagging
>
> set interfaces ae1 mtu 1600
>
> set interfaces ae1 encapsulation flexible-ethernet-services
>
> set interfaces ae1 unit 0 family bridge interface-mode trunk
>
> set interfaces ae1 unit 0 family bridge vlan-id-list 11
>
> set protocols vstp vlan 11 interface ae1
>
> ** **
>
> ** **
>
> what I have missed here to access the management units?
>
> ** **
>
> ___
> 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] SRX3600 weirdness

[Jonathan Lassoff]

On Tue, Apr 23, 2013 at 1:56 PM, James S. Smith wrote:

>
> Just in the process of finishing a project of migrating  subnets behind an
> SRX3600, and we've run into some odd behavior.
>
> We have a database subnet outside the firewall, and an exchange server
> subnet behind the firewall.  A database server uses IMAP4 over SSL (TCP
> 993) to send emails to Exchange.  The connection open and closes pretty
> regularly, every 5-15 minutes or so, and closes after the communication is
> done.  But every few days the communication get's stuck.  From the SRX
> point of view, the database server just isn't initiating a connection.
>  They have to restart the application to get the email flowing again.
>
> Now for the weirdness...  We just recently moved the database behind the
> SRX, into a separate zone.  After doing that I was told the application
> never had a problem.  It functioned like that for 2 weeks and everyone was
> happy.
>
> Unfortunately, due to some unrelated performance issues on some other
> traffic flows, we had to move the database outside the firewall again. Now
> the database is having connection issues to the Exchange server again.
>
> The firewall policies between the database server and the Exchange server
> were identical regardless of where the database server was located.  There
> is no natting going on, and we don't use screen or IPS on the SRX.  Any
> thoughts what could be the cause of this?
>

If, as you describe above, that restarting the "application" causes it to
get un-stuck, then I would think that it has nothing to do with the SRX'es
filtering.

Might it be possible to jump on the database host and try and use telnet or
netcat to manually make that connection and see what happens?

Cheers,
jof

> ___
> 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] M10i

[Jonathan Lassoff]

I think you'll need at least an M20 for your 10 GigE requirement as well as
SDH.

If you can somehow get a different transit circuit than your SDH one, an
MX5 would be a much closer (throughput-wise) and better bang-for-your-buck
replacement for a 7206 than an M-series.
J-series with a T1 module could also work, depending on your "STM-1".

If you need SDH though, you'll need M or T. J can do T1s.

--j

On Tue, Apr 9, 2013 at 6:28 PM, Orlando Cordova Gonzales <
orlando.cordova.gonza...@gmail.com> wrote:

> hello,
>
> I need to change a CISCO 7206 router that computer I recommend one of the
> requirements is that you have two 10G interfacez two interfacez 1G and STM1
> interface to connect with the ISP was thinking M10i Router but I do not
> support 10g interface.
>
> thank you very much for your help.
> ___
> 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] 3750 and 4200

[Jonathan Lassoff]

On Wed, Mar 13, 2013 at 6:36 PM, Eric Krichbaum  wrote:
> More likely, it's the forced "on" mode which disables LACP.  Try it with
> mode active.

Will JunOS show the ae as down, then?

[channel-group N mode on] with IOS just enables portchanneling unconditionally.
Wouldn't that, in conjunction with a JunOS without an "lacp" stanza
under the ifd / interface stanza (lacp passive) work just fine? I've
mostly only been doing JunOS-JunOS LACP lately, though I've done it
quite a bit with Cisco-Cisco in the past.

LACP is worth running on your links if it works, IMO.

Maybe try setting active on the JunOS and Cisco sides?

!
interface Fa1/0/9
 channel-group 10 mode active
!

set interface ae1 aggregated-ether-options lacp active
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 3750 and 4200

[Jonathan Lassoff]

It's strange that one end shows the interface as up, but the other does not.

Is it possible that you're using SFPs that only do 1000base-T?

What if you take the individual ports out of the ae / etherchannel and
just go point-to-point, does the link show as up then?

Maybe try cabling up to the management port (a known 100base-T port)
or a laptop and see if the link shows up? At least that way, you could
rule out the Cisco being wrong about the link status.

--j

On Wed, Mar 13, 2013 at 3:40 PM, snort bsd  wrote:
> hi all:
>
> i have a cisco 3750 fastethernet switch connecting to a juniper 4200, with 
> portchannel on cisco side and aggregated interface juniper side. the cisco 
> side shows as "connected" but juniper side remain down. could anyone give me 
> some ideas? no lacp activated on both side.
>
> for cisco:
>
> cisco-3750#sh int fast1/0/9
> FastEthernet1/0/9 is up, line protocol is up (connected)
>   Hardware is Fast Ethernet, address is 0018.b99f.5d8b (bia 0018.b99f.5d8b)
>   MTU 1500 bytes, BW 10 Kbit, DLY 100 usec,
>  reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>
> cisco-3750#sh interfaces por10
> Port-channel10 is up, line protocol is up (connected)
>   Hardware is EtherChannel, address is 0018.b99f.5d8c (bia 0018.b99f.5d8c)
>   MTU 1500 bytes, BW 20 Kbit, DLY 100 usec,
>  reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Full-duplex, 100Mb/s, link type is auto, media type is unknown
>   input flow-control is off, output flow-control is unsupported
>   Members in this channel: Fa1/0/9 Fa1/0/10
>
>
> interface Port-channel10
>  switchport access vlan 100
>  switchport mode access
>
> interface FastEthernet1/0/9
>  switchport access vlan 100
>  switchport mode access
>  switchport nonegotiate
>  channel-group 10 mode on
>
>
> for juniper:
>
> user@4200-1# run show interfaces terse ge-0/0/9
> Interface   Admin Link ProtoLocal Remote
> ge-0/0/9updown
> ge-0/0/9.0  updown aenet--> ae1.0
>
> user@4200-1# run show interfaces ae1 terse
> Interface   Admin Link ProtoLocal Remote
> ae1 updown
> ae1.0   updown eth-switch
>
>
> user@4200-1# show interfaces ge-0/0/9
> ether-options {
> no-auto-negotiation;
> link-mode full-duplex;
> speed {
> 100m;
> }
> 802.3ad ae1;
> }
>
> user@4200-1# show interfaces ae1
>
> ae1 {
> aggregated-ether-options {
> minimum-links 1;
> link-speed 100m;
> }
> unit 0 {
> family ethernet-switching {
> port-mode access;
> }
> }
> }
>
>
> _dave
> ___
> 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] switch idea.?

[Jonathan Lassoff]

If you want to stick with Juniper, maybe check out the EX4500.

If you're looking for inexpensive, maybe check out the Arista 7100s or
Accton's offerings.


On Thu, Dec 6, 2012 at 1:48 AM, hasan alperen selçuk  wrote:

> Hi all,
> We will change our Back Bone switch and i need some advice.
> our topology
> http://b1212.hizliresim.com/14/6/gml93.png
> we need min. 4x10g fiber and min 1x1g fiber port (should be 12x1g sfp)
> any idea?
> thanks
>
> H.Alperen SELÇUK
>
>
> GSM : +90 (544) 880
> 98 80
>
>
>
>
>
>
>
>
>
>
> ___
> 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] DHCP interface as next hop

[Jonathan Lassoff]

On Wed, Nov 28, 2012 at 4:45 PM, Aaron Dewell wrote:

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


Not sure about your routing setup and how you tag routes, but what about
running DHCP on the modem and letting default point out that path?

Then, setup your far end to only announce an "internal" table (whatever
routes are appropriate for your application) via your T1/BGP path.
Exclude the IPSec tunnel endpoint space.

Setup your IPSec tunnel and run a routing protocol over it, de-preferencing
those routes below that of the T1/BGP path routes.

That way, under normal operation you'll take the L3VPN path, but should
those routes become unreachable, you'll prefer the IPSec-learned routes.

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

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

[Jonathan Lassoff]

The other that that comes to mind for me is security policy.

Is it possible that there could be security policy in place that
blocks flows in the topology that is formed when your SRX is root?

Cheers,
jof

On Mon, Nov 19, 2012 at 9:55 PM, Jeff Wheeler  wrote:
> On Mon, Nov 19, 2012 at 6:04 PM, Ali Sumsam
>  wrote:
>> If I try to set the priority on one of the SRX110 to become root bridge,
>> MSTP seems to be converged but there are huge packet losses in the network.
>> I removed the priority and one of the cisco2970 became root and then
>> everything seems to be fine. No packet loss after that.
>
> Just taking a wild guess here, but does the SRX110 have enough
> forwarding performance, and enough port speed, to switch all of the
> traffic between your 2970s?  Check the CPU usage and link headroom
> when the SRX is root.  Unless you manipulate your port costs, the
> configuration you suggested would have traffic going
> 2970#1---SRX110---2970#2.
>
> --
> Jeff S Wheeler 
> Sr Network Operator  /  Innovative Network Concepts
> ___
> 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] STP Between Cisco and Juniper

[Jonathan Lassoff]

On Fri, Nov 9, 2012 at 9:57 PM, Saba Sumsam  wrote:
> Hi,
> I have a Layer 2 network consisting of a Cisco 2970G, SRX210 and SRX100.
> Following are the STP modes supported on each:
>
> Cisco 2970G: mst, pvst, rapid-pvst
> Juniper SRX100: STP, RSTP. MSTP
> Juniper SRX210: STP, RSTP
>
> My question is: Is Cisco mst interoperable with Juniper RSTP. What mode
> should I be using on each device in this case?
>
> Suggestions highly appreciated.

The best solution will really depend on your environment.
What is the topology like?

I would avoid MST/MSTP unless you have a good reason to use it. A
Cisco running MSTP should interoperate with non-MSTP-speaking devices,
as external to MSTP-speaking boxes, each "region" looks like like a
big spanning-tree bridge.

If your environment is simple and doesn't have any unusual
requirements, I would go for rapid-pvst/rstp on each device.

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

Re: [j-nsp] SRX: rate-limiting source NAT sources

[Jonathan Lassoff]

Alex, Hans -- thanks for the pointers.

I was aware of the UTM features, but I'm targeting SRX 3600s and 5600s.

The pointer to the [security screen ids-options] feature looks
promising. Thanks for the tip -- I'll get this labbed out and see what
happens!

Cheers,
jof

On Tue, Oct 30, 2012 at 9:15 AM, Hans Kristian Eiken
 wrote:
> You could limit the number of sessions each ip address in your internal zone
> can initiate. Here is an example on limiting an ip address in the zone trust
> to only be able to create 1 session.
>
> set security screen ids-option session-limit limit-session source-ip-based
> 1
> set security zones security-zone trust screen session-limit
>
> There should be no license needed for this feature.Here is how to configure
> this:
>
> http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/denial-of-service-firewall-source-based-session-limit-setting-cli.html
>
> --
> Hans Kristian Eiken
>
> 2012/10/29 Jonathan Lassoff 
>>
>> So, I'm working on tuning an SRX deployment and am wondering if
>> something is possible.
>>
>> This deployment is doing a lot of source NAT for a wide variety of
>> endpoints as they egress out to the Internet. Pretty vanilla
>> configuration.
>> Specific sources are mapped via NAT rules to specific egress IPs (for
>> IP filtering in some places, outside of the SRXes in question).
>>
>> And once in a while, some endpoint will have a legitimate need to open
>> up *many* connections (and then NAT states) that pass over this SRX
>> deployment.
>> Unfortunately, the rate of connection establishment relative to the
>> application timeouts means that these heavy users can use up all of
>> the ephemeral ports, blocking new flows from becoming established.
>>
>> We've been playing a bit of whack-a-mole, assigning more IP space to
>> the various source NAT pools, but would like to find a more proper
>> solution.
>>
>>
>> So, my question is this: is there any mechanism anyone knows of to
>> rate-limit or block-past-a-threshold a "source NAT" source if it
>> starts making too many connections?
>> I don't see anything obvious in the SRX documentation, so I figured
>> I'd ask here for pointers.
>>
>> Right now, it's way to easy for one bad actor (malicious or
>> benevolent) to max out a source NAT pool.
>>
>> Cheers,
>> jof
>> ___
>> 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] VPLS design - dual homed

[Jonathan Lassoff]

On Mon, Oct 29, 2012 at 8:03 PM, Luca Salvatore  wrote:
> Right.  So BGP needs to be full meshed also for this to work right?

Yes -- assuming you're using BGP for signaling.

Since BGP is used to signal where the PE/edge ports are, once it comes
time to use that to establish LSPs, the routers just need to be able
to reach one another.
The same thing can be scaled out with route reflectors, if one needs.

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

[j-nsp] SRX: rate-limiting source NAT sources

[Jonathan Lassoff]

So, I'm working on tuning an SRX deployment and am wondering if
something is possible.

This deployment is doing a lot of source NAT for a wide variety of
endpoints as they egress out to the Internet. Pretty vanilla
configuration.
Specific sources are mapped via NAT rules to specific egress IPs (for
IP filtering in some places, outside of the SRXes in question).

And once in a while, some endpoint will have a legitimate need to open
up *many* connections (and then NAT states) that pass over this SRX
deployment.
Unfortunately, the rate of connection establishment relative to the
application timeouts means that these heavy users can use up all of
the ephemeral ports, blocking new flows from becoming established.

We've been playing a bit of whack-a-mole, assigning more IP space to
the various source NAT pools, but would like to find a more proper
solution.


So, my question is this: is there any mechanism anyone knows of to
rate-limit or block-past-a-threshold a "source NAT" source if it
starts making too many connections?
I don't see anything obvious in the SRX documentation, so I figured
I'd ask here for pointers.

Right now, it's way to easy for one bad actor (malicious or
benevolent) to max out a source NAT pool.

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

Re: [j-nsp] L4-L7 and SSL offload switch

[Jonathan Lassoff]

On Wed, Oct 24, 2012 at 9:33 AM, Frank Sweetser  wrote:
>
> I don't believe that Juniper has anything in that product space, but we've
> been very happy with a set of A10 load balancers we recently rolled out.  They
> have all the features we needed, and for way less money than F5.

Agreed over here as well. I don't think Juniper makes load balancers.

I've had a pretty good experience with A10 boxes for enterprise
environments, and HAproxy on Linux for tight budgets and teams of
hackers.

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

Re: [j-nsp] Juniper MX5 vs Brocade CER

[Jonathan Lassoff]

On Mon, Oct 22, 2012 at 10:49 AM, Saku Ytti  wrote:

> On (2012-10-22 17:18 +), Doug Hanks wrote:
>
> > These numbers will change with every hardware release and software
> > release. I used a generic number with the MX book.
> >
> > The idea is that as soon as the book hits the shelf, the testing numbers
> > would have been obsolete anyway (it took Harry and I about 14 months to
> > write).
>
> Fair rationale, and I can see there is target audience for it to whom it's
> very useful book.
>
> The book is listed at 28.07GBP in AMZN. For every MX hardware generation
> I'm happy to shelve out 10x that and consider the price steal, if it
> contains detailed architecture, day in packets life explained, full
> explanation how to troubleshoot lookups in in 'show jnh ...' level and so
> forth.
> I'd like to think there is sufficient market for this, but I realize I'm
> highly biased.
>

No, I too would really like more internal information like that. I would be
more than happy to pay for it, even.

Being able to understand a routing platform in depth is really important
for conceptualizing how the various features are implemented and how to
debug the box in the lab and the occasional field deployment issue.

Unfortunately, Juniper seems to publish very little about their internals.
Most of the good stuff I find out is either purely anecdotal or comes from
extensive "fiddling" with the FPC or PIC CLIs and binaries to get a feel
for what's going on under the hood.

Cisco seems to only be marginally better at this, though most of the good
stuff I've picked up by talking with TAC folks that are willing to share,
rather than any documents being published.

Cheers,
jof

>
> --
>   ++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] Krt queue issues

[Jonathan Lassoff]

It's sadly a known issue for which there is no easy fix.

When turning up new adjacencies, I generally hack in policy to avoid
announcing any routes at first until the box has had a while to learn and
pick up the tables, only then do I start announcing space and sinking
traffic through the router.

However, this does little help after an unexpected reboot.

--j

On Mon, Oct 1, 2012 at 5:26 AM, Darren O'Connor wrote:

> Hi Saku.
>
> Indeed, this is the worst thing this router can do. I have redundant
> routers sitting there doing absolutely nothing as this router's
> control-plane says everything is fine.
>
> Juniper aren't really telling me anything, only that the links I've shows
> are 'corner cases' - no comment on the comment I got from JTAC.
>
> I do happen to have a spare Brocade XMR that I might just use instead.
>
> Juniper should just come out straight.
>
> > Date: Mon, 1 Oct 2012 15:15:39 +0300
> > From: s...@ytti.fi
> > To: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] Krt queue issues
> >
> > On (2012-10-01 08:38 +0100), Darren O'Connor wrote:
> >
> > Hi Darren,
> >
> > > So to me this means this problem is a software issue, not hardware.
> And it's not yet fixed. Hence spending the money on a new box would be of
> no use.
> >
> > Certainly not hardware issue, cisco boxes running significantly lower
> > performance RPs wont do this (well at this scale). Like crappy old
> > sup720-3bxl.
> >
> > IMHO this is absolutely worst thing router can do, not have RIB and FIB
> in
> > sync, since then all your investments in redundant network was lost. You
> > have working backup paths, but they cannot be used due to your router
> > sucking traffic it cannot handle yet.
> > If they can't fix the FIB programming, they should also stop accepting
> > routes from routing protocols, even if BGP convergence takes 30min, it's
> > much more preferable to FIB/RIB desync.
> >
> > > This particular router for me will be connected to a peering point so
> will have around 200 neighbours, as well as a transit link with a full BGP
> table.
> >
> > JunOS is exceedingly poorly performing platform in control-plane,
> > especially with PPC control-plane. 200 neighbours on MX80 does not sound
> > like a good idea right now. You probably should have gone with bigger MX
> > where you'd get XEON.
> >
> > MX80 has faster CPU than RSP720, but RSP720 runs circles around MX80 :/
> > --
> >   ++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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Strange ARP issue on M7i

[Jonathan Lassoff]

On Wed, Aug 15, 2012 at 12:13 AM, Saku Ytti  wrote:
> On (2012-08-14 13:09 -0700), Jonathan Lassoff wrote:
>
>> Moral of the story, as I see it: avoid static routing.
>
> This is bit circular. Vendor had software defect in ARP and you arrived to
> conclusion consequently we should not use static routing, but dynamic.
> However our choice of configuration does not affect quality of the code as
> implemented by vendor, so just as well we might have BGP defect doing
> something nasty, and someone might draw conclusion 'avoid bgp routing'.
>
> Moral of the story is, avoid broken software, which is easier said than
> done.

You make a very good point here.

My thing was more along the lines that routing (RIB) / next-hop path
information ought to be learned and/or monitored over protocols that
ride that same path, so that any path failures are detected and routed
around.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Strange ARP issue on M7i

[Jonathan Lassoff]

On Tue, Aug 14, 2012 at 1:20 PM, Tobias Heister  wrote:
> Hi,
>
> Am 14.08.2012 22:09, schrieb Jonathan Lassoff:
>> A dynamic routing protocol and BFD would be see this right away and
>> move traffic, but this would break any static routes that rely on any
>> dynamism with ARP and next-hops.
>>
>> Moral of the story, as I see it: avoid static routing.
>
> At least in our case it was a bgp route with a third-party next-hop (server) 
> living on a connected LAN segment.
> So we could not be saved by BFD in this case, but i admit its a special setup.

I'm confused, because you said that "The next-hop ip was gone for
several weeks".

In this case, wouldn't BGP detect the neighbor as down and remove the
route from the RIB?

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

Re: [j-nsp] Strange ARP issue on M7i

[Jonathan Lassoff]

On Tue, Aug 14, 2012 at 1:00 PM, Tobias Heister  wrote:
> Hi
>
> Am 14.08.2012 15:12, schrieb Markus:
>> Isn't that weird? Where did that arp entry come from and why was it saved on 
>> the Juniper for so long, and only got removed after I removed the static 
>> routing of that /24?
>
> We saw a similar thing a short time ago on an MX480 running 10.4R9
> In our case it was a bgp route pointing to a no longer existing ip address as 
> the next-hop. The arp entry for this ip address stayed active as long as 
> there was an active route for it.
> Even clearing the arp cache witch clear arp hostname x.x.x.x did not do the 
> trick. The next-hop ip was gone for several weeks and the arp entry had low 
> timeout values left but never expired.
> After clearing the route the arp entry vanished as expected.
>
> I guess something keeps the arp entry from being deleted as long as there are 
> or were forwarding entries in the fib for it at any time.

Probably because the underlying information ARP is learning is used to
build the next-hop in the forwarding table (which needs to know what
Ethernet address to put in the destination MAC).

However, I would think that the route should become unreachable or
pruned if ARP is failing.
What if the remote router died for some reason? If the ARP entry and
next-hop were kept into place, the path would not work, but the route
would stay active.
A dynamic routing protocol and BFD would be see this right away and
move traffic, but this would break any static routes that rely on any
dynamism with ARP and next-hops.

Moral of the story, as I see it: avoid static routing.

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

Re: [j-nsp] encrypted-password /* SECRET-DATA */;

[Jonathan Lassoff]

On Sun, Aug 5, 2012 at 6:51 PM, ibariouen khalid  wrote:
> Hi
>
> I'm running version 11.1R4.4 on an M10i ;
>
> i tried to load the configuration file from the M10i to an MX240 ( junos
> 12.x ) and i got an error  regarding the following items :
>
> user core {
> uid ;
> class Admin;
> authentication {
> encrypted-password /* SECRET-DATA */; ## SECRET-DATA
> }
> }

Some external program scrubbed the password from the configuration
file. This looks a lot like what RANCID does to Juniper configs.

This exact configuration as-pasted would indeed throw an error, as the
place where a normal passwd-style hash would be is the string "/*
SECRET-DATA */".

Just replace that with a hash like you pasted below
("$1$sbvf432k$qYoeoRs9/t2kywPztwxl01") and it should work.

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

Re: [j-nsp] FW configuations which are required during failover of one db to other !!

[Jonathan Lassoff]

On Sun, Jul 22, 2012 at 8:06 AM, Harri Makela  wrote:
> Hi All
>
> Application Server connecting successfully to DataBase Server01 (db01). This 
> DB01 now need to mirror to db02 and port 5022 will be used.
>
> Requirement : Application Servers which currently access DB01 should be able 
> to access DB02 when failover to DB02 will happen.
>  From FW perspective, I am not sure how I`ll add the failover on FW ? As per 
> my understanding, I just have to add the FW policies as per flow i.e. SRC --> 
> DST  --> Port and rest will be done from SQL end.

This depends on how you're doing failover. Two ways that I can think of:

If it's purely application-layer, and your clients will fail over to
connecting to db02 somehow, just be sure and have policy that allows
connections to db02's IP.
- Failover and test this out.

If it's a VIP, High Availability IP, or some other mechanism that
moves connections to the IP from one host to the other, do nothing.
Your firewall should allow new connections to form normally. However,
you may still see some sessions that are established but for which
there is no matching connection on the host. These may time out or
attempt closure after a while.

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

Re: [j-nsp] Troubleshooting output queue drops

[Jonathan Lassoff]

On Thu, May 24, 2012 at 8:01 AM, Per Granath  wrote:
> Well, this gentleman: http://mccltd.net/blog/?p=1199 has looked at that, so:
>
>   monitor traffic interface ge-1/0/0 no-resolve matching "(ip and (ip[1] & 
> 0xfc) >> 2 == 20)"
>
> would give you DSCP with AF22.

But wont this only work for kernel-bound or -sourced traffic?

Are there Juniper platforms for which one can capture transit traffic as well?

--j

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

Re: [j-nsp] Route redistribution

[Jonathan Lassoff]

On Tue, May 22, 2012 at 12:46 PM, Cyn D.  wrote:
> Thanks for the input. Given our network topology, I am trying to avoid
> running a full IBGP mesh.

If router C just needs internet transit, perhaps consider just
injecting a default route into your IGP?

It sounds like in this example, that most of the external next-hops
are via A anyway. Perhaps it would be simpler for internal routers to
just use a default, and catch any more-specifics for anything that
doesn't go out A.

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

Re: [j-nsp] Route redistribution

[Jonathan Lassoff]

On Tue, May 22, 2012 at 12:24 PM, Cyn D.  wrote:
> Network connections:
>
> We have router A(M120, 10.4), B(MX240, 11.4) and C(M7i, 10.4) connected as a 
> triangle. Router A and B are in OSPF area 0 and also run IBGP between them. 
> Router C is connected to A and B via OSPF area 5.
>
> Problem:
>
> Router A has a lot of EBGP learned routes. These routes are redistributed to 
> router B using IBGP and OSPF. My intension is to redistribute these routes to 
> Router C with OSPF from BOTH A and B. Therefore if A-C link fail, Router C 
> will learn all routes from B. The problem is now Router C only learned these 
> routes from A but can not learn from router B.  Did I miss anything or is it 
> Router B not working properly?

Assuming that B and C are both in the same AS and speaking iBGP, B
wont re-announce the NLRIs back into itself without being set as a
route reflector.

However, I'd recommend making a full-mesh of BGP sessions over
OSPF-learned loopback addresses. Whether that's hauled over MPLS or
some other L2 transport mechanism, or using routing and multi-hop BGP
is up to you.

That way, C will still learn the routes coming into A, even if the
path is via B to get to the next-hops.

Cheers,
jof

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

Re: [j-nsp] Help Needed for Bonjour Routing/OSX Clients

[Jonathan Lassoff]

On Thu, May 10, 2012 at 5:02 PM, Joel jaeggli  wrote:

> On 5/10/12 16:21 , Phil Mayers wrote:
> > On 10/05/12 17:12, Jonathan Lassoff wrote:
> >> On Thu, May 10, 2012 at 2:54 AM, Phil Mayers  >> <mailto:p.may...@imperial.ac.uk>> wrote:
> >>
> >> On 09/05/12 22:55, Jonathan Lassoff wrote:
> >>
> >> I've gotten this to work in the past, but it ended up being a
> >> LOT more work
> >> than just using DNS names and routing (which I've subsequently
> >> done each
> >> time).
> >>
> >>
> >> Out of curiosity, how did this work? Isn't most mDNS traffic TTL=1?
> >>
> >>
> >> I don't know about all the various implementations out there (of if the
> >> standard says anything), but my modern-ish OSX box does 255:
> >
> > Ok. Though I note that they're both link-local multicast groups, so
> > again I wonder how people did them cross-subnet.
>
> wide area bonjour is done like this:
>
> http://www.dns-sd.org/ServerSetup.html


On the surface, this looks like a much cleaner way of doing things,
provided the client support is there.

Thanks for the tip, Joel!

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

Re: [j-nsp] Help Needed for Bonjour Routing/OSX Clients

[Jonathan Lassoff]

On Thu, May 10, 2012 at 9:21 AM, Phil Mayers wrote:

> On 10/05/12 17:12, Jonathan Lassoff wrote:
>
>> On Thu, May 10, 2012 at 2:54 AM, Phil Mayers > <mailto:p.may...@imperial.ac.**uk >> wrote:
>>
>>    On 09/05/12 22:55, Jonathan Lassoff wrote:
>>
>>I've gotten this to work in the past, but it ended up being a
>>LOT more work
>>than just using DNS names and routing (which I've subsequently
>>done each
>>time).
>>
>>
>>Out of curiosity, how did this work? Isn't most mDNS traffic TTL=1?
>>
>>
>> I don't know about all the various implementations out there (of if the
>> standard says anything), but my modern-ish OSX box does 255:
>>
>
> Ok. Though I note that they're both link-local multicast groups, so again
> I wonder how people did them cross-subnet.
>

Oh, I'm not sure if v6 link-local groups can/should be routed. I see no
reason that a device could be configured to allow joins from multiple
links/LANs and forward frames accordingly. ff02::fb is in the link-local
scope however.

Interestingly, ff05::fb is a site-local scoped address that's been set
aside, but I don't know or haven't run across any clients that use this.
It's documented in
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15

In the past, I did this with the v4 traffic.

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

Re: [j-nsp] Help Needed for Bonjour Routing/OSX Clients

[Jonathan Lassoff]

On Thu, May 10, 2012 at 2:54 AM, Phil Mayers wrote:

> On 09/05/12 22:55, Jonathan Lassoff wrote:
>
>  I've gotten this to work in the past, but it ended up being a LOT more
>> work
>> than just using DNS names and routing (which I've subsequently done each
>> time).
>>
>
> Out of curiosity, how did this work? Isn't most mDNS traffic TTL=1?


I don't know about all the various implementations out there (of if the
standard says anything), but my modern-ish OSX box does 255:

v6:
Internet Protocol Version 6, Src: fe80:::xxff::
(fe80:::xxff::), Dst: ff02::fb (ff02::fb)
0110  = Version: 6
[0110  = This field makes the filter "ip.version == 6"
possible: 6]
        = Traffic class: 0x
  00..      = Differentiated
Services Field: Default (0x)
  ..0.      = ECN-Capable Transport
(ECT): Not set
  ...0      = ECN-CE: Not set
        = Flowlabel: 0x
Payload length: 35
Next header: UDP (0x11)
Hop limit: 255
Source: fe80:::xxff:: (fe80:::xxff::)
[Source SA MAC: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)]
Destination: ff02::fb (ff02::fb)
User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353)
Source port: 5353 (5353)
Destination port: 5353 (5353)
Length: 35
Checksum: 0x4aa1 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Domain Name System (query)
..

and the v4 case:
Ethernet II, Src: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx), Dst:
01:00:5e:00:00:fb (01:00:5e:00:00:fb)
Destination: 01:00:5e:00:00:fb (01:00:5e:00:00:fb)
Address: 01:00:5e:00:00:fb (01:00:5e:00:00:fb)
 ...1     = IG bit: Group address
(multicast/broadcast)
 ..0.     = LG bit: Globally unique address
(factory default)
Source: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
 ...0     = IG bit: Individual address
(unicast)
 ..0.     = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol Version 4, Src: nn.nn.nn.nn (nn.nn.nn.nn), Dst:
224.0.0.251 (224.0.0.251)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
 00.. = Differentiated Services Codepoint: Default (0x00)
 ..00 = Explicit Congestion Notification: Not-ECT (Not
ECN-Capable Transport) (0x00)
Total Length: 55
Identification: 0xd6ca (54986)
Flags: 0x00
0...  = Reserved bit: Not set
.0..  = Don't fragment: Not set
..0.  = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: UDP (17)
Header checksum: 0x82ad [correct]
[Good: True]
[Bad: False]
Source: nn.nn.nn.nn (nn.nn.nn.nn)
Destination: 224.0.0.251 (224.0.0.251)
User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353)
Source port: 5353 (5353)
Destination port: 5353 (5353)
Length: 35
Checksum: 0x2886 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Domain Name System (query)


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

Re: [j-nsp] Help Needed for Bonjour Routing/OSX Clients

[Jonathan Lassoff]

To get Bonjour to work across LANs, you would need to enable multicast
routing so that clients on the various LANs can join the same group.

Bonjour is just Apple's name for mDNS (multicast DNS).

Provided that everyone can solicit queries and hear announcements, hosts
should be able to resolve the addresses of the other stations and will then
attempt to route to it.

I've gotten this to work in the past, but it ended up being a LOT more work
than just using DNS names and routing (which I've subsequently done each
time).


Bonjour / mDNS is really only great at service discovery and small-scale
name resolution, IMO. DNS and distributing names at scale; not so much.

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

Re: [j-nsp] /kernel: %KERN-6: MTU for ff02::0005 reduced to 1500

[Jonathan Lassoff]

On Tue, May 8, 2012 at 10:58 AM, Alex D.  wrote:
> Hi list,
>
> i manually set IPv6 mtu to 1500 on M- an MX-Series routers running JunOS
> 10.4R8.5
> After configuration, following message appears in syslog:
> /kernel: %KERN-6: MTU for ff02::0005 reduced to 1500
>
> Is it a problem or why does the router inform about the change ?
> Whith manually set IPv4 MTU, there are no such messages in the logfile.

I would presume this is just a new codepath, and some logging was
added into the kernel.

To me, logging MTU changes on interfaces seems prudent and useful.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] About Juniper MX10 router performance

[Jonathan Lassoff]

On Sun, Apr 22, 2012 at 10:24 PM, Md. Jahangir Hossain
 wrote:
> Dear valued member:
>
>
> Wishes all are fine.
>
>
> i need
> suggestion from you about Juniper MX10 router performance who already 
> implement this. i want to
> buy  this router for IP Transit provider where i received  all global
> routes .
>
>
> it would be nice please put your valued suggestion about this issue .

Jahangir -- we spoke briefly about this on NANOG just now as well.

Do you have a specific question about the MX10? What is it that you're
trying to accomplish?

--j

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

Re: [j-nsp] DOM: SNMP polling of RX power for 1 GE SFP impossible?

[Jonathan Lassoff]

On Thu, Apr 12, 2012 at 2:28 AM, Saku Ytti  wrote:
> On (2012-04-12 11:12 +0200), Emmanuel Halbwachs wrote:
>
>>     Juniper fellows subscribed to this list, please bring us useful,
>>     complete and sane SNMP MIBs. We badly need it! Thank you very
>>     much.
>
> And maybe basic trap support, like ISIS up/down, BGP max-prefix, BGP trap
> which reports previous state (so you don't need to keep track of states).

Nor poll too often.

Since 10.x, I get the sense that Juniper has been chasing so many
other bugs that good SNMP support has slipped somewhat.
It's probably a lot of extra work, especially for things that mutate state.
I can imagine it involving managing MIB contents and naming, finding
every place in which a hook or function needs to be defined to support
representing things into SNMP-compatible types.

What if I do a write to shut an interface? Should a whole commit happen?


It's too bad that netconf and op scripts are so hard to use (and
utilize relatively-obscure XML-based languages). They hold the full
power to read and manipulate states of just about everything in JunOS.
However, I think this can sometimes be too big of a hammer.

When you just want to pull out some counter data, routing protocol
states, route next-hops, etc., who wants to have to haul out XML and
XML-centric editing tools? The netconf Perl library seems like a step
in the right direction, but seems like just a thinly veiled
higher-layer API to build XML documents.

I'll cherish the day when I can just curl
http://r00ter/protocols/bgp/neighbors.json?key=d756d378f8e7bf506bf1c7d3aac2f8d480c84776

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

Re: [j-nsp] SSH_Brute_Force events

[Jonathan Lassoff]

On Thu, Apr 5, 2012 at 3:09 PM, Harri Makela  wrote:
> Hi Guys
>
> We are getting "SSH_Brute_Force" alerts quite often from our Intrusion 
> prevention systems (IPS) - ISS GX.
>
> Issue Description: We have detected SSH_Brute_Force events sourcing from 
> external IP x.x.x.x targeting multiple internal IPs. This is probably an 
> attempt to gain access to SSH enabled servers.
>
> What could be best practices to handle these alerts ? i.e.
>
> change SSH port  system wide from 22 to 10022 ?
> Report the ISP to contact with the customer which is really not a practical 
> solution ?
>
> Any advice will be highly appreciated. I myself new to this and trying to 
> document the process.

This is a very common occurrence on the open internet. Usually, these
remote hosts test out some common account names and passwords, looking
for weakly-protected accounts.

The first thing I would do to mitigate this risk in my network would
be to setup firewall filters (in the case of JunOS) on my loopback and
management interfaces so that only internal management stations (that
also cannot be reached from the open internet!) can reach the SSH
daemons on my router.

Switching SSH ports to a non-standard port will stop the casual
scanner, but doesn't really do anything to mitigate the risk.

--j

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

Re: [j-nsp] Best way to detect abnormal traffic without enabling security?

[Jonathan Lassoff]

On Tue, Apr 3, 2012 at 12:20 AM, Yucong Sun (叶雨飞)  wrote:
> But jflow is not going to work in packet mode, right?

Netflow-like reporting is probably the right way to detect these types
of anomalies in a scalable manner. However, I can't speak to the
performance of it on J-series. I'm guessing that since the state is
probably handled in-memory and with a CPU on that platform (J-series),
that exporting flows will just become another DOS vector.

If you're looking to try and narrow down where the bulk of your
traffic is going in a more stateless manner, consider looking at
"monitor interface traffic" and looking for abnormally high numbers,
or setup a firewall filter that counts term hits. Then, monitor the
counters for the filter and see which terms are getting hit the most.


Alternatively, tap all of your traffic (if it's a J-series, I can't
imagine it's more than 1 - 2 Gbps) and analyze it on another PC. If
you have some upstream or downstream managed switches, this could be
possible.
Using tshark on the command like, I would run something like "tshark
-ni eth0 -z ip_hosts,tree" to get a breakdown from a live capture as
to which IPs are talking the most.

Cheers,
jof

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

Re: [j-nsp] Mounting MX80 at an angle

[Jonathan Lassoff]

On Thu, Feb 16, 2012 at 9:18 AM, Serge Vautour  wrote:
> Hello,
>
> Has anyone ever rack mounted an MX80 or a similar sized router at an angle 
> before? Any reason why this isn't a good idea? Could it have an impact on the 
> electrical components?
>
> We've run into alot of COs where we could save money by installing them at an 
> angle. Existing racks aren't big enough and we've had to buy complete new 
> racks which drives up the costs. Our guys have found angled brackets that 
> would work.

I can't say for sure, though I bet it would be ok.
However, this may qualify as one of the more hilarious mountings
imaginable. Take some photos of the end result, if you can share. :P

Some hardware configurations run hotter than others. Maxing out on 10
GigE ports will make more heat than the 48-port GigE fixed
configuration, for example.

One thing I might intuit would be to mount the hot exhaust pointing
up, so you're not fighting the hot air wanting to rise against the
cool (though the fans are pushing enough air, I bet it doesn't matter
that much).
Though in all the configurations I've seen, there's been mostly
side-to-side airflow, so it may not matter here.

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

Re: [j-nsp] proxy arp C vs J

[Jonathan Lassoff]

On Tue, Feb 7, 2012 at 2:23 AM, Alex Arseniev  wrote:
> Did you check what MACs are used in 1st, 2nd and 3rd time? Specifically MAC
> OUIs.
> I suspect this is a side effect of having C-J in the same broadcast domain.
> Basically, when J-interface ARPs for a connected host, _AND_ if C has a
> specific route to that host/32, the C will answer with own MAC.

And potentially, depending on the configuration, the Cisco may try and
proxy based on a route learned from the Juniper, creating a loop.

The question I would ask: what is proxy arp used for? why?

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

Re: [j-nsp] Juniper SA SSL VPN static ip for user

[Jonathan Lassoff]

On Sat, Feb 4, 2012 at 6:42 PM, Barny Sanchez  wrote:
> the suggestion from Jof is clever but it doesn't scale. I am afraid that you 
> would require of an external device to help you accomplish this, such as 
> using a Radius and Attribute Value Pairs (AVP) to send back to the SA the 
> associated IP for an user (framed-ip-address) upon connection.

That seems much cleaner.

Maintaining many groups or address pools per-user is a lot more work
to setup with the web UI. By manipulating the XML configuration, it's
possible to automate this. Still, it seems like a hack.

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

Re: [j-nsp] Juniper SA SSL VPN static ip for user

[Jonathan Lassoff]

On Sat, Feb 4, 2012 at 3:46 PM, Maciej Jan Broniarz  wrote:
> I have a bunch of users using SSL VPN to Juniper SA box. Is there a way to 
> "give" each user the same static ip that will
> always be given to that user, whenever he logs in?

Unfortunately, I don't know of a simple way of doing this. However, I
would think that it should be possible to create address pools with
just one IP in them (they're not CIDR, just ranges), user groups with
just one user in them, and map each user to their own set of user
group and address pool.

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

Re: [j-nsp] Hash algorithms for LAG

[Jonathan Lassoff]

On Thu, Jan 19, 2012 at 8:08 AM, Thomas Eichhorn  wrote:
> Dear all,
>
> I just had some discussions with our SE about the
> hashing algorithms used in different devices for
> packet distribution on LAG.
>
> This seems to be a horrible complexe topic, with
> much sensible information behind - the exact algorithm
> seems to be much of a secret.
>
> I just wonder why, maybe my idea ist just a little
> bit naive, but I hope somebody here can bring some clarification
> into it:
>
> If I were to implement such a distribution algorithm,
> I would just define a range of bits of the headers,
> and do a modulo (number of member links) with it.
>
> The range of bits could say: Only from Byte 9 to 20 for
> using the mac-adresses, or a longer part of the header
> if including MPLS-labels.
>
> Am I completely wrong and there is much more magic
> behind? Has somebody here an deep insight and might
> share it with us?

That's usually what I've seen.

Devices construct a bitfield from one or more headers that can be
picked out in hardware quickly, then apply your hash, modulo the
number of "links" and map that to a next-hop.

However, there's some differences in picking the "links" part (does it
include configured next-hops that might be unreachable), the fields
(mac, mpls, {src,dst} ip, {src,dst} L4 port, etc.), and whether or not
there's a way to reverse the hash->next hop mapping.

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

Re: [j-nsp] Whitebox 10Gb/s capture challenge

[Jonathan Lassoff]

On Thu, Jan 12, 2012 at 10:20 AM, Drew Weaver  wrote:
> Everyone pointed out really good notes here as well but as far as I know and 
> this may have changed recently but if you do the 10Gbps / smallest possible 
> packet size you'll crush the CPU before it ever gets anywhere near the disks.

I believe that this observation will depend heavily on the software in
use to communicate with your NIC. Certainly if your card is generating
interrupts per-packet, your system would be crushed under the load of
constantly switching contexts. However, with drivers that support
multiple ring buffers for reception (and especially those that are
thread-safe and can split the load across CPU cores), it's possible to
scale out a single "system" to handle even very high PPS loads.

Where this falls down in practice though is that some of the other
features in the kernel do not split their load across cores as cleanly
(netfilter/iptables included).

Still... if you have the means, using a capturing appliance can really
help ease this pain and frees you to worry about other portions of
your application.

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

Re: [j-nsp] End host mapping tool

[Jonathan Lassoff]

On Sun, Nov 27, 2011 at 6:15 PM, Dale Shaw wrote:

> Hi all,
>
> Is anyone aware of open source or COTS software that provides MAC
> address to switch port to IP address (and vice versa) mapping and
> discovery? aka end user / end station tracking.
>
> There are lots of them out there ('netdisco' being a popular open
> source choice) but I haven't stumbled across one yet that properly
> understands Juniper (JUNOS) bridging MIB(s) supported on EX-series
> such that the MAC/L2 to IP/L3 resolution works properly.
>
> I've personally tried the cacti 'MacTrack' plugin, as well as the
> relevant module within Statseeker -- neither work as intended. In the
> latter case, there is a product enhancement request logged but I'm
> looking for something in the short term.
>
> What are you using in your environment to do this?
>

Hrm... I've had good personal luck with NetDisco and MacTrack.
Another great system I've been enjoying recently is Observium (
http://www.observium.org/wiki/Main_Page ). It blows Cacti out of the water,
IMO.

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

Re: [j-nsp] Pulse Client Mobile Devices with SRX ?

[Jonathan Lassoff]

On Tue, Sep 27, 2011 at 6:20 AM, Chris Gapske  wrote:
> Sorry Very new at this but I would like to ask for help on an issue.
>
> I am getting conflicting stories on the ability of the SRX.  TAC says they 
> cannot get Mobile  Devices such as Android or Idevices to connect with the 
> pulse client.
> However I have heard reports of people getting there Android devices to work 
> can anybody confirm this ?
>
> Thank you .. I am pretty new at the SRX thank you.

Apparently it is possible to do on some SRX platforms. I've only had
success in terminating mobile clients against the "Secure Access"
(SA-series) devices running IVE/SSL VPN software.

I found this KB article on doing it. It utilizes the "Dynamic VPN"
feature. http://kb.juniper.net/InfoCenter/index?page=content&id=KB17641

Beware the Android client though -- as of several months ago, it only
provided a wrapped web browser, rather than real IP tunneling. The iOS
Pulse client does proper tunneling though.

Good luck.

Cheers,
jof

___
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

[Jonathan Lassoff]

On Mon, Sep 19, 2011 at 2:04 PM, Chris Morrow wrote:

>
>
> 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...
>

This is the exact right way to go about this.

in 2011, we CAN have more than routing table on a single device, yes?


Certainly. Though plenty of older hardware did not do this for many years.

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

[Jonathan Lassoff]

On Mon, Sep 19, 2011 at 2:16 PM, Pavel Lunin  wrote:

>
>
>> I see two ways one can go about this. Either programmatically tunnel into
>> an OOB L2 segment via a "bastion" host in an on-demand fashion, or point
>> some routes (dynamically, or otherwise) into your internal network for
>> management use.
>>
>> The risk of pointing routes into your internal network, IMO, is that
>> very-specific ACLs for management access can begin to have a blurred
>> distinction. RFC-1918 space can overlap, and public IPs within an internal
>> network can sometimes overlap with an active transit path.
>>
>>
> Why not just use a normal port/vlan, plug it where you would've plug fxp0
> to, and than put it to a vrf/whatever?
>

On the internal side? This is one way about going about it. The question is,
what would the routing table on the device-to-be-managed look like? Just one
directly-connected route for the network segment it touches?

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

[Jonathan Lassoff]

On Mon, Sep 19, 2011 at 1:42 PM, Pavel Lunin  wrote:

> 2011/9/17 Chris Evans 
>
> > Juniper devices have out of band ethernet ports, but have the HUGE HUGE
> > downfall of being in the main routing table conflicting with every other
> > route.
> >
>
>
> 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?
>
> But. Nowadays not really many folks run separate PCs for OOB MGT totally
> apart of their LAN, corporate environment, email, Internet, etc. Even
> though
> some conservators may still desire this sort of design, most NMS need an
> Internet connection to update something. In this case — yes, you bump into
> a
> routing conflict using fxp0, but why to use fxp0 in such a scenario?
>
> An only exception I know of (looks like a real design flaw by Juniper) is
> the SRX cluster case, where you MUST use fxp0 interfaces, if you want to
> have access to particular members of a cluster. Otherwise you can only
> access a virtual devise as a whole, with no clue which particular node you
> connect to. Not so big problem in real world, to be honest, but if you are
> required to connect it to, say, NSM, which goes to the Internet through
> this
> same SRX cluster, you got a real pain in the rear (workarounds exist, of
> course).
>
> Sure, there are some good applications of fxp0 in field, but this does not
> much relate to real routing issues.
>

I see two ways one can go about this. Either programmatically tunnel into an
OOB L2 segment via a "bastion" host in an on-demand fashion, or point some
routes (dynamically, or otherwise) into your internal network for management
use.

The risk of pointing routes into your internal network, IMO, is that
very-specific ACLs for management access can begin to have a blurred
distinction. RFC-1918 space can overlap, and public IPs within an internal
network can sometimes overlap with an active transit path.

It's more work to script things to work nicely, but I believe the dynamic
tunneling method is the safer thing to do.
In the spirit of Junipers clean separation of the data and forwarding
planes, it seems too bad that they end up using the kernel routing table to
hold what goes in the forwarding hardware as well.

If you have the blessing of being able to have an all-J network, or one with
devices that all support multiple routing tables and routing protocol
separation (a la logical systems, or routing instance) -- setting up
separate routing tables for management vs. traffic-carrying is probably a
good thing.

--j

> ___
> 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] out of band management - real OOB

[Jonathan Lassoff]

I agree with all of these points, and it's a pretty classic problem with
managing devices that route.

The path I've gone down in most setups I've done is to simplify.

I place all devices within a site within an "out of band" LAN/broadcast
domain, and setup one (or two, depending on HA requirements) management
host(s) on that LAN with a connection to a DSL or analog modem.
Then, I only use the management port with other directly-connected hosts and
avoid the routing problem all-together.

In the cases where constant connections need to be made (SNMP polling,
configuration auditing, etc.), I've setup NAT or port forwarding rules in
iptables or pf on the management host.

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

Re: [j-nsp] acceptable/good laser receive power in case of different interfaces

[Jonathan Lassoff]

On Sun, Aug 7, 2011 at 2:03 PM, Martin T  wrote:
> Lane,
> while browsing the specifications of the optical modules listed in
> this "Optical Interface Support—EX 3200 and EX 4200 Switches.pdf"
> file:
>
> http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/optical-interface-support-ex-series.pdf
>
> ..all the modules have minimum and maximum launch power which differ
> from each other quite a lot. What does this mean? Shouldn't the launch
> power be consistent? In addition, what is a "Maximum Receiver
> Sensitivity"?

They're different underlying hardware. Most likely, Juniper is OEMing
transceivers from big manufacturers like Finisar and sticking their
stickers on them.

The different transmit powers are simply because they're different
hardware and standards.

I would guess that "Maximum Receiver Sensitivity" is just the max
recommended optical power that can be stuck into it. However, the
numbers listed in there seem pretty low for that, IMO. "Minimum
Receiver Sensitivity" makes sense, but the maximum possible power is
usually pretty high.

> In addition, there isn't some sort of connection between Rx power and
> Tx power, is there? I mean for example in case the received signal is
> low, the transmit signal of the SFP/XFP is increased automatically? As
> far as I know and as Lane confirmed, the Tx signal should be always
> consistent..

Not really. Each link between two transceivers is usually made up of a
duplex of fibers (two strands), so each TX / RX pair on either end is
its own optical system. One side transmits, and the other receives.
The other fiber strand does the same thing, but in the opposite
direction.

There's not usually a connection between RX and TX power, in my
experience, though I've heard of some GMPLS systems that will signal
the RX power to the transmitting device so that it can alter its
transmit power to compensate for over/underpowering the far end.

--j

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

Re: [j-nsp] acceptable/good laser receive power in case of different interfaces

[Jonathan Lassoff]

On Tue, Aug 2, 2011 at 2:26 PM, Martin T  wrote:
> What is the acceptable Rx power in case of SFP/XFP? For example, here
> are XFP Tx and Rx signals from six FXP's:
>
> 1:
> Laser output power                        :  1.2920 mW / 1.11 dBm
> Laser rx power                            :  0.0285 mW / -15.45 dBm
>
> 2:
> Laser output power                        :  0.6420 mW / -1.92 dBm
> Laser rx power                            :  0.3054 mW / -5.15 dBm
>
> 3:
> Laser output power                        :  0.4230 mW / -3.74 dBm
> Laser rx power                            :  0.5092 mW / -2.93 dBm
>
> 4:
> Laser output power                        :  0.4180 mW / -3.79 dBm
> Laser rx power                            :  0.4208 mW / -3.76 dBm
>
> 5:
> Laser output power                        :  1.0920 mW / 0.38 dBm
> Laser rx power                            :  0.1801 mW / -7.44 dBm
>
> 6:
> Laser output power                        :  0.7680 mW / -1.15 dBm
> Laser rx power                            :  0.3337 mW / -4.77 dBm
>
>
> Is there some sort of pattern? It looks like if the Rx signal is
> lower, the Tx is higher?

Yes, usually. Unless you have a perfect conductor or transmission
medium between the transmitter and receiver, there is bound to be some
loss.
TX is the optical power going out of the device, RX is coming into it.

> And what can one consider a decent Rx laser
> power level?

Personally, I would start to get concerned around -13bdm to -15dbm.
The actual thresholds will depend heavily on the sensitivity of the receiver.

Depending on your platform, there's probably some good information
when you run "show interfaces diagnostics optics"

Cheers,
jof

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

Re: [j-nsp] srx with ethernet switching and chassis clustering

[Jonathan Lassoff]

On Mon, Aug 1, 2011 at 12:04 AM, Richard Zheng  wrote:
> Thanks jof. I see, in production we can make other switches handle the
> access and only use srx for firewall. So after setting up reth interface, we
> should be able to add vlan-tagging to it, right?

I believe so, but honestly I do this with multiple independent SRXes
rather than reth interfaces. I would presume vlan-tagging will work
with reth interfaces, but I'm not 100% sure.

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

Re: [j-nsp] srx with ethernet switching and chassis clustering

[Jonathan Lassoff]

On Sun, Jul 31, 2011 at 7:28 PM, Richard Zheng  wrote:
> Hi,
>
> We have a configuration with multiple VR to support multiple customers. Vlan
> is used to trunk traffic into and out of SRX. While trying to do chassis
> clustering, it seems vlan is not supported. How do you do chassis cluster
> with multiple customers? Do you have dedicated interfaces for each customer?

If it's truly just a trunk and used to carry traffic to another switch
for access, there is another way to configure a trunk that doesn't
require "ethernet-switching".

Configure an interface like:

interfaces {
ge-0/0/0 {
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
address 10.0.0.1/24;
}
}
}

Now, your IP interface could be ge-0/0/0.10 instead of vlan.10.

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

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

[Jonathan Lassoff]

Jeff, Michael -- these are both totally reasonable cases I didn't even
consider. The Juniper clue wiki article is a really good example as to
why.

I wonder why it's not implemented. It does seem relatively easy
considering the fact that there is already some support for regular
expressions anyway.
I guess a large-enough customer hasn't made an ultimatum for Juniper yet. :p

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

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

[Jonathan Lassoff]

On Wed, Jul 13, 2011 at 11:02 PM, Michael Hallgren  wrote:
> Le mercredi 13 juillet 2011 à 18:25 +0200, Daniel Verlouw a écrit :
>> see
>> 
>>
>> Not supported. I requested an ER back then, don't think it ever got
>> implemented...
>
> Thanks Daniel, I'll do the same then... Must be considered pretty basic
> from a regexp point of view, I think. Right? :)

>From a user and standardization perspective, they seem pretty simple,
but are actually difficult to implement very efficiently since the
time it takes to do the search is non-deterministic.

Here's a nice accessible write-up about DFA vs NFA regex engines that
touches on this: http://swtch.com/~rsc/regexp/regexp1.html

Honestly, what's the use case of a backreference for an AS path? It
seems like BGP loop detection would never allow a path like "A X X A",
in which case if it's just used to search for repetition (as mentioned
above), why not just use the "+" and "*" operators? e.g. "^(701 )+"

Cheers,
jof

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

Re: [j-nsp] Route Precedence

[Jonathan Lassoff]

On Wed, Jul 13, 2011 at 12:31 AM, Chris  wrote:
> On 13/07/2011 3:29 PM, Ben Dale wrote:
>> Hi Chris,
>>
> Hi all,
>
> Thanks for the replies - the issue is as above, the routing table was
> topping out. I should have checked that - it completely slipped my mind.

Nice catch, Ben!
The EXes are not geared to be routers, but are fine for injecting
dynamic routes and holding a modest IGP's worth of routes. I suppose
in many environments, do you really care if a downstream switch knows
about every route on the Internet -- in most cases, probably not.

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

Re: [j-nsp] Route Precedence

[Jonathan Lassoff]

On Tue, Jul 12, 2011 at 11:35 PM, Chris  wrote:
> On 13/07/2011 2:27 PM, Chris wrote:
>> 
>>
> To add to the already long email, here is some more examples of whats
> happening:
>
> From the 10.10.10.100 device, trying to ping the 'acc-bdr1' (J6350)
> device works:
>
> traceroute to 99.99.99.242 (99.99.99.242), 30 hops max, 40 byte packets
>  1  10.10.10.254 (10.10.10.254)  0.996 ms  0.699 ms  0.66 ms
>  2  99.99.99.242 (99.99.99.242)  1.928 ms  1.589 ms  1.978 ms
>
> Yet if I try it from a device that I CANT ping from acc-bdr1 (the source
> being 10.10.10.30):
>
> [root@acc-nx4cs ~]# traceroute -n 99.99.99.242
> traceroute to 99.99.99.242 (99.99.99.242), 30 hops max, 40 byte packets
>  1  10.10.10.254  4.021 ms  3.981 ms  3.958 ms
>  2  * * *
>  3  * * *
>  4  * * *

Wow. Weird situation. In the case of the traceroute above (from
10.10.10.30 to 99.99.99.242), it only gets back ICMP messages from
your EX but not the J series. What route does the EX show for
99.99.99.242?

In the case of the static route that you added to the J series, the
route may not have been installed by default as "indirect next-hops"
are disabled by default. Since the router has no directly-connected
interface to 10.10.10.0/24, it's not sure that's what you want to do
and will just take the route it already has (the one learned via
iBGP).
You can set "routing-options forwarding-table indirect-next-hop" to
enable this functionality.

I would just trace down the path to the host that isn't working and
look at the routing and switching tables of anything along the path
and debug the path from the source to the destination, and then back
again. A route may just be missing somewhere (though this wouldn't
explain why only some IP-paths break).

Out of curiosity, is there any discernible pattern to the unreachable
IPs (every other, every four, etc.)?
All the times that I've seen the some-IPs-are-reachable-but-not-others
problem, it's been due to a link aggregation or ECMP configuration
that has a failed link or IP path along the way that isn't being
communicated (and shutdown) by higher layers.

Cheers,
jof

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

Re: [j-nsp] SRX210 IPv6 on ADSL2+ PIM

[Jonathan Lassoff]

I think there are just a lot of places in the SRX codebase that don't
support IPv6. It's sad, but true.

I too have been having problems using IPv6 on VLAN and NHTB IPSec
interfaces on SRX 210s and 240s.

It feels like Juniper took gobs of Netscreen code, crammed it into
JunOS and didn't bother to fix up existing missing features. I keep
wanting to like the SRX, and stuff just like this keeps biting me.



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

Re: [j-nsp] SRX vx IPad IOS Junos Pulse

[Jonathan Lassoff]

On Mon, Jun 27, 2011 at 6:12 PM, Ben Dale  wrote:
> Last time I looked (which was a while ago), the iPad/iPhone version of pulse 
> used SSL to establish the VPN Tunnel.
>
> The SRX only support Pulse over IPSEC (which the Windows client also 
> supports).
>
> The Secure Access (now Juniper Pulse Gateway/MAGx600) appliance supports both 
> SSL and IPSEC termination using Pulse.
>
> Confused? ; )

Indeed, I think that the iOS Pulse client only terminates on gateways
running the IVE-style SSL VPN software.

I've used both the SA-2500 and MAG2600 for terminating Pulse and
Network Connect clients (both to IVE/SSL VPN software), and both
worked just fine. As far as the software goes, it's a little bloated
(in my opinion), but it gets the job done and CPUs are fast and disk
space is cheap nowadays.

I've had some luck configuring Macintosh OS X to terminate IPSec/L2TP
on an SRX in the past, so presumably the iOS client could be coerced
into doing something similar.

>From what I hear from SEs and resellers is that the SA-2500 (maybe
other SA appliances) are being EOLed in favor of the newer MAG
appliances. They're Intel Atom boxes that can run the IVE (SSL VPN) or
UAC/NAC (802.1x, virus scanning, etc.) software set on the same
hardware.
I've found them to be a little funky in that they don't seem all that
well-suited for datacenter use. The simplest unit (MAG2600) requires
an additional tray for rack-mounting, and most seem to have one-sided
or side-to-side airflow.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASA to Junos Convertor

[Jonathan Lassoff]

On Sun, Jun 19, 2011 at 9:28 PM, MSusiva  wrote:
> Hi Altaf,
>
> Can you try IOS to JunOS translator tool?
>
> https://i2j.juniper.net/release/index.jsp

I2J is indeed a pretty awesome tool. It's probably a great tool for
Juniper SEs to pitch switching.

Unfortunately, Cisco PIXes and ASAs don't really run IOS. They may
borrow portions of code from one platform to the other, but the
configuration is totally different.

Altaf, you're best bet (in my opinion) would be to read over the JunOS
documentation for SRXes and start manually porting over your
configuration.
If you're really stuck after giving it a shot, maybe someone on this
list can help you out.

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

Re: [j-nsp] OSPFv3 interop/tuning recommendations?

[Jonathan Lassoff]

On Fri, Jun 10, 2011 at 8:51 AM, Justin M. Streiner
 wrote:
> I can do SVIs, but that starts to get away from the topology that's in
> production today.  If I need to, I can set up a span port on the 6509s to a
> machine that's running Wireshark.

A SPAN port was what I was getting at with the SVIs.

Maybe one router is faster at installing routes in the RIB than the other.

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

Re: [j-nsp] OSPFv3 interop/tuning recommendations?

[Jonathan Lassoff]

On Fri, Jun 10, 2011 at 8:07 AM, Justin M. Streiner
 wrote:
> All:
>
> I have a fairly extensive IPv6 test bed set up in my lab, using OSPFv3 as my
> IGP, and one thing I noticed is that the OSPFv3 adjacencies on links between
> Cisco (6509-Es, Sup720/3BXLs, 12.2SXH code) and Juniper (M7is, JUNOS
> 10.3R1.9) devices seem to take about 3x longer to come up, than between two
> Cisco devices.  OSPFv3 timers are at their default settings on all devices.
>  The topology is point-to-point links, and all of the relevant devices are
> in the same area.  OSPFv3 adjacencies between two Juniper devices also seem
> to come up pretty quickly.
>
> It's been a while since I've had to look at IGP interoperability between the
> vendors, so I still need to re-familiarize myself with timer differences
> between vendors and things like that, to understand why the Cisco<->Juniper
> adjacencies come up more slowly.
>
> It's not a major headache at this point (~30 secs to bring up a
> Cisco<->Juniper OSPFv3 adjacency vs ~10 secs to bring up a Cisco<->Cisco
> adjacency, and ~2 secs to bring up a Juniper<->Juniper adjacency), but
> something I'd like to understand fully and address before I start rolling
> things out in production down the road.
>
> Does anyone have any recommendations for tuning OSPFv3 in multi-vendor
> setups like this?

Perhaps look at the neighbor state through the 10 and 30 second
windows and see if you can see what state is taking the most amount of
time.
Are you exchanging a lot of routes? Maybe the back and forth of many
DBD packets are faster to be acknowledged on one host, but not the
other?

If you have the hardware, or are willing to do SVIs on the Cisco, try
and get a tap of the OSPF traffic and analyze protocol timings in
tshark or wireshark.

My two cents.

--j

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

Re: [j-nsp] MX80 Opinions

[Jonathan Lassoff]

I think Juniper's answer to redundancy with the MX80s is to setup 2x
MX80's and use routing protocols to switch over from one to the other.

For a fully loaded box, it probably edges up on making an MX280 a
better deal, but for the smaller software-limited MX80's I could see
it being an ok deal.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] M7i

[Jonathan Lassoff]

On Thu, Mar 24, 2011 at 1:02 AM, Joel Jaeggli  wrote:
> On 3/24/11 12:44 AM, cjwstudios wrote:
>> Hi Jonathan, thanks for the reply.
>>
>> The application is a service provider edge, all ethernet, with routed
>> traffic to two carriers.  Internal traffic is a mix of IGP and OSPF.
>>
>> I'll have to take a look at the EX series.  All of the literature on
>> the juniper site suggests the EX is targeted more toward lan
>> aggregation while the SRX handles the edge.
>
> ex doesn't have enough fib for a ful table so If you need to take two
> feeds and install all those routes, it's the wrong platform. m7i is just
> ducky at the speed you're talking but the re-400 is a bit underpowered
> and ramed for the modern era. re-850 with 1.5GB however is tollerable.

This is a very good point, and one that I kinda didn't think about. It
would probably be fine to take a decently-sized IGP table, but not an
external one. Though it could be used to terminate an MPLS path to pin
the BGP sessions and traffic elsewhere.

There's kinda a hole in Juniper's product line between something small
like a J-series or SRX and an M or MX-series box.
I suppose the MX80 fills that hole somewhat, but certainly not
cost-wise. If you can work some aggressive pricing (which at the end
of a quarter or year can be easier), it can be a pretty good deal for
an amazing box.

If you can afford it, use an MX80 for an all-Ethernet environment.
I've got several going, and they're just great.

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

Re: [j-nsp] M7i

[Jonathan Lassoff]

On Wed, Mar 23, 2011 at 11:49 PM, cjwstudios  wrote:
> Hello Juniper folks :)
>
> I'm setting up a remote metro ethernet site (fiber in a closet) that
> will have 2 x 100mb BGP transit feeds and a smattering of IGP feeds.
> The traffic will be service provider transit without inspection, NAT
> or other services.
>
> Since everything is cost sensitive these days I initially planned on
> implementing an ebayish 7206vxr-npe-g1.  Although I was quite happily
> slinging the 7206 around 10 years ago I realized tonight that it has
> been 10 years and the 7206 platform is well aged.   M7i (M7i 2AC 2FE
> w/ RE400,PE-1GE-SFP) are quite common on the secondary market now and
> likely more than enough to get started.  Although trunking multiple
> metro FE feeds to a single GE port will be frowned upon I may consider
> this as an option.
>
> I suppose my questions are whether a base M7i config out of the box
> will support this application or if there are better options out
> there.  Thank you in advance.

The M7 is an awesome router for small to medium sites. It does have an
on-board GigE port, so if you can fit everything in that or a
downstream switch it could work.
However, it's really starting to show its age and there's not much
development happening on the M-series routers anymore (at least it
seems that way to me -- I'm sure they're still supported).
They're also pretty rock solid with JunOS 9. JunOS code quality and
feature-completeness has started to really slip since 10.0.

I'm not sure I totally understand from your description what you're
trying to build, but it sounds like you're looking for a router that
will support up to 200 Mbit/s of routed traffic that can speak BGP and
whatever IGP you're running.

If your environment is all copper ethernet (seems pretty common these
days), I might suggest checking out some of the nicer EX switches.
While really targeted at the "top of rack" market segment, they can
route up to 10GigE (with the right modules and platform), and speak a
variety of protocols (though some require extra software licensing).
With a little negotiating (remember, "list price" is very inflated),
you should be able to get a lot more bang for your buck over an older
M-series in an all-Ethernet environment.

My two cents.

Cheers,
jof

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

Re: [j-nsp] LSA memory usage

[Jonathan Lassoff]

On Wed, Mar 16, 2011 at 8:15 AM, James Jones  wrote:
> Can anyone tell me the average memory usage for Type 1 and Type 5 LSA's?

FWIW, I have a very modest OSPF installation with 24 LSAs that "show
task memory detail | match ospf_lsa" suggests to me is using ~6k of
memory.

Hardware is an MX-80.

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

Re: [j-nsp] Load balancing using Ethernet Aggregate interface ae0

[Jonathan Lassoff]

On Tue, Mar 15, 2011 at 11:31 PM, medrees  wrote:
> Hi Doug
>
>   Thanks for your reply, my question is that "is it possible to make
> aggregation in two links from juniper side and the other side is connected
> to two different Layer-2 Cisco switches for load balance?" currently I'm
> connected this setup but one physical interface as primary and the other as
> backup inside the ae0.

I suppose it's possible that this might work in an active-standby
mode, but if the remote device(s) that you are connecting to are two
physically separate devices, you're much better off using a
higher-layer protocol to balance traffic over both links.

What type of hardware are the upstream Cisco devices? If they're
something like Cisco Catalyst 6500's with VSS running, it's possible
for you to balance traffic across both devices easily, since they both
act like a single device.

If they're two physically-separate devices, you'll have a hard time
getting this to balance properly in the reverse direction since you'll
be causing the source MAC address of your M10i to flip-flop between
switches (as seen from the perspective of your "upstream" Cisco
switches).

Hope this helps.

Cheers,
jof

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

Re: [j-nsp] building a gre tunnel between two juniper boxes (one behind a NAT)

[Jonathan Lassoff]

On Fri, Jan 28, 2011 at 5:07 PM, Simon Chen  wrote:
> Hi jof,
>
> I'm using mx-240, and I don't see the DHCP option... Can you tell me
> the exact configure path that I should check?

Sometimes options can be platform and version-specific. What version
of JunOS are you running?

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

Re: [j-nsp] building a gre tunnel between two juniper boxes (one behind a NAT)

[Jonathan Lassoff]

On Fri, Jan 28, 2011 at 4:02 PM, Simon Chen  wrote:
> Hi all,
>
> This might be a stupid question...
>
> I am trying to configure a GRE tunnel between two Juniper routers. One
> is connecting to the Internet with a public IP, the other one is
> unfortunately behind a broadband router --- this is a temporary setup,
> but I need to get it to work...

Unfortunately, since GRE is an IP protocol, it requires having two IPs
on the endpoints that can route directly to one another, or in your
case a NAT router that can support forwarding IP protocol 47 to your
NATed endpoint.

> What is my best option to build a GRE tunnel betweent these two
> routers? I am not sure if GRE would still work if one side is behind a
> NAT. I can potentially make the second router into DMZ, but it must
> run a dhcp client, which I don't think it's there...

JunOS has a DHCP client, just set the "dhcp" option under your iff
(interface  family ) interface and any associated options that
you'd like.

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

Re: [j-nsp] Unidirectional Ping on the J6350

[Jonathan Lassoff]

On Sat, Jan 8, 2011 at 2:45 AM, networking alcatel  wrote:
> Hi
>
> i'm sort of stuck ...
>
> One end is a J6350 router and the other end a Cisco router...
>
> the built up between these two devices is L2 and on a VLAN 10.
> From J6350 to the Cisco Router you are able to ping reverse you are not able
> to ping ,in the middle of the circuit there is a switch on which we tore the
> circuit into two segments and did a ping to the J6350 router and Cisco
> Router , both were ok.
> When the circuit is made through you are able to ping only from J6350 to
> Cisco Router the other way its not working.
>
> On the J6350 all protocols and services are allowed on the cisco no
> restrictions, its a /30 with a single IP's on either end any suggestions

If you're running a JunOS-ES version (factory default on new J-series,
I think), be sure that your policies in the "security { }" hierarchy
permit your ICMP traffic.

Cheers,
jof

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

Re: [j-nsp] Cisco 7206 replacement

[Jonathan Lassoff]

I guess that would depend on the hardware configuration that you have
in your 7206? What NPE are you using?

Assuming you're using an NPE-G1, which can run a few GigE ports at 1
Mpps, some comparable routers might be:

Juniper J6350 -- A CPU-based router (more inexpensive) that'll route
400 Kpps and connect a decent amount of GigE ports (52 GigE copper,
but probably not full duplex)

Juniper M7i -- A real hardware-based router that'll do 10 GbE / 16
Mpps (half-duplex).

Juniper MX -- A nice mixed Ethernet / IP router that comes in several
configurations, but can support 48 GigE ports and will do 55 Mpps.

Honestly, I would say that an MX would be the best long-term
investment if you're interested in checking out Juniper, want a robust
DOS-hardy edge router, but will also probably be the most expensive of
these suggestions.

Get in contact with an awesome reseller and ask around about who has
the best deals as the "list price" is often way inflated.

Many resellers will give you a good deal if you're checking out
Juniper for the first time, since they usually have way better
products that Cisco but cost a little more. It's easy to get hooked on
well-made routers :p

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

Re: [j-nsp] any command/tools to know traffic immediately

[Jonathan Lassoff]

 I really like the "monitor interface traffic" screen.


It's a little app that loops over writing out some columnnar statistics on 
interface rates and link states, clears the screen, and repeats.

Cheers,
jof


On Thursday, December 9, 2010 at 10:44 AM, Deric Kwok wrote:

> Hi
> 
> When the bandwidth is high / spike, how can I be easy way to identify
> the traffic coming from in juniper/netscreen
> 
> In linux, I can run the iftop -i int
> 
> 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] JunOS route-based VPN: multiple st interfaces

[Jonathan Lassoff]

On Mon, Nov 29, 2010 at 6:49 PM, Adam Leff  wrote:
> Also, for what it's worth, I do have multiple logical interfaces under st0
> (i.e. st0.0 and st0.1) and it is working without requiring NHTB.

Without NHTB? So the "security ipsec vpn XXX" hierarchy has a
"bind-interface" statement, but the iff hierarchy under st0 *doesn't*
have a "next-hop-tunnel" statement?

> Do you have all the pre-requisites set up?  i.e. st0.1 in the proper
> security zone, a route pointed down st0.1 for the traffic to be tunneled,
> etc.?

I'm pretty sure everything looks right (but just to me, so it's
certainly possible that there's a bug or two in my config). st0.1 is
in a security zone that has policies to permit vpn-monitor ICMP
traffic, and I'm not even routing over the st0.1 interface yet, just
pinging the remote end.

Cheers,
jof

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

[j-nsp] JunOS route-based VPN: multiple st interfaces

[Jonathan Lassoff]

I'm trying to setup an SRX in my office as a branch office with two
ISP connections, and I'd like to run an IPSec path over each back to
our datacenter. Ideally, I could terminate each tunnel on a separate
st0 unit (ifl's of st0.0 and st0.1), but it seems that JunOS will only
try to establish IPSec SPIs for VPNs that are bound to st0.0. I had a
second bound to st0.1, but it would never even try to send IKE traffic
to start the connection.

So, I've got some failover working now by doing hub-and-spoke (in a
bit of a reverse fashion: one device at the datacenter, two paths to
the branch device) style config -- both VPNs are tied to st0.0 which
is configured as a multipoint interface. My only trouble now is
directing st0.0 traffic down a specific interface, it seems like there
isn't a way to tell it which VPN tunnel to prefer for sending traffic
down.

Any ideas or opinions on what the right way to do this is? I feel like
two separate st0 units makes the most sense, but it's stumping me as
to why it never tries to establish a session.

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

Re: [j-nsp] JunOS 10.0R3 MX960 (DPC's only)

[Jonathan Lassoff]

On Sun, Oct 31, 2010 at 6:29 PM, Derick Winkworth  wrote:
> this is an on-going topic here.  I'm wondering if we should set up an
> independent website with a hardware/software matrix hyperlinked to known 
> issues
> with problem descriptions/diagrams (if available) etc...

If only there was a website related to this topic
http://juniper.cluepon.net/index.php/DPC

There isn't much in the way of a hardware/bugs table, but there are
plenty of pages about specific hardware platforms and a list of bugs.

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

Re: [j-nsp] J6350 Jumbo frame MTU and OSPF setting

[Jonathan Lassoff]

While having an increased MTU across your WAN can improve throughout
greatly, I would suggest tuning your TCP stack for a "Long Fat Pipe", as
many operating systems are not designed to work well with high-throughput,
high-latency links.

There are some good tips here: http://fasterdata.es.net/

Cheers,
jof

On Sep 30, 2010 10:38 PM, "Harris Hui"  wrote:



Dear all,

We had subscribed a private line circuit between 2 different data center
for Data Backup and replication. The bandwidth of the private line is
100Mbps.

According to the provider, The Circuit is Built across their
 Network as 2 STS1's or High Speed DS3's which equals 100meg.

Their GE port setting as follows.

MTU Size - 9600
Auto Negotiation - OFF
Remote Client Fail - Disabled.

The private circuit is connected directly to the fiber module of our J6350
Services router at each Data Center. The Circuit is up and running but when
we perform some TCP throughput test, we only get ~3Mbps for a Single TCP
session with iPerf and the latency between two data center across the
private circuit is ~80ms.

I am trying to configure our J6350 fiber interface to MTU 9192 to get a
better TCP throughput. However, I can only able to configure the MTU size
below 1500, when I configure the MTU to 9192 and commit the changes, it
still shows MTU 1500 on the physical interface.

Do you have any experience on using Jumbo frame MTU size on the J6350? We
are also running OSPF across the private circuit, is JUNOS support "OSPF
ignore-mtu" like cisco?

Please advise.

Fiber module

FPC 3REV 18   750-013599   AAAH7361  FPC
 PIC 0  1x GE SFP
   Xcvr 0   REV 02   740-011614   PG336CS   SFP-LX10

show interfaces ge-3/0/0
speed 1g;
mtu 1400;
link-mode full-duplex;
gigether-options {
   no-auto-negotiation;
}
unit 0 {
   family inet {
   address xxx.xxx.xxx.253/30;
   }
}

har...@j6350# run show interfaces ge-3/0/0
Physical interface: ge-3/0/0, Enabled, Physical link is Up
 Interface index: 152, SNMP ifIndex: 184
 Link-level type: Ethernet, MTU: 1400, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled,
 Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:
Disabled, Remote fault: Online
 Device flags   : Present Running
 Interface flags: SNMP-Traps Internal: 0x4000
 Link flags : None
 CoS queues : 8 supported, 8 maximum usable queues
 Current address: b0:c6:9a:87:35:36, Hardware address: b0:c6:9a:87:35:36
 Last flapped   : 2010-09-27 02:32:24 UTC (4d 02:29 ago)
 Input rate : 0 bps (0 pps)
 Output rate: 0 bps (0 pps)
 Active alarms  : None
 Active defects : None

show interfaces ge-3/0/0
speed 1g;
mtu 9192;
link-mode full-duplex;
gigether-options {
   no-auto-negotiation;
}
unit 0 {
   family inet {
   address xxx.xxx.xxx.253/30;
   }
}

run show interfaces ge-3/0/0
Physical interface: ge-3/0/0, Enabled, Physical link is Up
 Interface index: 152, SNMP ifIndex: 184
 Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled,
 Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:
Disabled, Remote fault: Online
 Device flags   : Present Running
 Interface flags: SNMP-Traps Internal: 0x4000
 Link flags : None
 CoS queues : 8 supported, 8 maximum usable queues
 Current address: b0:c6:9a:87:35:36, Hardware address: b0:c6:9a:87:35:36
 Last flapped   : 2010-09-27 02:32:24 UTC (4d 02:35 ago)
 Input rate : 0 bps (0 pps)
 Output rate: 1192 bps (2 pps)
 Active alarms  : None
 Active defects : None


Thanks
Harris
___
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] J-Series: filtering only RE-bound traffic?

[Jonathan Lassoff]

I'm trying to setup some filtering on my loopback and WAN interfaces
to only filter RE-bound traffic.

I'm doing this by applying a "filter input" term to the iff-level
(interface xxx unit xxx family [inet/inet6]), but this filter seems to
also catch traffic being forwarded from the WAN interfaces, so the
filter is affecting downstream traffic as well.

On platforms I've used in the past (M and MX -- "real" PFEs), these
filter terms only catch locally-bound traffic and not things
transiting the router. Is there a way to do some sort of similar
classification on J-series as well?

I have my box configured with the included "router" mode template
(packet-based forwarding, all interfaces in a trusted security zone,
etc.)

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

Re: [j-nsp] Is the J-6350 in Chassis Cluster mode support Router Context (IPv4 Packet-based forwarding)

[Jonathan Lassoff]

On Thu, Sep 2, 2010 at 9:21 PM, Harris Hui  wrote:
>
> Hi all,
>
> The J-6350 in JUNOS 10.0R3.1 can disable the security context (flow-based
> forwarding) and use it as a Router Context (IPv4 Packet-based forwarding).
> I had tested this on a single J-6350 box.
>
> Did anyone tested to disable the security context and enable the router
> context in a chassis cluster configuration? If yes, could you share the
> experience with me? Thanks a lot!

I would imagine that this can be done, but admittedly, I've never run
"router mode" in a chassis cluster.

Check out the factory-included
/etc/config/jsr-series-routermode-factory.conf file. It sets some
other things under security { } as well, like disabling TCP SYN and
sequence checking.

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

Re: [j-nsp] 10.3 on MX960 with MPC only?

[Jonathan Lassoff]

Agreed. To me, it seems to me that the overall quality of JunOS has slipped
since 10.x, however recovering from most problems on JunOS is at least
possible.

In classic IOS, even a small bug or memory leak can quickly turn into a
major catastrophe (no memory management/supervision and a single binary
image). On Juniper platforms, one can usually kill and restart the affected
daemon while the PFEs still chug along.

I hope Juniper takes some time to get their release quality back up to the
par we've come to expect from them over the years.

Cheers,
Jof

On Aug 30, 2010 6:21 PM, "Chris Evans"  wrote:
I have real concerns with juniper.  We are primarily a Cisco shop and are
using juniper devices here and there.  I have to honestly say, anymore Cisco
code is way more stable than Junos. I'm always finding major bugs in junos,
yet any Cisco bugs we are finding are usually cornercase ones.

The latest junos bug I've found is that with the mx platform igmp snooping
doesn't work at all in 10.0 and other train releases. In 10.3 all mulicast
is broken when using irb interfaces.  Seriously is no one testing?

I hope they get their act together soon

On Aug 30, 2010 7:57 PM, "Richard A Steenbergen"  wrote:

> On Mon, Aug 30, 2010 a...
> > In fact, yes! 10.3 is primarily...

> The story I've heard is that they put the brakes on almost all new
> feature development for 10.3 ...
> > similar to 8.5. Perhap...

> Don't get your hopes up, I don't think there has been any significant
> progress made on the route...
> juniper-nsp mailing list juniper-...@puck.nether.net...

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

Re: [j-nsp] JUNOS OID

[Jonathan Lassoff]

On Wed, Aug 18, 2010 at 12:06 AM, Bjørn Tore  wrote:
> You'll find it under
>   jnxOperatingBuffer,  1.3.6.1.4.1.2636.3.1.13.1.11

And you can find which index to use under that tree (in case you want
to monitor PICs or multiple RE's) by examining the contents of
jnxOperatingDescr ( .1.3.6.1.4.1.2636.3.1.13.1.5 )

Cheers,
jof

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

Re: [j-nsp] EX4200 sFlow on cluster

[Jonathan Lassoff]

Excerpts from Abel Alejandro's message of Wed Mar 31 18:59:08 -0700 2010:
> Hello,
> 
> I am running 4 x EX4200 in a virtual chassis configuration. I configured
> sFlow but I can not get it to work.
> Basically the configuration is accepted and no errors are given but no
> flows are sent to the collector.
> 
> I tried placing the collecting within the same subnet as the vme 0
> management interface and also moving it to a physical port.
> 
> According the EX4200 the flows are being sent but I am running a tcpdump
> on the collector and nothing is coming from the EX4200.

Could a ACL be blocking the exports?

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

Re: [j-nsp] ipv6 routing

[Jonathan Lassoff]

Excerpts from chrisccnpspam2's message of Wed Mar 31 12:13:14 -0700 2010:
> Forgive me for not fully remembering as its been a while since I muddled with 
> v6.  But for some reason I believe you have to do the static route to a link 
> local address, not to the address you configure under the interface. This 
> would be the address starting with "fe80"
> 
> Can anyone validate my vague memory?

I'm not so sure about the applicability of this under JunOS, as most of
my work with it has been for IPv4/inet installations.

Protocol-wise though, I can't think it should matter. A next-hop via a
link-local address or one addressed out of the global unicast pool
should resolve all the same (i.e.. they'll both result in ICMPv6
Neighbor Solicitations)

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

Re: [j-nsp] EX Switches - Internet Exchange Points

[Jonathan Lassoff]

Excerpts from Paul Stewart's message of Fri Mar 26 06:10:47 -0700 2010:
> Hi there..
> 
> I just wanted to follow up on this - I'd open a case at JTAC but honestly
> have no idea where to get started with them yet...;)
> 
> So, the MAC filtering worked for one of the exchange points yesterday ...
> then late last night one of our upstream providers dropped off.  With the
> upstream provider I've asked them for port security logs so I can start
> hunting for MAC's they are seeing  this will hopefully provide a clue.

Oh no! Hopefully you're multihomed :)

It's strange that a transit provider would drop a connection because of
layer 2 traffic it doesn't like. Perhaps the outage was unrelated?

Every transit I've dealt with delivers service over a point-to-point
link (an Ethernet segment with just two routers on it), with no port
security or spanning tree.

IXes on the other hand seem to regularly implement port security as a
way of preventing loops in a switched environment without spanning tree
running. It's a hassle to deal with spanning tree across administrative
boundaries.


If you're still trying to track down traffic that's appearing without
explaination, and have a free PC with a GigE NIC, attach it to an
analyzer port and just start capturing.
 
> Is there a way in a filter to log denied MAC addresses?  Snippet looks like
> this:
> 
> family ethernet-switching {
> filter core2_peering_filter {
> term expected_mac_address {
> from {
> source-mac-address {
> 00:0b:45:b6:f5:00;
> }
> }
> then accept;
> }
> term block {
> then discard;
> }
> }
> 
> I tried to add "then discard log" to the term block but I get:
> 
>   'filter'
> Referenced filter 'core1_peering_filter' can not be used as log not
> supported on egress
> error: configuration check-out failed

Looks like it's not supported on egress then. This has the potential to
log a LOT.

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

Re: [j-nsp] EX Switches - Internet Exchange Points

[Jonathan Lassoff]

Excerpts from Richard A Steenbergen's message of Thu Mar 25 16:52:15 -0700 2010:
> On Thu, Mar 25, 2010 at 03:13:31PM -0400, Paul Stewart wrote:
> > The problem I'm facing we're tripping the port security on the exchange
> > switch:
> > 
> > Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
> > violation occurred, caused by MAC address 000b.45b6.f500 on port
> > FastEthernet0/1.
> > 
> > It is obviously seeing several MAC addresses and doesn't like this.  so I'm
> > trying to adapt a "best practice" here based on what other folks have
> > encountered along the way as we're trying our best to learn Juniper better
> > ;)
> 
> The MAC address vendor database says 000b45 is Cisco, so either you have
> a misconfiguration or your Juniper is leaking something it shouldn't be,
> but at least is isn't generating something on its own. I'd recommend you
> track down that MAC address on your network and figure out how it is
> getting to the exchange, since if the Juniper is leaking things outside
> of its configured vlan it is a Big Problem (tm) which needs to be fixed.

>From the original post, it sounds like Paul was using a Cisco as the
router and just using his EX switch as an L2 device to connect the two,
in which case, the Cisco OUI seems expected.

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

Re: [j-nsp] EX Switches - Internet Exchange Points

[Jonathan Lassoff]

Excerpts from Paul Stewart's message of Thu Mar 25 13:09:51 -0700 2010:
> Thanks very much for the reply...
> 
> The AMS-IX guide I've been through but their Juniper section isn't nearly as
> detailed as the Cisco side... good guide for sure. ;)
> 
> The MAC shown in my example below is actually the correct MAC for the layer3
> facing interface ... so you're suggesting to create a filter to only allow
> that MAC to be 'sent out' to the peering switch?  We never had to do this in
> the Cisco world using the configurations I sent in my original post hence
> some of my confusion...

Ok, I checked this out on a spare EX-3200.

Maybe some configuration like:

firewall {
family ethernet-switching {
filter XXX-IX_Peering_Filter {
term expected_mac_address {
from {
source-mac-address {
00:0b:45:b6:f5:00;
}
}
then accept;
}
term block {
then discard;
}
}
}
}

interfaces {
 ge-x/x/x {
  unit 0 {
   family ethernet-switching {
filter {
 output XXX-IX_Peering_Filter
}
   }
  }
 }
}

Would accomplish what you want.

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

Re: [j-nsp] EX Switches - Internet Exchange Points

[Jonathan Lassoff]

Excerpts from Paul Stewart's message of Thu Mar 25 13:09:51 -0700 2010:
> Thanks very much for the reply...
> 
> The AMS-IX guide I've been through but their Juniper section isn't nearly as
> detailed as the Cisco side... good guide for sure. ;)
> 
> The MAC shown in my example below is actually the correct MAC for the layer3
> facing interface ... so you're suggesting to create a filter to only allow
> that MAC to be 'sent out' to the peering switch?  We never had to do this in
> the Cisco world using the configurations I sent in my original post hence
> some of my confusion...

Indeed, Cisco is a big global player in the switching market, so many
guides and experience are with Cisco gear.

There's probably some other protocol running that's causing frames from
other source MACs to be sent out of your port facing the peering switch,
either from your Juniper or your Cisco interface.

Maybe implement port security on your downstream interfaces that are on
your peering VLAN/bridge..

If you can track down that protocol and disable it out of the interface
in question, all the better.

I was suggesting an L2 filter since if it's supported, it should give
you the effect you want for the least amount of effort (no packet
tracing, taps, etc.), but it comes at the cost of having to go back and
change the filter if you want to change routers.

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

Re: [j-nsp] EX Switches - Internet Exchange Points

[Jonathan Lassoff]

Excerpts from Paul Stewart's message of Thu Mar 25 12:13:31 -0700 2010:
> I'm looking for feedback from folks on the list who are service providers
> and connect to peering exchange points (IE. PAIX, Equinix, LINX etc).   I'm
> looking for recommended configuration for layer2 connectivity via an EX
> switch towards one of these exchange points - we have been doing in Cisco so
> long that I'm missing some obvious config in the Juniper's we just moved to
> ;)

AMS-IX has a nice guide and some useful suggestions over here:
http://www.ams-ix.net/config-guide/#10


> The problem I'm facing we're tripping the port security on the exchange
> switch:
> 
>  
> 
> Mar 24 15:36:52.773 EDT: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
> violation occurred, caused by MAC address 000b.45b6.f500 on port
> FastEthernet0/1.
> 
> It is obviously seeing several MAC addresses and doesn't like this.  so I'm
> trying to adapt a "best practice" here based on what other folks have
> encountered along the way as we're trying our best to learn Juniper better
> ;)

Doh!

If your platform supports it, implement a packet filter that blocks all
traffic except for the single MAC that you think should be on that port.

Maybe IGMP is leaking out?

Also, depending on your platform, tcpdump (probably not much help on an
L2 switch configuration) or a passive tap could provide some indication
as to what traffic is causing port security to trip on the far side.

Is 00:0b:45:b6:f5:00 the Ethernet MAC you expect to be seeing?

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

Re: [j-nsp] EX 8200 deployment

[Jonathan Lassoff]

Excerpts from Dan Farrell's message of Thu Mar 25 09:13:59 -0700 2010:
> Flash gets a bad rap. I think most people have heard of supposed horror 
> stories or they see the cycle limit and get wary.
> 
> But I'm wondering... has anyone in this list actually had a personal flash 
> horror story? I don't have one of my own, and I'm swimming in network devices 
> (some quite old) that use them.

I've definitely observed wearing out older multi-layer flash chips, but
every modern (in the last several years) flash device I've run across
implements some sort of damaged cell management on the chips controller.

If you're careful about how you access the device (mounting filesystems
with no atime, no heavy logging, etc.), I'm convinced that modern flash
works just fine in an embedded application like this.

That being said, I think Richard is right regarding adding expandable
flash. 
Flash is so cheap and constantly developing, it seems like a no
brainer to just eat the cost of adding a small controller-on-a-chip,
some discrete components, and a CF slot to future-proof the storage.

In looking at the EX platforms though, this doesn't seem in line with
Juniper's design goals though (not that I actually know what they
planned). It seems like most of the hardware ('cept the EX-8200) comes
in a fixed configuration -- stuff that's just supposed to "work", and
not to worry the manuf. with compatibility concerns.


If you're feeling gutsy and want to void any warranties, you might try
de-soldering and replacing the internal flash :)

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

Re: [j-nsp] RFC2544 on Juniper MX960 10G ports

[Jonathan Lassoff]

Excerpts from Serge Vautour's message of Thu Feb 18 16:28:44 -0800 2010:
> Hello,
> 
> We recently used a traffic generator to run RFC2544 tests against a Juniper 
> MX960. The 1G ports work flawlessly. 0% packet loss at all frame sizes. 
> 
> The 10G ports  (4x10G "R" card) didn't do as well. They dropped up to 25% 
> packets with certain small frames (ex: 70 byte frames). The packet loss goes 
> away almost completely for frames larger than 100 bytes. Our SE tells us this 
> is normal and is due to how the MX chops the frames up into 64 byte cells 
> inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G port) and 
> each of them has 10G of bandwidth. 10G of small frames essentially creates 
> more than 10G of traffic inside the PFE. That explanation may not be 100% 
> correct but I think it paints the right picture.
> 
> Now the questions. Is this a problem on production networks with real world 
> traffic? What about on VPN networks with alot of small frames like VoIP? Has 
> anyone seen this problem creep it's head in production?

Isn't the minimum Ethernet frame size 64 bytes? I think Ethernet II /
Ethernet 802.3 requires this.

Wouldn't this make the problem moot if you're just running Ethernet?

Might be a problem with small ATM cells?

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

Re: [j-nsp] read-only config account, "rancid" user

[Jonathan Lassoff]

Excerpts from matthew zeier's message of Thu Feb 04 09:14:52 -0800 2010:
> Not clear how to create a dumbed down read-only user who can just view the 
> config.  
> 
> In a Cisco world I'd use "privilege exec level" .  In JunOS, a read-only 
> class can't run "show configuration".
> 
> What's the nugget of info I'm missing?

Define a system login class that includes the "view" and
"view-configuration" permissions. You could also explicitly place a
regexp in the class to allow certain CLI command patterns to be allowed.
This could be useful if you're also setting rancid to fetch things other
than the configuration.

For example:

system {
 login {
  class only-see-config {
   permissions [ view view-configuration ];
  }
  user rancid {
   class only-see-config;
   authentication {

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

Re: [j-nsp] aggregate ethernet

[Jonathan Lassoff]

Excerpts from Taqdir Singh's message of Wed Jan 27 19:26:39 -0800 2010:
> Hi Team,
> 
> JUNOS doesn't support layer 2 aggregate ethernet (i mean layer 2
> ether channels ) ?
> 
> and how many max links we can combine in junos, in cisco we can combine upto
> 8 ?

I would think this would depend on the platform you're doing this on.
I've tested link aggregation (both with and without LACP as a control
protocol) on the EX and MX platforms.

EX has a limit 12 links per LAG, and a limit of 64 LAGs per virtual
chassis. The Juniper documentation says that the EX8200 can support up
to 256 LAGs, but I can't vouch for it, as I've not used that device
before.


The documentation I can find suggests that all platforms can support up
to 128 LAG interfaces with the right software, with a maximum of 8 links
per bundle.
However, all T-series, M120, M320, MX960, MX480, and MX240 can support
up to 12 links per bundle.

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

Re: [j-nsp] tagged traffic on EX access port

[Jonathan Lassoff]

Excerpts from Malte von dem Hagen's message of Wed Dec 23 10:23:45 -0800 2009:
> what exactly do you want to do? It's not yet clear to me.
> 
> Anyway, you seem to mix up "vlan-tagging", which is a JunOS-Option for 
> L3-ports,
> and "port-mode trunk", which does quite the same for L2-ports (below "family
> ethernet-switching"). On the EX, you can of course configure a trunk-port with
> just one VLAN, if that's what you want do do.

This is the right way to configure 802.1Q trunks on EX'es.

For example, from an EX4200:

--
j...@ex1.sfo2> show configuration interfaces xe-0/1/0 
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ foo bar ];
}
}
}
--

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

Re: [j-nsp] PFE-forwarded IPv6

[Jonathan Lassoff]

Excerpts from Truman Boyes's message of Tue Dec 22 20:12:34 -0800 2009:
> Hi Jonathan,
> 
> You can use any of your DPCs. On non-MX JUNOS routers you need to have tunnel
> pics (ie. packet that needs to be encapsulated/tunneled/etc will switch from
> PFE to PIC to PFE). MX does not require this because you can make the DPC
> perform tunnel-services. 
> 
> Once you create the tunnel-services function on the DPC, you can associate the
> IPIP tunnel interface with the tunnel service. Ie. Change the IPIP.0 to:
> ip-3/0/0.0, which corresponds to your FPC 3 PIC 0, port 0 unit 0. 


That seems to have done the trick.

One thing I found when trying this on my platform is that configuring:

fpc 3 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}

Which is:

FPC 3REV 15   750-021157   xxDPCE 40x 1GE R TX
  CPUREV 03   710-022351   xxDPC PMB
  PIC 0   BUILTIN  BUILTIN   10x 1GE(LAN) RJ45

Yields an ip-3/0/10, instead of the ip-3/0/0 that's shown as an example in the 
documentation.

I configured this, and traffic passes just fine.

Thanks for the tip Truman.

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

Re: [j-nsp] PFE-forwarded IPv6

[Jonathan Lassoff]

Excerpts from Truman Boyes's message of Tue Dec 22 18:25:23 -0800 2009:
> Have you enabled the tunnel-services statement at the [ edit chassis fpc
> slot-number pic pic-number] stanza?

Thanks Truman!

Nope. I've yet to find reference to this in the documentation relating
to setting up tunnels. Do you have any recommendations for where I find
out more about what this is doing architectually? 

On which slot and pic number do you think I should choose? I read that
the MX's DPCs have built-in tunnel-services PICs along with a number of
fixed interface PICs.

I assumed I should choose the DPC and PIC number for the upstream
interface that goes towards the tunnel's outer IP destination:

j...@mx1.sfo2-re0> show configuration chassis fpc 3  
pic 0 {
tunnel-services {
bandwidth 1g;
}
}

However, I'm still seeing the same ICMPv6 responses, and traffic is not
passing.

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

Re: [j-nsp] PFE-forwarded IPv6

[Jonathan Lassoff]

Excerpts from Truman Boyes's message of Tue Dec 22 04:17:22 -0800 2009:
> Can you post the relevant configuration from the box? I expect that the host 
> is
> directly connect to the MX-960; and the interface that is facing the host is
> running RA; furthermore if you look at the routing table on the host, you will
> see a default route to the MX's link-local address?

Actually, I was testing with a Cisco Cat6k/Sup720 box downstream to test
the interoperability of the two routers, and also IPv6 on the Cat6k.

As a test to better understand what's going on, I attached a host
downstream from the MX960. I can ping and reach the MX's inet6 interface
just fine. I'm also setting my default route to go through the inet6
interface on the MX.  Pinging out to 2001:500:2f::f (f.root-servers.net)
through this interface causes the MX to return an ICMPv6 Unreachable
(Address unreachable) message.

However, there's a route on the MX to that destination:

--
j...@mx1.sfo2-re0> show route 2001:500:2f::f 

inet6.0: 2299 destinations, 2302 routes (2299 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2001:500:2f::/48   *[BGP/170] 1w3d 20:24:53, localpref 100
  AS path:  x 3557 I
> to :xxx::xx::1 via ipip.0
--

Here's the relevant configuration of interface "ipip":
--
j...@mx1.sfo2-re0> show configuration interfaces ipip 
unit 0 {
tunnel {
source xxx.xxx.xxx.xxx;
destination xxx.xxx.xxx.xxx;
}
family inet6 {
address 2001:xxx::xx::2/64;
}
}
--

Thanks for any help or insight you can provide.

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

[j-nsp] PFE-forwarded IPv6

[Jonathan Lassoff]

I'm having an odd problem routing IPv6 traffic through an MX-960 I'm
testing. I'm sending traffic from a directly connected host through the
Juniper box to be routed out to the Internet. I can ping the address on
the MX from the downstream router, but can't seem to route *through* the
Juniper.

One thing that may be pertinent is that the next-hop I expect the
traffic should take is on the other end of a 6in4 tunnel.

Any ideas?

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

Re: [j-nsp] The P2MP LSP story when using LDP for VPLS?

[Jonathan Lassoff]

Excerpts from Patrik Olsson's message of Sun Dec 06 21:57:11 -0800 2009:
> Yes, today P2MP can only be achieved with RSVP. Also, P2MP is thought
> for a different application than VPLS perhaps. VPLS is bidirectional
> any-to-any communication. P2MP is one-way from-on-to-many communication.

P2MP LSP's are totally applicable in use with VPLS. Broadcast frames,
unknown destination unicast, and multicast (although in the case of
Ethernet, kinda like broadcast) need to get sent to all or multiple
PE's.

My understanding is that a P2MP LSP will duplicate the encap'ed frames
to use core bandwidth more efficiently.

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

Re: [j-nsp] MX960 JunOS recommendations

[Jonathan Lassoff]

Excerpts from sthaug's message of Thu Nov 12 00:12:16 -0800 2009:
> Absolutely. We use quite a bit of dual tagging on Ethernet, so then we
> need to crank it up to 4492. But all our backbone links are 4484 on the
> Juniper side.

Is there a reason not to use 9000-bytes everywhere (accounting for
bridges/interfaces that count/don't count ethernet headers)?

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