Re: [j-nsp] format of minimum and maximum value of math:random() in SLAX

[Michael Loftis]

idk if there’s a floor function but the general solution is floor(rand() *
16) when rand() produces values 0-1(exclusive) IE if random does not
generate 1.0 - dunno implementation details for slax

On Thu, Jul 5, 2018 at 13:43 Martin T  wrote:

> Hi!
>
> According to the documentation, math:random() function returns a
> random number with a minimum value of 0 and a maximum value of 1.
> Larger values than 0 and smaller values than 1 have a format similar
> to 0.663341003779015. What is the format of minimum and maximum value?
> Simply 0 and 1? 0.000 and 1.000? The reason I
> ask is that I use "substring(math:random(), 3, 2) mod 16" for finding
> random numbers between 0 and 15 and I need to apply a workaround if
> format is not always x.xxx.
>
>
> thanks,
> Martin
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX 300 VPN

[Michael Loftis]

I wouldn’t bother. Terminating anything other than static site to site on
SRX is a nightmare. The clients are trash even when they work. Install
openvpn internally and port forward.

On Thu, May 24, 2018 at 13:47 Łukasz Trąbiński  wrote:

> Hi
>
> I’m trying setup dynamic VPN (using 18.1R1.9) on SRX 300 - I want to have
> access from internet to my home network.
>
> First, I’m confused about vpn client. Should I use Junos Pulse?  I’t looks
> like not supported by Juniper right now (latest version is from 2015).
> Should I use Pulse Secure?
> I’ts possible to use „native” vpn client from mac os x or Windows?  I also
> found information that Dynamic VPN is not supported on new SRX boxes.
> If it still supported, where I can find newest documentation how to
> correctly setup?
>
> Of course I tried confgiure vpn tunel but without success. Below, fragment
> form logs / trace debug:
>
> [May 21 10:48:38]IKEv1 packet R(:500 <- xx.xx.xx.xx :500): len=
>  40, mID=125b77cb, HDR, N(NO_PROPOSAL_CHOSEN)
> [May 21 10:48:38]ike_st_i_n: Start, doi = 1, protocol = 1, code = No
> proposal chosen (14), spi[0..0] =   ..., data[0..0] =
>   ...
> [May 21 10:48:38]:500 (Responder) <-> xx.xx.xx.xx:62252 { c14a7f01
> 1d013489 - 82bf44a1 0fddfa77 [0] / 0x125b77cb } Info; Received notify err =
> No proposal chosen (14) to isakmp sa, delete it
>
> Where I can find some examples of proper configuration dynamic vpn for
> actual version of Junos?
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

[Michael Loftis]

My experience with DACs in the wild is they're not worth the trouble. Even
if they "work" once you look closer you'll spot that they're not working
well. Lots of errors/corrections at higher rates etc. better luck with say
1m or truely active DACs but thing is (Q)SFP(+) was never meant to be more
than an interconnect between points on the same board and the signal timing
constraints, drive levels and basically every other design decision and
constraints reflect that. It's got a very short maximum distance.

On Fri, Dec 1, 2017 at 13:18 Emille Blanc 
wrote:

> To close this thread, DAC's appear to have been a wash.
> Using like-vendor branded optics on both sides, and we have a functioning
> 40Gbps link.
>
> Thanks for the feedback on, and off-list. :]
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Chuck Anderson
> Sent: November-21-17 7:10 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+
> DAC's
>
> On Tue, Nov 21, 2017 at 06:28:07AM -0800, Emille Blanc wrote:
> > Hello folks,
> >
> > Trudging through the woes that are cross-vendor compatibility issues,
> and failing completely at getting a link between an EX3400 or EX4600, and
> an HPE FlexFabric-20/40 F8 card in our c7000 enclosure using an HPE branded
> QSFP+ 3mtr DAC.  That is to say, Juniper on one side, HPE on the other.
> > As an added bonus, the HPE module seems to be allergic to Juniper's QSFP
> completely.
> >
> > After the inevitable "It's not us, it's them" back-and-forth between
> JTAC and HPE Support, I'm looking for any success (or failure) stories from
> the community.
> >
> > We've been testing with a pair of HPE DACs, and they each work fine when
> we loop it to two QSFP+ slots in the same chassis/module.
> >
> > Has anyone been successful in making such a connection in the wild?
>
> Buy cheap QSFP+ optics and use fiber?
> ___
> 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
>
-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Ex4550 sfid process increase cpu

[Michael Loftis]

You don't have GRE or anything do you?  As I understand it sfid
basically handles CPU side traffic for things like GRE, ping, arp,
etc, that originate/terminate at the switch.

On Sat, Sep 16, 2017 at 2:58 AM, Rodrigo 1telecom
 wrote:
> Hi, we have one ex4600 and ex4550 and have a interconnection( vlan) with 
> IX-SP connected on ex4600. this switch is connected on ex4550 and goes to 
> my router my ex4600 have a normal operarion... does not increase any 
> process and cpu have a normal operation. But my ex4550 have a high cpu levels 
> all time if we disable IX-SP PORT on ex4600  This cpu goes to 10% on 
> 4550.
> Sfid process increase my cpu so much 
> Already update this switch to j-tac version and have the same  something 
> wrong is comming from IX-sp but don't know what...
> Anybody can help?! Because if i have a normal operation in 4600 why 4550 have 
> this ?!
>
>
> Enviado via iPhone 
> Grupo Connectoway
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Set system no-ping-time-stamp

[Michael Loftis]

Exactly what the documentation states it's perfectly clear...
Disbales responding to ICMP Echo request sent to a multicast group,
disable sending IPv4 redirects, etc.  Most of those can be done at the
interface or system level.  They don't allow/disallow/change behavior
of commands, just the responses to network devices (which MAY in fact
be itself)

On Mon, Mar 6, 2017 at 5:06 AM, Valentini, Lucio
 wrote:
> Hi folks,
>
>
>
> I´ve been using these commands for quite a while now:
>
>
>
> set system no-multicast-echo
>
> set system no-redirects
>
> set system no-ping-record-route
>
> set system no-ping-time-stamp
>
> however, I only took the time to test them out today and I can only figure 
> out what
>
>
> set system no-ping-record-route
>
>
>
> does, when I use the ping command in operational mode with "record-route". 
> The question is, what do the other commands do ? Juniper does not seem to 
> provide examples. I never see the time stamp in the ping response anyway.
>
> Thanks
>
> Cheers
> Lucio
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] interpreting 10Gb interface "PCS statistics" values

[Michael Loftis]

Was hoping someone who knew more could chime in...but it's measured in
seconds basically because the PCS (physical coding sublayer) does NOT
keep detailed statistics...so the "Seconds" value means there were X
distinct seconds in which an error was flagged in that category...the
previous response detailing bit vs errored blocks I think is wrong.
The PCS layer can repair single bit errors, thus a second with one or
more single bit (but correctable!) errors is a "bit errored second" -
if it is unabled to correct and recover a valid PCS block then you get
the "errored block" seconds...

It's not a raw count of the number of those errors, just that it
occurred in a ~1s window X times.  You can totally get PCS errors
unplugging an optic or otherwise shutting down the remote end.  You
can totally get spurious PCS errors from a marginal ish link that
shows PLENTY of light (SNR is low or a marginal cable).  in MX
specifically it *can* in very rare circumstances indicate a problem
even between the optic and the MICmost of the time my suggestion
for PCS errors is clear counters and check in 1h and 24h.  If you get
a significant number of errored seconds in a 24h period then
check/clean ends and patches, maybe replace optics.

Also beware, lots of DOM bugs in various JunOS releases cause the DOM
values to get stuck, and it can be hard or impossible to check in a
non outage causing way (sometimes you can safely bend the patch cable
and observe the increase in loss to verify your DOM values aren't
stuck) - I've had this most commonly in the past on DPC cards but have
also observed it in MPC cards.  The DOM data is also highly dependent
upon the optic itself and there's a LOT of buggy stuff out there so
it's not all juniper's fault there.


On Fri, Oct 21, 2016 at 11:07 AM, David B Funk
 wrote:
> Thanks guys but this isn't what I was asking.
>
> The optical power is similar (within a few tenths of a dBm) at my end, down
> by 3 dBm at the far end of the link that is having issues (-6.23 dBm as
> opposed to -3.73 dBm) but not enough to explain what I'm seeing.
>
> The big question I have is: What does "30 Seconds" mean for an attribute
> that by description of the docs is supposed to be number of PCS blocks with
> invalid Sync headers?
> Particularly when the guy on the Cisco at the other end says his error
> counters are going up like crazy (and packets are being dropped) while the
> stats my end stays constant at "30 Seconds".
> What does that mean?
>
> The particularly frustrating thing is that data streams are dropping packets
> (EG iperf3 showing retries and seriously degraded performance) but none of
> the interface stats are showing any values that indicate an issue other than
> that "30 Seconds".
>
> Can anybody tell me what "30 Seconds" means (in the context of an error
> counter)?
>
>
>
>
> On Fri, 21 Oct 2016, Christopher Costa wrote:
>
>> Here's my notes from a jtac review about these a couple years ago:
>>
>>
>>
>> [pcs] encoding is continually transmitting to keep the line in sync. The
>> PCS layer is directly below the MAC layer so for MX,
>> it’s on the MIC. PCS errors can be caused by anything MIC or lower, i.e.
>> transceiver, fiber, line equipment, etc.
>>
>>
>>
>>  PCS functionality:
>>  ===
>>  IEEE 802.3ae 10GbE interfaces use a 64B/66B encoder/decoder in the
>> PHY-PCS (Physical Coding Sub layer) to allow reasonable
>> clock recovery and facilitate alignment of the data stream at the
>> receiver.
>>  As the scheme name suggests, 64 bits of data on the MAC layer are
>> transmitted as a 66-bit code block on the PHY layer, which
>> realizes easier clock/timing synchronization. A 66-bit code block contains
>> a 2-bit Sync. Header + 8 octets data/control field.
>>   If the Sync. header is '01', the 8 octets are entirely data.
>>  If the Sync. header is '10', an 8-bit Type field follows, plus 56 bits of
>> data/control field.
>>   The 8 octets data/control field is scrambled by using a self-synchronous
>> scrambler to achieve complete DC-balance on the
>> serial line.
>>  PCS statistics displays PCS fault conditions by checking valid Sync.
>> headers received with every 66 bits interval, so that we
>> can monitor 10Gbps high speed transmission line quality.
>>   If the 64B/66B receiver does not detect the 2-bit Sync.
>>  Header with regular 66-bit interval and it estimates the high BER (Bit
>> Error Rate of >10^-4), PCS statistics will report a
>> problem.
>>   PCS statistics :
>>  
>>  - "Bit errors" indicates the number of PCS blocks with invalid Sync
>> headers.
>>  - "Errored blocks" indicates the number of PCS blocks with a valid Sync.
>> header but invalid block format.
>>
>>
>> On Fri, Oct 21, 2016 at 9:37 AM, Michael Carey  wrote:
>>   David,
>>
>>   When I've seen PCS statistical errors before, it pointed to either a
>>   failing optic that needed replaced in our MX or a drastic change in
>> optical

Re: [j-nsp] need HELP black holing a /32 via BGP community.

[Michael Loftis]

On Thu, Sep 15, 2016 at 10:10 AM, Matthew Crocker
 wrote:
>
>
> Route table inet.0  has
>
>
> A.B.C.D/32 *[Static/5] 00:27:29
>   Discard
>
>
> run show route advertising-protocol bgphas
> • A.B.C.D/32  SelfI
>
>
>
> How can I check the community on the outgoing announcements?
>
>
>
> I think it is working, just need to verify and add all my other upstreams
>
> Thanks

sh ro adv bgp  detail  (also see extensive etc)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] need HELP black holing a /32 via BGP community.

[Michael Loftis]

On Thu, Sep 15, 2016 at 9:55 AM, Jared Mauch  wrote:
>
>> On Sep 15, 2016, at 12:53 PM, Matthew Crocker  
>> wrote:
>>
>> Am I on the right track?  What am I missing?
>
> Are you generating the route as a /32 as well?

Jared's exactly right, you'll need a static, or IGP or other route in
the RIB so that BGP sees that and tags it, but you're on the exact
right path IMO which is to say that's exactly how I do it.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] filter DNS Recursive MX5 Juniper

[Michael Loftis]

You're dropping all outside udp return traffic to y.y.y.1 - unless that
host uses an entirely different address for its recursion.

On Sunday, May 29, 2016,  wrote:

> dear good night,
>
> how to configure DNS recursive filter in my MX5 Juniper?
>
> IP DNS: Y.Y.Y.1
> authorized network: 10.0.0.0/8
>
> below is configuration, but does not work.
>
>
> set firewall family inet filter FILTER-DNS term 1 from source-address
> 10.0.0.0/8
> set firewall family inet filter FILTER-DNS term 1 from destination-address
> Y.Y.Y.1
> set firewall family inet filter FILTER-DNS term 1 from destination-port 53
> set firewall family inet filter FILTER-DNS term 1 from protocol udp
> set firewall family inet filter FILTER-DNS term 1 from protocol tcp
> set firewall family inet filter FILTER-DNS term 1 then accept
>
> set firewall family inet filter FILTER-DNS term 10 from tcp-established
> set firewall family inet filter FILTER-DNS term 10 from
> destination-address Y.Y.Y.1
> set firewall family inet filter FILTER-DNS term 10 then accept
>
> set firewall family inet filter FILTER-DNS term 40 from
> destination-address Y.Y.Y.1
> set firewall family inet filter FILTER-DNS term 40 then discard
>
> set firewall family inet filter FILTRO-DNS term 50 then accept
>
> by google translator.
>
> thank you for attention.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full routes on MX5

[Michael Loftis]

On Tue, May 10, 2016 at 1:12 PM, Adam Vitkovsky <adam.vitkov...@gamma.co.uk>
wrote:

> > Michael Loftis
> > Sent: Wednesday, April 27, 2016 6:48 PM
> > To: Matthew Crocker
> > Cc: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] Full routes on MX5
> >
> > You'll definitely be a lot happier with the bigger RE's...usually my
> > convergence time at $dayJob is generally 3 minutes or less, with the less
> > often depending on how fast we get routes form the other guy when a
> > transit flaps.  Cold starts are a little ugly-ish with the number of
> full tables we
> > take in but still ~5 minutes usually once booted...that RARELY happens
> > though, esp now w/ 14.2's ISSU on MPCs...  This is on an MX960 w/ MPC's
> --
> > DPCs actually slowed the RIB->FIB process down I don't remember exact
> > timings sorry -- 14.2 train as well which makes huge differences if
> you're
> > using flow, and that definitely slows things down.
> >
> So do I understand it right that your experience is that 14.2 further
> slows down the RIB to FIB convergence as I'd assume the opposite?
>

No, sorry, you've misunderstood.  It's no better, no worse with same
hardware.  DPCs are slower to get the RIB->FIB convergence, with MPCs we
generally have not noticed any RIB->FIB convergence WITHOUT flow sampling
on all supported releases.  WITH sampling prior to more recent revs we DID
see RIB->FIB issues with MPCs as well.

For our use cases in production (not using sampling in production on DPCs!)
it was DPCs causing occasionally slower RIB->FIB times for us.  Never
really had any serious issues like many have had but I put that down to
having not used sampling/flow until well after Juniper had taken
significant steps to address the sync issues as being the biggest reason.
 14.2 didn't seem to change the timings except in problematic cases in the
lab (flow sampling) but we didn't use flow sampling in production prior to
14.2 at all so I can't speak from any real experience there.


>
> Also I'd like to ask if you've considered using hierarchical FIB as a
> workaround for the slow RIB to FIB convergence?
>

In our case except in testing with flow prior to 14.2 (unsure which
revision), and with a cold start we've not really observed issues with
RIB->FIB convergence in our use cases after upgrading to MPC3E's and
later.  With the prior generation setup using DPCs there were occasionally
some significant RIB->FIB sync problems but in all cases I recall it
settled within a couple minutes.


In general when I'm speaking of convergence I mean the whole thing end to
end.  Which means you're also at the mercy of your peers because if they're
not sending routes as fast as you can process them, you'll get slowed
down.  If your hardware at any point has a bottleneck you'll get slowed
down.  I'm generally NOT discussing the RIB->FIB step alone.

-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full routes on MX5

[Michael Loftis]

You'll definitely be a lot happier with the bigger RE's...usually my
convergence time at $dayJob is generally 3 minutes or less, with the less
often depending on how fast we get routes form the other guy when a transit
flaps.  Cold starts are a little ugly-ish with the number of full tables we
take in but still ~5 minutes usually once booted...that RARELY happens
though, esp now w/ 14.2's ISSU on MPCs...  This is on an MX960 w/ MPC's --
DPCs actually slowed the RIB->FIB process down I don't remember exact
timings sorry -- 14.2 train as well which makes huge differences if you're
using flow, and that definitely slows things down.

dfz.inet.0: 585059 destinations, 4046049 routes (585049 active, 0 holddown,
7770 hidden)
 ...
 BGP: 4045889 routes, 584900 active
...

Routing Engine status:
  Slot 0:
Current state  Master
Election priority  Master (default)
Temperature 32 degrees C / 89 degrees F
CPU temperature 32 degrees C / 89 degrees F
DRAM  16349 MB (16384 MB installed)
Memory utilization  21 percent
CPU utilization:
  User   1 percent
  Background 0 percent
  Kernel 4 percent
  Interrupt  2 percent
  Idle  93 percent
Model  RE-S-1800x4
Serial ID  ...
Start time ...
Uptime ...
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute   5 minute  15 minute
   0.01   0.08   0.07


On Wed, Apr 27, 2016 at 5:57 AM, Matthew Crocker 
wrote:

>
> I’m basically the same:   I have MX480s with 64G REs on order
>
> Convergence time is horrific (10 minutes) but luckily stable sessions keep
> that from happening often.
>
> MX80-1SUMMER> show bgp summary
> Groups: 10 Peers: 15 Down peers: 2
> Table  Tot Paths  Act Paths SuppressedHistory Damp State
> Pending
> inet.0
>  1766527 600191  0  0  0
> 0
> inet6.0
>26952  13477  0  0  0
> 0
>
>
> MX80-1SUMMER> show chassis routing-engine
> Routing Engine status:
> Temperature 39 degrees C / 102 degrees F
> CPU temperature 51 degrees C / 123 degrees F
> DRAM  2048 MB (2048 MB installed)
> Memory utilization  89 percent
> CPU utilization:
>   User   2 percent
>   Background 5 percent
>   Kernel13 percent
>   Interrupt  1 percent
>   Idle  79 percent
> Model  RE-MX80
> Serial ID  S/N ABBM2981
> Start time 2015-04-08 17:41:16 UTC
> Uptime 384 days, 19 hours, 7 minutes, 46
> seconds
> Last reboot reason Router rebooted after a normal shutdown.
> Load averages: 1 minute   5 minute  15 minute
>0.12   0.24   0.20
>
>
> MX80-1SUMMER> show route summary
> Autonomous system number:
> Router ID:
>
> inet.0: 600648 destinations, 176 routes (600638 active, 10 holddown, 0
> hidden)
> Restart Complete
>   Direct:  7 routes,  7 active
>Local:  6 routes,  6 active
> OSPF:506 routes,502 active
>  BGP: 1766144 routes, 600120 active
>   Static:  1 routes,  1 active
>  LDP:  2 routes,  2 active
>
> show system memory
> System memory usage distribution:
>Total memory: 2072576 Kbytes (100%)
> Reserved memory:   36896 Kbytes (  1%)
>Wired memory:  294748 Kbytes ( 14%)
>   Active memory: 1390992 Kbytes ( 67%)
> Inactive memory:  122924 Kbytes (  5%)
>Cache memory:  143348 Kbytes (  6%)
> Free memory:   82920 Kbytes (  4%)
>
>
>
> —
>
> Matthew Crocker
> President - Crocker Communications, Inc.
> Managing Partner - Crocker Telecommunications, LLC
> E: matt...@corp.crocker.com
> E: matt...@crocker.com
>
>
> > On Apr 26, 2016, at 3:26 PM, Eduardo Schoedler 
> wrote:
> >
> > Hi Colton,
> >
> > Yes, it's very high but it's working ok :)
> > 3 full tables (~580k each) + 4x IXP route-server (~60k each) + 1
> > peering with HE (81k).
> >
> > Indeed, convergence it's terrible... for my luck, these sessions are
> > pretty stable.
> >
> > --
> > Eduardo Schoedler
> >
> >
> > 2016-04-26 15:46 GMT-03:00 Colton Conor :
> >> Eduardo,
> >>
> >> So if I am reading that right, the box is using 96 percent of its
> memory? It
> >> looks like it has 2 

Re: [j-nsp] MPC-3D-16XGE-SFPP at 1G speed

[Michael Loftis]

Yeah those are specifically NOT 1/10, just 10G.  In general with the big
MXes the MICs won't do 1/10.  For 1G you need like MIC-3D-20GE-SFP on an
MPC or like the DPCE-*-40GE-SFP or similar-ish.  It might be cheaper to
just use a cheap EX3300 or EX4300 w/ 2x10 (for redundancy) to the MX if
you've a fair amount of 1G that you're connecting...or really...if you're
connecting 1G at all to the MX rather than burning a slot (MIC slot or
router slot) on 1G interfaces.

I actually can't think of ANY line card nor MIC for MX that does 1/10...

On Tue, Apr 26, 2016 at 12:23 PM, Dave Peters - Terabit Systems <
d...@terabitsystems.com> wrote:

> Hi all--
>
> Stupid question, here. Can the MPC-3D-16XGE-SFPP run with 1G optics (e.g.
> EX-SFP-1GE-SX), and if so, is there a specific port setting I need to
> commit? I'm running an MX480 with 13.3R8.7, and Uncle Google hasn't been
> too useful, yet.
>
> I tried:
>
> set interfaces xe-0/0/0 auto-negotiate
>
> inserted the EX-SFP-1GE-SX connected to an outside 1G port, no lights, no
> joy.
>
> Any help is appreciated.
>
> Thanks much.
>
> --Dave Peters
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full routes on MX5

[Michael Loftis]

Convergence time only becomes a factor when you're not taking just a
default route.  Thats one route.  When we speak of this we mean the time it
takes the RE to process the hundreds of thousands of routes in the IPv4 DFZ
and completely finish synchronizing RIB and FIB.

On Tue, Apr 26, 2016 at 11:08 AM, Dovid Bender  wrote:

> I assume that means that if a peer drops out of sight then for two minutes
> some of the traffic will drop? As of now we use default routes. If a bgp
> session drops the traffic shifts over fairly fast (under 30 seconds).
>
> Regards,
>
> Dovid
>
> -Original Message-
> From: "Tim St. Pierre" 
> Sender: "juniper-nsp" Date: Tue, 26
> Apr 2016 09:09:32
> To: 
> Subject: Re: [j-nsp] Full routes on MX5
>
> I have one in a very similar configuration, with three full feeds in
> IPv4 and IPv6.
>
> It generally works just fine, but convergence time is slow.  It can take
> two minutes to process the full feed, and if you restart the box, it
> will take even longer.
>
> It's a good machine for a small ISP though.
>
> -Tim
>
>
>
> On 2016-04-26 08:33 AM, sth...@nethelp.no wrote:
> >> Has anyone ever tried full IPv4 routes on a MX5? We have 3 peers +
> iBGP. We
> >> were told in the past that when a BGP session drops the MX5 could lock
> up
> >> for up to 2 minutes.
> > We have MX80s (essentially the same box) with full Internet routing
> > table. It works but is not recommended: RE memory (2 GB) is rather
> > limited, and convergence time is not great.
> >
> > Steinar Haug, Nethelp consulting, sth...@nethelp.no
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> --
> Tim St. Pierre
> System Operator
> Communicate Freely
> www.communicatefreely.net
> 289-225-1220 x5101
>
> ___
> 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
>



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 2x MS-MPC-128

[Michael Loftis]

On Fri, Feb 26, 2016 at 11:54 AM, Josh Reynolds  wrote:
> Further info:
>
> I just requested a restart of the FPC and for once it came online, but
> now I'm seeing the following:

The oinker there may be "normal" during bringup.  As for the power up,
check /var/log/chassisd
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 Power Options

[Michael Loftis]

On Tue, Jan 26, 2016 at 7:04 AM, Sebastian Wiesinger
 wrote:

> Hi Steinar,
>
> yes that's how I understood it but I was under the impression that I
> could use that to have redundancy for a single PEM as well. Seems I
> was mistaken. :)
>

Not really, no.  They need the dual inputs for the wattage.  4.1kW per
PEM.  If it loses an input it'll derate to half that.  They're
designed to be on the same feed, separate plugs.  Otherwise you end up
with special connectors for UL/IEC/NEBS which is a PITA.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 Power Options

[Michael Loftis]

On Tue, Jan 26, 2016 at 7:50 AM, Colton Conor  wrote:
> So from what I gather, there are 4 AC power supplies, and each AC power
> supply has two plugs. So thats not really going to change, its more what
> power to order from the datacenter.
>
> So can I get away with one A side 208V/ 30 AMP circuit and one B side
> 208V/30AMP circuit?
>
> 208V X 30AMP X .80 Max Load = 4,992 watts. That's a lot.
>
> Are you saying I ideally need double this? Why?

Depends on your configuration!  The new high capacity chassis' will
support up to ~8kW, redundant.  So it has ~16kW of PSU.  Base chassis,
one single idle MPC3E will use something like 2kW.  Take a look at
http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/calculating-power-requirements-mx960.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Is the M7i still an option for an ASBR ?

[Michael Loftis]

M7i and related platforms have an announced EOL - there's roughly 4yrs left
before they start ending support.


MSM requires CFEB-E. CFEB-E has a much faster onboard CPU, way more route
lookup memory. The CEB likely won't even hold a full IPv4 table anymore.
CFEB-E gets HQoS amongst other things with QoS and policers.

The M7i platform is extremely limited WRT jflow (called something else now
marketing wank speaky) without the ASM or MSM.  Even with the ASM - ISTR
the ASM basically doing either flow or other stuff (NAT/stateful firewall)
but not both and didn't work very well even 6 yrs ago due to insufficient
RAM.




On Monday, December 28, 2015, Jérôme Nicolle  wrote:

> Hi,
>
> I have to upgrade and expand a network currently routed by 2
> M7i-RE400-CFEB. It has two transit providers and filters out at /20
> because the RE-400 can't process a modern full-view.
>
> I've been told the RE-850 (RAM fully loaded) would be able to handle it.
> I found a few deals here and there, and some sellers also offer CFEB-E
> upgrades.
>
> I can't find any feedback on the practical differences between CFEB and
> CFEB-E.
>
> Here are my current questions :
> - Is a RE-850 really capable of handling 2 full views plus some peering
> sessions ?
> - What would I gain by upgrading CFEB to CFEB-E ? Is it required to
> handle 600k+ routes ?
>
> In addition, I'd like to use cflowd to monitor and balance this AS'
> traffic. I've read this features requires either the MSE-100 PIC or the
> multiservice module attached to the CFEB-E.
>
> - Doesn't the MSE-100 PIC requires the CFEB-E, as the multiservice
> module does ?
> - Is it realistic to handle 2 full views plus iBGP and a few peers WITH
> cflowd on a RE-850 ?
>
>
> Thanks !
>
> --
> Jérôme Nicolle
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions on management of dual-RE devices

[Michael Loftis]

On Wed, Nov 25, 2015 at 7:14 AM, Mike Williams  wrote:
> Thanks to all those who responded.
> master-only is mostly what I wanted!
>
>
> Rather confusingly, Juniper do specify setting lo0 per RE.
> https://www.juniper.net/techpubs/en_US/junos12.3/topics/task/configuration/routing-engine-dual-initial-configuration.html
> But then that document also tells you to run "commit synchronise" from 
> operational mode.
> A single loopback address works, and both REs have the same system SSH key, 
> so no warnings if they switch.
>

On the MX platforms (and the big hardware identical EXes) only the
master processes punted packets.  tcp/22 (subject to the ddos profiles
and firewall filters) gets punted when received on a hardware
interface to an lo0 address, there the master RE in the chassis gets
to process it.  Same path as BGP, OSPF, etc.  "master-only" is thus
only necessary (and applicable) to fxp interfaces.  You can't ssh to
an lo0 address and get a backup RE.  I believe VC EX and QFX behave
the same, pushing the inbound packets towards the VC master.

Hope that clears it up a little bit.

> This is broadly what I've got now.
>
> groups {
> re0 {
> system {
> host-name ...-re0;
> }
> interfaces {
> fxp0 {
> unit 0 {
> family inet {
> address 10.22.0.2/24 {
> master-only;
> }
> address 10.22.0.3/24;
> }
> }
> }
> }
> }
> re1 {
> system {
> host-name ...-re1;
> }
> interfaces {
> fxp0 {
> unit 0 {
> family inet {
> address 10.22.0.2/24 {
> master-only;
> }
> address 10.22.0.4/24;
> }
> }
> }
> }
> }
> }
> interfaces {
> lo0 {
> unit 0 {
> family inet {
> address 10.177.4.2/32;
> }
> }
> }
> }
>
>
> Thanks
>
> On Tuesday 24 November 2015 21:52:38 Olivier Benghozi wrote:
>> Juniper document provides each RE with it's own MANAGEMENT address (on fxp
>> port of each RE), not its own loopback. You configure a single loopback
>> (interface lo0.0).
>>
>> Anyway, about your need, there is:
>> http://www.juniper.net/documentation/en_US/junos15.1/topics/usage-guidelines
>> /interfaces-configuring-a-consistent-management-ip-address.html
>> > es/interfaces-configuring-a-consistent-management-ip-address.html>
>> > Le 24 nov. 2015 à 19:07, Mike Williams  a écrit
>> > :
>> >
>> > Hi all,
>> >
>> > So we just got our first Juniper devices with dual-REs (if you exclude
>> > virtual chassis').
>> > Before I get into actually configuring them, I'm wondering how others
>> > handle management, as I'm a touch confused.
>> >
>> > Normally we just SSH/snmp to the loopback address, optionally jumping off
>> > from a device on the same OoB network if routing is down (yes, we should
>> > configure a backup router).
>> >
>> > Juniper document providing each RE with it's own loopback address.
>> > If you do that, you'd have to detect if what you're connected to is master
>> > or backup, right?
>> > That might be a necessary trade off. As if you had a single loopback
>> > address, wouldn't the system SSH key change as loopback "moved" between
>> > the REs? Can a 'global' single loopback even be configured?
>> >
>> > Or do dual-RE devices actually work like virtual chassis, where the system
>> > SSH key is the same on all nodes, and connections to the backup are
>> > internally redirected to the master?
>
> --
> Mike Williams
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VC on a QFX5100 won't go away

[Michael Loftis]

Oh also... request virtual-chassis recycle member-id N for old member IDs

On Fri, Nov 13, 2015 at 10:08 AM, Michael Loftis <mlof...@wgops.com> wrote:
> It might be it's in split mode?  request virtual-chassis reactivate ?
> It's odd that it shows itself as a linecard but also master role.  The
> other thing you could do is maybe explicitly set it as a routing
> engine?  in config set virtual-chassis member 0 serial-number XXX role
> routing-engine
>
> Whatever is going on is just software having to do with it previously
> being in a line card role.
>
> On Fri, Nov 13, 2015 at 9:38 AM, Dave Peters - Terabit Systems
> <d...@terabitsystems.com> wrote:
>> That's another weird part. It's not connected to anything, and there's no 
>> vc-port recognized:
>>
>> root> show virtual-chassis
>>
>> Virtual Chassis ID: 1517.c443.48e0
>> Virtual Chassis Mode: Enabled
>> Mstr   Mixed Route 
>> Neigh
>> bor List
>> Member ID  Status   Serial NoModel  prio  Role  Mode  Mode 
>> ID  I
>> nterface
>> 0 (FPC 0)  PrsntTR0214440089 qfx5100-48c-6q 128   Master*  N  VC
>>
>> Member ID for next new member: 1 (FPC 1)
>>
>> {linecard:0}
>> root> show virtual-chassis vc-port
>> fpc0:
>> --
>>
>> {linecard:0}
>> root>
>>
>> I think I've got a lemon, here, but as always, I really appreciate 
>> everyone's input.
>>
>> Thanks much.
>>
>> --Dave Peters
>>
>> -Original Message-
>> From: Alexandre Guimaraes [mailto:alexandre.guimar...@ascenty.com]
>> Sent: Friday, November 13, 2015 8:22 AM
>> To: Dave Peters - Terabit Systems; juniper-nsp@puck.nether.net
>> Subject: RES: VC on a QFX5100 won't go away
>>
>>> show virtual-chassis
>>
>> Preprovisioned Virtual Chassis
>> Virtual Chassis ID: cf12.a99f.e63b
>> Virtual Chassis Mode: Enabled
>> Mstr   Mixed Route 
>> Neighbor List
>> Member ID  Status   Serial NoModel  prio  Role  Mode  Mode 
>> ID  Interface
>> 0 (FPC 0)  PrsntTA3714071234 qfx5100-48s-6q 129   Master*  N  VC   2 
>>  vcp-255/0/50
>>  
>> 1  vcp-255/0/51
>> 1 (FPC 1)  PrsntTA3714141234 qfx5100-48s-6q 129   Backup   N  VC   0 
>>  vcp-255/0/50
>>  
>> 2  vcp-255/0/51
>> 2 (FPC 2)  PrsntTA3714141234 qfx5100-48s-6q   0   Linecard N  VC   1 
>>  vcp-255/0/50
>>  
>>0  vcp-255/0/51
>>
>>
>> See vcp-255/0/51 ports:
>>
>>> show virtual-chassis vc-port
>> fpc0:
>> --
>> Interface   Type  Trunk  Status   SpeedNeighbor
>> or ID (mbps)   ID  Interface
>> PIC / Port
>> 0/50Configured -1Up   42   
>> vcp-255/0/51
>> 0/51Configured -1Up   41   
>> vcp-255/0/50
>>
>> fpc1:
>> --
>> Interface   Type  Trunk  Status   SpeedNeighbor
>> or ID (mbps)   ID  Interface
>> PIC / Port
>> 0/50Configured -1Up   40   
>> vcp-255/0/51
>> 0/51Configured -1Up   42   
>> vcp-255/0/50
>>
>> fpc2:
>> --
>> Interface   Type  Trunk  Status   SpeedNeighbor
>> or ID (mbps)   ID  Interface
>> PIC / Port
>> 0/50Configured -1Up   41   
>> vcp-255/0/51
>> 0/51Configured -1Up   40   
>> vcp-255/0/50
>>
>>
>> So:
>>
>> request virtual-chassis vc-port delete pic-slot X port Y member   Z
>>
>>
>>
>>
>>
>>
>>
>> -Mensagem original-
>> De: juniper-nsp

Re: [j-nsp] VC on a QFX5100 won't go away

[Michael Loftis]

It might be it's in split mode?  request virtual-chassis reactivate ?
It's odd that it shows itself as a linecard but also master role.  The
other thing you could do is maybe explicitly set it as a routing
engine?  in config set virtual-chassis member 0 serial-number XXX role
routing-engine

Whatever is going on is just software having to do with it previously
being in a line card role.

On Fri, Nov 13, 2015 at 9:38 AM, Dave Peters - Terabit Systems
 wrote:
> That's another weird part. It's not connected to anything, and there's no 
> vc-port recognized:
>
> root> show virtual-chassis
>
> Virtual Chassis ID: 1517.c443.48e0
> Virtual Chassis Mode: Enabled
> Mstr   Mixed Route 
> Neigh
> bor List
> Member ID  Status   Serial NoModel  prio  Role  Mode  Mode ID 
>  I
> nterface
> 0 (FPC 0)  PrsntTR0214440089 qfx5100-48c-6q 128   Master*  N  VC
>
> Member ID for next new member: 1 (FPC 1)
>
> {linecard:0}
> root> show virtual-chassis vc-port
> fpc0:
> --
>
> {linecard:0}
> root>
>
> I think I've got a lemon, here, but as always, I really appreciate everyone's 
> input.
>
> Thanks much.
>
> --Dave Peters
>
> -Original Message-
> From: Alexandre Guimaraes [mailto:alexandre.guimar...@ascenty.com]
> Sent: Friday, November 13, 2015 8:22 AM
> To: Dave Peters - Terabit Systems; juniper-nsp@puck.nether.net
> Subject: RES: VC on a QFX5100 won't go away
>
>> show virtual-chassis
>
> Preprovisioned Virtual Chassis
> Virtual Chassis ID: cf12.a99f.e63b
> Virtual Chassis Mode: Enabled
> Mstr   Mixed Route 
> Neighbor List
> Member ID  Status   Serial NoModel  prio  Role  Mode  Mode ID 
>  Interface
> 0 (FPC 0)  PrsntTA3714071234 qfx5100-48s-6q 129   Master*  N  VC   2  
> vcp-255/0/50
>   
>1  vcp-255/0/51
> 1 (FPC 1)  PrsntTA3714141234 qfx5100-48s-6q 129   Backup   N  VC   0  
> vcp-255/0/50
>   
>2  vcp-255/0/51
> 2 (FPC 2)  PrsntTA3714141234 qfx5100-48s-6q   0   Linecard N  VC   1  
> vcp-255/0/50
>   
>   0  vcp-255/0/51
>
>
> See vcp-255/0/51 ports:
>
>> show virtual-chassis vc-port
> fpc0:
> --
> Interface   Type  Trunk  Status   SpeedNeighbor
> or ID (mbps)   ID  Interface
> PIC / Port
> 0/50Configured -1Up   42   
> vcp-255/0/51
> 0/51Configured -1Up   41   
> vcp-255/0/50
>
> fpc1:
> --
> Interface   Type  Trunk  Status   SpeedNeighbor
> or ID (mbps)   ID  Interface
> PIC / Port
> 0/50Configured -1Up   40   
> vcp-255/0/51
> 0/51Configured -1Up   42   
> vcp-255/0/50
>
> fpc2:
> --
> Interface   Type  Trunk  Status   SpeedNeighbor
> or ID (mbps)   ID  Interface
> PIC / Port
> 0/50Configured -1Up   41   
> vcp-255/0/51
> 0/51Configured -1Up   40   
> vcp-255/0/50
>
>
> So:
>
> request virtual-chassis vc-port delete pic-slot X port Y member   Z
>
>
>
>
>
>
>
> -Mensagem original-
> De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de Dave 
> Peters - Terabit Systems Enviada em: quinta-feira, 12 de novembro de 2015 
> 18:05
> Para: juniper-nsp@puck.nether.net
> Assunto: [j-nsp] VC on a QFX5100 won't go away
>
> Hi all--
>
> I've been trying to remove the VC config from a QFX5100 running 13.2X51-D38, 
> and I'm not having any luck. I've tried zeroizing and going into the shell to 
> remove the files in the config/vchassis folder, but I'm having no luck.  
> Looking at the config, I'm seeing:
>
> root> show configuration
>
> 
> commit {
> factory-settings {
> reset-virtual-chassis-configuration;
> reset-chassis-lcd-menu;
> 
>
> root>
>
> Which isn't on a factory default system, but I can't seem to clear that 
> portion of the configuration, and I when I delete the .conf files from the 
> shell, the commit/factory-settings/reset-vc stuff pops up all over again.
>
> This is probably a really simple thing, but I'm not getting 

Re: [j-nsp] Routed VLAN Interfaces on MX

[Michael Loftis]

If you don't need to switch the subintf at all you can just do...
set int ae0 flexible-vlan-tagging
set int ae0 .
set int ae0 unit 41 vlan-id family inet 

instead of doing encap vlan-bridge on the unit 41 and all the other
related bridge-domain stuff


On Fri, Nov 13, 2015 at 1:12 PM, Josh Baird  wrote:
> Hi,
>
> I apologize for the basic question as I'm a new Junos user.  I'm attempting
> to convert the following basic config from a Cisco NPE-G1:
>
> interface GigabitEthernet0/3
>  desc 'Physical link to EX'
>
> interface GigabitEthernet0/3.41
>   encapsulation dot1q
>   ip address 1.1.1.2/30
>
> On the MX, I am trying to configure an agg between the MX and other device
> (EX), so this is the config that I have came up with:
>
> # interfaces
> ae0 {
> flexible-vlan-tagging;
> encapsulation flexible-ethernet-services;
> aggregated-ether-options {
> lacp {
> active;
> periodic fast;
> }
> }
> unit 41 {
> encapsulation vlan-bridge;
> vlan-id 41;
> }
> }
>
> # interfaces irb
> irb {
> unit 41 {
> family inet {
> address 1.1.1.2/30
> }
> }
> }
>
>
> # bridge-domain
> bridge-domains {
> vlan41 {
> vlan-id 41;
> interface ae0.41;
> routing-interface irb.41;
> }
> }
>
> Does this configuration look correct?  Is all of this necessary?  I realize
> there are several different ways to handle this in Junos.
>
> Thanks for any suggestions or input.
>
> Josh
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Routed VLAN Interfaces on MX

[Michael Loftis]

On Friday, November 13, 2015, Michael Loftis <mlof...@wgops.com> wrote:

> If you don't need to switch the subintf at all you can just do...
> set int ae0 flexible-vlan-tagging
> set int ae0 .
> set int ae0 unit 41 vlan-id family inet 
>
> instead of doing encap vlan-bridge on the unit 41 and all the other
> related bridge-domain stuff


Almost forgot! Be sure to check the L2 and L3 MTUswhen you turn on vlan
tagging. Most of the time JunOS will not help you out by correctly bumping
the L2 MTU like Cisco. Big trap. It kind of varies between EX and MX. I've
taken to just being explicit on all L2 and L3 MTUs.


>
>
> On Fri, Nov 13, 2015 at 1:12 PM, Josh Baird <joshba...@gmail.com
> <javascript:;>> wrote:
> > Hi,
> >
> > I apologize for the basic question as I'm a new Junos user.  I'm
> attempting
> > to convert the following basic config from a Cisco NPE-G1:
> >
> > interface GigabitEthernet0/3
> >  desc 'Physical link to EX'
> >
> > interface GigabitEthernet0/3.41
> >   encapsulation dot1q
> >   ip address 1.1.1.2/30
> >
> > On the MX, I am trying to configure an agg between the MX and other
> device
> > (EX), so this is the config that I have came up with:
> >
> > # interfaces
> > ae0 {
> > flexible-vlan-tagging;
> > encapsulation flexible-ethernet-services;
> > aggregated-ether-options {
> > lacp {
> > active;
> > periodic fast;
> > }
> > }
> > unit 41 {
> > encapsulation vlan-bridge;
> > vlan-id 41;
> > }
> > }
> >
> > # interfaces irb
> > irb {
> > unit 41 {
> > family inet {
> > address 1.1.1.2/30
> > }
> > }
> > }
> >
> >
> > # bridge-domain
> > bridge-domains {
> > vlan41 {
> > vlan-id 41;
> > interface ae0.41;
> > routing-interface irb.41;
> > }
> > }
> >
> > Does this configuration look correct?  Is all of this necessary?  I
> realize
> > there are several different ways to handle this in Junos.
> >
> > Thanks for any suggestions or input.
> >
> > Josh
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net <javascript:;>
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
>
> "Genius might be described as a supreme capacity for getting its possessors
> into trouble of all kinds."
> -- Samuel Butler
>


-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

[Michael Loftis]

It isn't 10G only. They support 10g/1g/100m but I don't know if they do tri
rate. And when you insert a 1G SFP it enumerates as ge-n/n/n not as xe- --
I have something like a dozen of these in production and a few 1G SFPs so
not just guessing here.

On Wednesday, November 4, 2015, Vincent Clement <vclement.m...@gmail.com>
wrote:

> Hello,
>
> Pretty sure QFX in 10G only, so if you want to achieve that, you'll have
> to use a uplink module to have 10G on 4300 side.
>
> Vincent
>
> 2015-11-04 2:23 GMT+01:00 Michael Loftis <mlof...@wgops.com
> <javascript:_e(%7B%7D,'cvml','mlof...@wgops.com');>>:
>
>> I'd take a closer look at show interfaces. When a link is 1gig QFX calls
>> it
>> ge-. So you can have an ex-0/0/1 and a ge-0/0/1 but only one is active as
>> I
>> do not believe tri rate SFP+ is supported.
>>
>> On Tuesday, November 3, 2015, ThienDuc Nguyen <thienduc.ngu...@zayo.com
>> <javascript:_e(%7B%7D,'cvml','thienduc.ngu...@zayo.com');>>
>> wrote:
>>
>> > Hi
>> >
>> > I was trying to create a LACP bundle between two ports : one on a
>> EX4300,
>> > the other on a QFX5100.
>> > Both link have their speed negotiated at 1GE (but the interface name on
>> the
>> > QFX is xe-, I can't force it to ge-, and their are no way to force the
>> > speed on the QFX).
>> > if I set the lacp speed to 1ge, the configuration can't commit because
>> it
>> > sees the QFX interface as a 10G interface...
>> >
>> >
>> > Is their a special knob to activate it, or I need to create LACP on the
>> > same device family ?  (the version is  14.1X53-D30.3)
>> >
>> > Thanks,
>> >
>> > *Thien Duc Nguyen*
>> > ___
>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>> <javascript:_e(%7B%7D,'cvml','juniper-nsp@puck.nether.net');>
>> <javascript:;>
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>>
>>
>> --
>>
>> "Genius might be described as a supreme capacity for getting its
>> possessors
>> into trouble of all kinds."
>> -- Samuel Butler
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> <javascript:_e(%7B%7D,'cvml','juniper-nsp@puck.nether.net');>
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
>
> --
> Vincent Clément
> +33 6 74 49 66 30
>


-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

[Michael Loftis]

I'd take a closer look at show interfaces. When a link is 1gig QFX calls it
ge-. So you can have an ex-0/0/1 and a ge-0/0/1 but only one is active as I
do not believe tri rate SFP+ is supported.

On Tuesday, November 3, 2015, ThienDuc Nguyen 
wrote:

> Hi
>
> I was trying to create a LACP bundle between two ports : one on a EX4300,
> the other on a QFX5100.
> Both link have their speed negotiated at 1GE (but the interface name on the
> QFX is xe-, I can't force it to ge-, and their are no way to force the
> speed on the QFX).
> if I set the lacp speed to 1ge, the configuration can't commit because it
> sees the QFX interface as a 10G interface...
>
>
> Is their a special knob to activate it, or I need to create LACP on the
> same device family ?  (the version is  14.1X53-D30.3)
>
> Thanks,
>
> *Thien Duc Nguyen*
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] authentication failure in case of configuration archival over scp

[Michael Loftis]

keyboard-interactive vs. password authentication.  They may "feel" the
same but they're not.  I'd check which is going on, and maybe try
configuring the server for the other.

On Mon, Oct 26, 2015 at 4:12 PM, Martin T  wrote:
> Stacy,
>
> I configured SSH server(OpenSSH) to log both the user name and
> password for all the successful and unsuccessful authorization
> attempts and turned out, that Juniper router sends an empty string as
> a password. I guess Junos uses FreeBSD scp utility for configuration
> archival if following configuration is used:
>
> configuration {
> transfer-on-commit;
> archive-sites {
> "scp://juniper@backupserver:/home/juniper/configbackups"
> password "$9$2joDkf5F9tOik0IhcMWGDjq5Q"; ## SECRET-DATA
> }
> }
>
>
> If yes, then Junos probably provides an empty password string to scp.
> Underlying XML also holds the correct obfuscated password, i.e. as far
> as I can tell, the password in configuration is correct. I also tried
> with other passwords, but the router still sends an empty string. How
> to troubleshoot this further? Has anyone seen such behavior(possibly a
> bug) before?
>
>
> thanks,
> Martin
>
> On Wed, Oct 21, 2015 at 7:39 PM, Stacy W. Smith  wrote:
>>
>>> On Oct 21, 2015, at 10:16 AM, Martin T  wrote:
>>>
>>> SSH server log tells that "error: PAM: Authentication failure for juniper 
>>> from r1".
>>
>>> What might cause this?
>>
>> Assuming the Junos version has not changed on the router, have there been 
>> any changes to the SSH server, or the OS, on backupserver (potentially 
>> including "security patches")?
>>
>> Assuming OpenSSH, you may want to "man sshd_config" and look into the 
>> various Authentication settings as well as the UsePAM. I suspect 
>> some recent upgrade may have changed the default value of some of these 
>> settings.
>>
>> I would normally suggest changing the client's config to interoperate with 
>> the server, but since that's not easy to do on a Junos device, you might 
>> look at changing the server config.
>>
>> --Stacy
>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LACP

[Michael Loftis]

You do not want to do LACP (or any ae)  over dissimilar links.  You
will be on a trail of tears of poor performance and wonky behavior.
LACP/ae is NOT designed for dissimilar links.

On Wed, Oct 14, 2015 at 8:15 AM, David Samaniego  wrote:
> Hi all. I need to create an LACP between two ex3300-24t. This can be
> done if one
> of the links transport provider allows me only 802.1Q and the other only
> 802.1ad.
> It might be possible to configure the LACP?
>
> I appreciate any insight that can be provided.
>
> Thank you,
> David
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understand the DRAM usage on CFEB(FEB-M10i-M7i-S)

[Michael Loftis]

It's not quite the FIB, it's a representation of it (J-Tree) for
lookups.  I don't recall much of the specifics past that on the
FEB/CFEB of the M7i/M10i because there's the other memories involved
too and I can't recall how they're used.  But yes the microkernel is
given a digest of the FIB as a j-tree which it keeps a copy of.

On Thu, Oct 1, 2015 at 5:51 AM, Martin T <m4rtn...@gmail.com> wrote:
> One last question- am I correct that copy of FIB is kept on this
> microkernel SDRAM? I mean there seems to be a clear correlation
> between amount of routes in router and CFEB microkernel memory
> utilization. The reason I assume this is because if I upgrade the
> SDRAM SODIMM on CFEB(i.e. upgrade the memory for microkernel), then
> total amount of "heap" memory on CFEB increases and if router has more
> routes, then the usage of "heap" memory increases.
>
>
> thanks,
> Martin
>
> On 9/30/15, Martin T <m4rtn...@gmail.com> wrote:
>> Ok, thanks! I had never seen a solution where parity information is
>> stored in additional individual SDRAM chips. So in conclusion 128MiB
>> of on-board SDRAM is used for packet memory, 64MiB of on-board SDRAM
>> is used for packet memory parity information and replaceable DDR SDRAM
>> SODIMM is used solely for the PFE microkernel.
>>
>>
>> regards,
>> Martin
>>
>> On 9/29/15, Michael Loftis <mlof...@wgops.com> wrote:
>>> The "extra" SDRAM chips.  The packet memory has parity or ECC bits, I
>>> actually do not recall for sure which, but the "extra" is for those
>>> extra bits.
>>>
>>> On Tue, Sep 29, 2015 at 12:45 PM, Martin T <m4rtn...@gmail.com> wrote:
>>>> What do you mean?
>>>>
>>>>
>>>> thanks,
>>>> Martin
>>>>
>>>> On Tue, Sep 29, 2015 at 8:45 PM, Michael Loftis <mlof...@wgops.com>
>>>> wrote:
>>>>> Parity/ECC.
>>>>>
>>>>> On Tue, Sep 29, 2015 at 7:32 AM, Martin T <m4rtn...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> according to Juniper M10i Compact Forwarding Engine
>>>>>> Board(http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/cfeb-m10i-description.html)
>>>>>> documentation it has 128 MiB SDRAM for packet memory and 128 MiB SDRAM
>>>>>> for the microkernel. If I visually inspect the CFEB, then it has
>>>>>> twelve "MT 46V8M16" DDR SDRAM chips which means 12x 134217728 bits,
>>>>>> i.e. 192MiB of on-board soldered DDR SDRAM. Questions:
>>>>>>
>>>>>> 1) Are four "MT 46V8M16" DDR SDRAM chips actually not in use? If they
>>>>>> are in use, then what for?
>>>>>>
>>>>>> 2) Am I correct that on-board soldered DRAM is used for shared packet
>>>>>> buffer and installable DDR SDRAM SODIMM is used for the microkernel?
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> Martin
>>>>>> ___
>>>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> "Genius might be described as a supreme capacity for getting its
>>>>> possessors
>>>>> into trouble of all kinds."
>>>>> -- Samuel Butler
>>>
>>>
>>>
>>> --
>>>
>>> "Genius might be described as a supreme capacity for getting its
>>> possessors
>>> into trouble of all kinds."
>>> -- Samuel Butler
>>>
>>



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understand the DRAM usage on CFEB(FEB-M10i-M7i-S)

[Michael Loftis]

The "extra" SDRAM chips.  The packet memory has parity or ECC bits, I
actually do not recall for sure which, but the "extra" is for those
extra bits.

On Tue, Sep 29, 2015 at 12:45 PM, Martin T <m4rtn...@gmail.com> wrote:
> What do you mean?
>
>
> thanks,
> Martin
>
> On Tue, Sep 29, 2015 at 8:45 PM, Michael Loftis <mlof...@wgops.com> wrote:
>> Parity/ECC.
>>
>> On Tue, Sep 29, 2015 at 7:32 AM, Martin T <m4rtn...@gmail.com> wrote:
>>> Hi,
>>>
>>> according to Juniper M10i Compact Forwarding Engine
>>> Board(http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/cfeb-m10i-description.html)
>>> documentation it has 128 MiB SDRAM for packet memory and 128 MiB SDRAM
>>> for the microkernel. If I visually inspect the CFEB, then it has
>>> twelve "MT 46V8M16" DDR SDRAM chips which means 12x 134217728 bits,
>>> i.e. 192MiB of on-board soldered DDR SDRAM. Questions:
>>>
>>> 1) Are four "MT 46V8M16" DDR SDRAM chips actually not in use? If they
>>> are in use, then what for?
>>>
>>> 2) Am I correct that on-board soldered DRAM is used for shared packet
>>> buffer and installable DDR SDRAM SODIMM is used for the microkernel?
>>>
>>>
>>> thanks,
>>> Martin
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>> --
>>
>> "Genius might be described as a supreme capacity for getting its possessors
>> into trouble of all kinds."
>> -- Samuel Butler



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cheaper way to have 2x100G and 16x10G wire-speed in MX480

[Michael Loftis]

Depending on your chassis you may be able to upgrade to SCBE2 - but
that requires *all* MPC cards AND requires a newer style backplane
(part number is escaping me at the moment) and of course with the MPC4
will require high capacity fans.  Assuming you meet all of those
hardware prereqs MPC4 based cards can hit that.  SCBE is 160G/slot,
SCBE2 is 360G/slot.

But cheap, and 100G or cheap and 40G and full scale routingthey're
kind of mutually exclusive right now.  The PTX platform may have
better price points for this role too.  I suggest you talk to your
Juniper sales rep.

On Sat, Sep 26, 2015 at 5:41 AM, Robert Hass  wrote:
> Hi
> What is cheapest way to choose proper MPC/MICs to have 2x100G and 16x10G
> all wire-speed plus possibility to extend my configuration to total 32x10G
> and 4x100G ?
>
> Is it possible to have 200Gbps (400G in both directions) per slot in cast
> of malfunction of one fabric card ?
>
> What you can suggest ?
>
> Rob
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper branded Sumitomo Optics

[Michael Loftis]

They both are. -Inf just means it's below the RX detectable level. Ambient
light can hit the RX and get you some light level measurement even when not
connected to a TX. If you've a black solid plug covering the optic and
still getting -20dBm that's kind of odd though.

On Thursday, September 17, 2015, Bill Blackford 
wrote:

> I'm seeing an inconsistent behavior. I have two Juniper branded XFP (LR)
> made by Sumitomo inserted into a chassis, but are not configured nor
> connected. Looking at the light levels, I see
>
> Laser rx power 0.0098 mW / -20.09 dBm and similar for the
> other.
>
> Now, other optics I have in the same chassis, also not configured nor
> connected, show
>
> Laser rx power 0. mW / -Inf dBm
>
> I would suspect the second behavior (that of the non-Sumitomo's) should be
> correct, expected.
>
> My question is, which of these behaviors is correct and does it matter?
>
> Thank you,
>
>
> --
> Bill Blackford
>
> Logged into reality and abusing my sudo privileges.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX240 MX480 and MX960 Power Consumption

[Michael Loftis]

The fans are variable speed too.  So if your env isn't pushing (cards
aren't heating up) the actual load from the fans will be a lot lower
on the MX960.

An idle unpopulated MX960 (3xSCB, 2xRE, no line cards) uses about
900W.  I'd still budget it at the 1425/1500W number though for a base
chassis.

On Fri, Aug 21, 2015 at 6:40 AM, Jerry Jones jjo...@danrj.com wrote:
 Components in the MX240/480 are all identical. The 480 just has physically 
 larger chassis and 2 more power supplies.

 If these are in a controlled environment and do not require NEBS, ie temp 
 will NOT exceed 40c, then use a recent version of code and use the new power 
 knobs to get the most power savings. Using cards like the NG MPC can really 
 save power


 On Aug 21, 2015, at 8:28 AM, Colton Conor colton.co...@gmail.com wrote:

 We are evaluating the three Juniper platforms, and trying to understand the
 power consumption differences between the 3. Space is not really an issue,
 but overall power consumption is.

 So if all three have the following cards in the, how much difference will
 there be in power consumption between the three chassis? I assume the only
 differences will the the fan trays, and that the MX960 supports a 3rd SCB
 that will more than likely be populated?

 Does Juniper have an excel worksheet?
 ___
 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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX240 SCBE2 10G ports

[Michael Loftis]

On Wed, Aug 19, 2015 at 9:09 AM, Chuck Anderson c...@wpi.edu wrote:
 On Wed, Aug 19, 2015 at 11:43:43AM -0400, Phil Rosenthal wrote:
 I suggest you bring this up with your Juniper sales rep :)

 Juniper is very much driven by customer feedback.

 I wonder if these ports are connected to a PFE, or if they are
 direct-to-RE ports.  If the latter, they may never be usable as
 revenue ports but they might make it easier for Juniper to implement
 external routing engines or distributed/clustering technologies like
 the TX Matrix Plus with the Line Card Chassis.  This is just a guess.

I personally would actually bet that's what it was/is for.  Linking
the chassis internal network that carries the management.  It's
probably hanging off the management switching system on the fabric
cards, not on the fabric itself.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Looking for paid config - source/port NAT?

[Michael Loftis]

You can do a transparent proxy type setup. Using the firewall filter syntax
to change the next hop to a properly configured Linux, FreeBSD, or whatever
host.

On Wednesday, August 5, 2015, Markus unive...@truemetal.org wrote:

 Hi list,

 I'm looking for someone to create the following config on an M7i with
 12.3R2.5 for me:

 Several source addresses on the LAN should not be able to contact port 25
 on the internet, but instead all these connections should be relayed
 through an external mail relay.

 I can't seem to figure it out by myself. Not sure if I even need NAT or
 not.

 Anyone available to do this paid  rather quickly? Please contact me
 off-list.

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] iSCSI, fast write, slow read

[Michael Loftis]

I've fought a similar issue.  You'll want to check for MAC Pause
Frames (show int blah extensive, and whatever your OS might have,
maybe ethtool) - the drops themselves also get accounted for usually
in the QoS section on the EX and QFX, often on the ingress port and
NOT the egress port (as they drop on a full buffer for the egress)

It is VERY possible you're running into buffering issues on the
EX3300.  Any MAC pause frames received on the downstream ports can
very negatively effect upstream ports and cause drops further upstream
even to unrelated ports as the buffers fill.

On Fri, Jul 10, 2015 at 7:26 AM, Mike Williams mike.willi...@comodo.com wrote:
 Hey all,

 Firstly, this could very much possibly not be related to any Juniper 
 equipment at all. If so, I apologise in advance.



 So.
 iSCSI.
 4 servers.
 Target has a 10Gbps Mellanox Connect-X3 Pro.
 Three initiators have 1Gbps I350s.

 Writing data, and only writing data, to all 3 initiators runs at ~2.5Gbps.
 Exactly what I'd hope would happen.

 However, reading data is pegged to ~1Gbps.
 In fact, any reading of data at all pegs the throughput at ~1Gbps.
 100Mbps reading, 900Mbps writing. 500Mbps reading, 500Mbps writing.

 Not sure if this attachment will make it through, but attached is a graph 
 illustrating.
 Before 11:20 was a bonnie++ run reading and writing at the same time.
 After that was ~80 minutes of pure writing.
 Finally pure reading.


 In the middle is an EX3300.

 Hardware inventory:
 Item Version  Part number  Serial number Description
 Chassisx  EX3300-48T
 Routing Engine 0 REV 14   750-034247   x  EX3300 48-Port
 FPC 0REV 14   750-034247   x  EX3300 48-Port
   CPU BUILTIN  BUILTIN   FPC CPU
   PIC 0   BUILTIN  BUILTIN   48x 10/100/1000 
 Base-T
   PIC 1  REV 14   750-034247   x  4x GE/XE SFP+
 Xcvr 0   REV 01   740-021308   x   SFP+-10G-SR
 Xcvr 1   REV 01   740-021308   x   SFP+-10G-SR
 Power Supply 0   PS 100W AC
 Fan Tray Fan Tray

 Physical interface: xe-0/1/0
 Laser bias current:  7.904 mA
 Laser output power:  0.5820 mW / -2.35 dBm
 Module temperature:  41 degrees C / 106 degrees F
 Module voltage:  3.3420 V
 Receiver signal average optical power :  0.1781 mW / -7.49 dBm


 Juniper branded optics both ends, single-mode fiber connecting them.

 It has almost entirely no config at all.
 12.3R6.6, and a 9216 MTU configured on all ports as the only config change.


 Now, the reason I'm writing here is I suspect the EX.

 Reading across a back-to-back 10Gbps connection (same Connect-X3 Pros) goes 
 at the sort of lick you'd expect for a disk subsystem that can sustain 2Gbps 
 of writes.


 Am I seeing some sort of buffering issue? When a 10Gbps machine sends traffic 
 to 1Gbps machines.
 Or maybe a physical limitation of the 3300?


 Closest thing I could find was a discussion about Cisco switches.
 https://supportforums.cisco.com/discussion/12483511/performance-issue-10gbs-1gbs-6880-x6800-ia-1521sy0a
 I don't see any drops logged, and don't understand Cisco config.


 Thanks for any advice!

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP behaviour with Juniper router

[Michael Loftis]

I think you're referring to update-groups.  You can show existing
groupings with show bgp group, and JunOS automatically manages all of
these.  You can (and should probably) still create your own groups to
manage common configuration elements for groups of peers though.
JunOS does NOT automatically imply any delay.  If you need to delay
announcements for any reason you use the out-delay parameter.  IOS
does this because Cisco refused to put a decent CPU in anything for
decades longer than they should have.  Juniper only recently got a few
BGP edge routers that are CPU anemic-ish (the MX80/MX104 lineup) but
even they're beefier than most comparable Cisco kit.  Because of this
you don't need to micro manage update groups like you might need to in
Cisco, there's generally plenty of RE CPU to go around for the most
part in Juniper land.

Anyway.  out-delay can be set within a neighbor, a group, or at
the root of protocols bgp hierarchy.  It controls how long a route
must be present before it is propogated to the relevant peers, it does
not just flat out delay announcements.  It just ensures a route has a
minimum age before being propagated.

http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/out-delay-edit-protocols-bgp.html



On Wed, Jun 3, 2015 at 5:39 AM, Eng. Bahaa via juniper-nsp
juniper-nsp@puck.nether.net wrote:
 Hi Guys,I am new with this group and with Juniper products as well.I curious 
 to know the behaviour of BGP routing with Juniper routers.With Cisco router, 
 a BGP speaker deals by default with all external peers as one group and with 
 internal peers as another group.With external peers,it starts a timer of 30 
 seconds after each announce or forwarded update/updates to other neighbors 
 while it send it directly with 0 seconds to internal peers (on the same 
 AS).My question is Juniper routers work in the same behaviour?I really 
 appreciate if someone has configured BGP in Juniper router and send me the 
 o/p of show ip bgp update-groups (this a cisco command not really sure how it 
 looks like in Juniper).

 Regards
 Bahaa


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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JTAC Recommended Junos Software Versions Old?

[Michael Loftis]

On Wed, Apr 29, 2015 at 9:58 AM, Colton Conor colton.co...@gmail.com wrote:
 Why is the JTAC Recommended Junos Software Version for the MX routers
 currently Junos 12.3R8.7? There are much newer versions of JUNOS out there.
 From the posts I have read so far, Junos 12.3 in general has flow and nat
 issues. I assume some of these bugs have been fixed with the latest .x
 versions like R8.7, but still why such an old version?

 Is there a guide showing the big changes from 12.3 vs 13.2 vs 13.3 vs 14.1
 vs 14.2. I know there a release notes for all of these versions, but is
 there an outline showing the reason for the jump in version numbers? Most
 of the PR's I have seen show a bug was found and fixed in the current .x of
 most all these versions.

Feature explorer.

http://pathfinder.juniper.net/feature-explorer/

The recco's have to do with overall stability etc  recco'd
releases tend to be bugfix stage releases rather than active
development.  That doesn't meant they get all bugfixes though.  And
they definitely lag behind point for even the associated Major.Minor
version, I'm sure by design.  There might be some official policy on
exactly how they advance or select the recco'd release for a given
platform but I'm not aware of it.


 I notice that the Juniper JTAC recommends Junos 13.3R4.6 for the MX104 and
 PTX series? If Junos 13.3R4.6 is stable enough to run on these platforms,
 then I assume its stable enough to run on the other MX platforms, the MX80
 to be specific?
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] IPv6 RE protection

[Michael Loftis]

On Saturday, April 25, 2015, Cydon Satyr cydonsa...@gmail.com wrote:

 Hello,
 Currently we don't use any IPv6 RE protect filters on our routers (6PE only
 in network). We do use IPv6 filters on public interfaces, however.
 Would you recommend deploying IPv6 RE filters on our edge routers at least.

 What kind of configuration you have in your network?

 Also, do you know if Juniper still only supports matching on one
 next-header?


Depends on your hardware. MPC can dig a bit more precisely but DPC is
limited (hardware)

http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/general/firewall-filter-match-conditions-for-ipv6-traffic.html





 Best Regards community
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5100 issues with IPv6 hashing

[Michael Loftis]

On Friday, April 17, 2015, Anton Yurchenko ayurche...@gmail.com wrote:

 Hi All,

 I am seeing issues with QFX5100, hashing of IPv6 traffic over ECMP paths
 is very bad.
 In my case I have an ECMP over 3x40Gig links, and sending 180x10Mbit UDPv6
 flows over them. First 40G gets ~300mbit, second ~600 and third ~900.
 IPv4 hashing is fine ~5% variance in traffic levels.

 I have enabled hashing on L3/L4 and layer2-payload but no avail.

 It seems that protocol/ports are not taken into account at all. If I start
 traffic from just one IP with 30 flows, they will all end up on a single
 link.


You say 30 flows but are they differing at all? Even for v6 it looks at
Source IP, Dest IP, Proto, Source port, Dest port. If you traffic generator
doesn't vary the source port then each flow will look identical to the
hash algo.



 Seeing this on 13.2X51-D35.3 and 14.1X53-D25.2 releases.

 Here is my hashing config:

 load-balance {
 indexed-load-balance;
 }
 hash-key {
 family inet {
 layer-3;
 layer-4;
 }
 }
 enhanced-hash-key {
 hash-mode {
 layer2-payload;
 }
 }

 Wondering if anybody have seen something similar or have seen it working
 properly.

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Activating FPC's on an EX8208

[Michael Loftis]

MX960 is different than MX480 and MX240  WRT the power requirements,
it also differs for high power stuff (All newer chassis) IIRC.  Two
zones, not one big zone, two 1+1 redundant zones,  PEM 0/2 and 1/3.

Zoning or no zoning depends on your *chassis* not your PSUs.

On Thu, Mar 5, 2015 at 7:30 AM, Tom Storey t...@snnap.net wrote:
 Interesting, Ive got a couple of MX960's with high line AC PEMs in front of
 me, and if I only turn one of them on, I only get half a router powered up.
 As far as I know, there is still zoning with high line AC PEMs.

 PEM0 and PEM2 supply one half of the router (slots 0-5 and RE0 and one fan
 tray), and PEM1 and PEM3 the other half (RE1 and slots 6-11 and the other
 fan tray) - as I understand it.

 So we do PEM0 and PEM1 as A feeds and PEM2 and PEM3 as B feeds, therefore
 if you lose A or B the router keeps running with all slots.

 So 2 may be mandatory, but you have to do one for each zone.

 Smaller boxes like MX240 we can power entirely with a single PEM.

 On 5 March 2015 at 13:01, Kevin Wormington kw...@sofnet.com wrote:

 That's right the power zones are only for DC power.  AC has only one zone,
 but according to the link below 2 high line AC supplies are mandatory and 3
 low-line.  I guess it might come up on a single high line depending on what
 line cards you have.

 http://www.juniper.net/documentation/en_US/release-
 independent/junos/topics/reference/specifications/calculating-power-
 requirements-mx480.html


 On 03/05/2015 12:48 AM, Mark Tinka wrote:



 On 4/Mar/15 18:21, Kevin Wormington wrote:

 I don't have any experience the the large EXs, but is there a chance
 you don't have enough power to the chassis to bring the line cards
 online? I know the larger MXs require a certain number of supplies and
 IIRC certain supplies power certain slots.  So if you just have one
 supply plugged into 120VAC it may not bring the line cards online.


 For the MX routers, I think this is only if you run DC or the AC low
 power units (i.e., 120VAC).

 IIRC, a single 240VAC PSU on an MX should be able to drive an entire MX
 chassis, non?

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MTU mismatch between EX4200 and EX4500 / OSPF3 adjacencies

[Michael Loftis]

I've learned to configure MTU explicitly everywhere in Juniper.  Too
many places where they're getting it wrong.  Setting vlan-tagging will
usually get the right setting but interface-mode or port-mode trunk
links can come up with wrong MTUs...

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

On Mon, Mar 2, 2015 at 9:56 AM, Chuck Anderson c...@wpi.edu wrote:
 On Mon, Mar 02, 2015 at 06:05:18PM +0100, Laurent CARON wrote:
 We clearly see a MTU mismatch (1500 vs 150*4* for inet6 on the 4200
 side) leading to OSPF adjacencies not coming up.

 Setting:
 set interfaces ae26 mtu 1518
 on the 4200 side allows to have the OSPF adjacencies up.

 Did you guys experience such bahavior ?

 4200 are running 12.3R8.7
 4500 is running 12.3R7.7

 I do not have an answer to your question, but this is one reason I
 always configure family inet mtu 1500 and family inet6 mtu 1500.  Then
 you can set the physical mtu as high as you want to accomodate
 multiple VLAN tags, MPLS, etc. without worrying.
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX series ntp clock issue ??

[Michael Loftis]

On Mon, Jan 26, 2015 at 7:25 AM, John Brown j...@citylinkfiber.com wrote:
 HI,
 While trying track down another issue I went to make sure that the MX
 clock was correct.
 I'm a bit confused by the results.

 Current time via show system uptime does NOT match the clock via
 show ntp status
 And the reftime in show ntp status and clock from the same aren't the same 
 ?

 Thoughts, appreciated

I don't see what the issue is...
Current time: 2015-01-26 08:21:59 MST
clock=d870da19.ba096ea4  Mon, Jan 26 2015  8:22:01.726, state=4,

Allowing for the time it took you to up arrow or type it in...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Experience with QFX5100 13.2 14.1

[Michael Loftis]

On Thu, Jan 15, 2015 at 6:43 AM, Tim Jackson jackson@gmail.com wrote:
 L3/MPLS LSR - Great experience, one issue currently in 14.1X53-D15 is any
 traffic that would have been sent an ICMP redirect (even with that turned
 off) will be duplicated.. One copy forwarded through the RE, one copy
 through T2 caused by PR1022354 (there are other scenarios that can cause
 this, too.. and this is still unfixed).. I think in 13.x there is an LDP
 bug (PR889585), but it's easy to work around.

 L2 - Several issues with it.. DHCPv4 Traffic in I think up to 13.2X53-D25
 in L2 will be silently discarded (punted to the RE as you can see this
 traffic by doing monitor traffic).. 14.1X53-D10+ fixes this (maybe
 13.2X53-D25). DHCPv6 traffic is still broken in even 14.1X53-D15, no PR for
 that one yet.

Do you have DHCPv4 enabled in any other way?   Ex dhcp-relay?  I ask,
b/c, on an unrelated platform (nd entirely different JunOS
versions- MX960s and EX9214s) we ran into - turning on dhcp-relay will
cause them to punt all UDP port 67 traffic.  Even if it's on an
interface that isn't mentioned in the config.  I haven't had a chance
yet to see if that happens to all logical instances or just the LI
that the dhcp-relay or dhcp features are enabled on.  Like I said,
unrelated platform, but, effectively the same thing.


 I've also had several QFX5100-96S boxes reboot without reason (on software
 all the way up to 14.1X53-D10), 0 logs, like they were powered off.. Still
 haven't found the root cause of this one yet, we're suspecting a bad batch
 of hardware possibly.

 I have several that are about to enter a mixed L2+L3/MPLS P/PE role soon..
 MC-LAG+L2+L3/MPLS+L3VPN all on a pair.. So far with testing that there
 haven't been any issues outside of the previously mentioned L2 gotchas.


 In general the experience has been pretty positive with them outside of a
 few L2 snafus.. I'm also not using the boxes in a traditional DC role,
 these are all SP roles..


 On Thu, Jan 15, 2015 at 1:30 AM, Richard Hartmann 
 richih.mailingl...@gmail.com wrote:

 Dear all,

 I was wondering what experience, if any, you have had with QFX5100.

 Of special interest would be what JunOS version you are running, what
 features you have enabled, and if you consider them production-ready.


 This question is open-ended on purpose.


 Thanks,
 Richard
 ___
 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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 14.x on MX

[Michael Loftis]

On Thu, Jan 8, 2015 at 12:32 PM, Mark Tinka mark.ti...@seacom.mu wrote:
 On Thursday, January 08, 2015 10:16:40 PM Michael Loftis
 wrote:

 Meep?   14.1R3 is the point on 14.1 train for MX960,
 MX480 

 Of course, I meant to type R1.10 ...

Cool, TY - I was thinking maybe as much but you never know.


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

Re: [j-nsp] 14.x on MX

[Michael Loftis]

On Thu, Jan 8, 2015 at 12:07 AM, Mark Tinka mark.ti...@seacom.mu wrote:
 On Thursday, January 08, 2015 01:09:29 AM Morgan McLean
 wrote:

 Anyone running 14.1 on a chassis based MX successfully ?
 Considering upgrading from 13.x to 14.1 for features..

 Been runnning 14.1R10 since June 2014 on MX80's and MX480's
 with all services including NetFlow. No issues to report.
 Amazingly, this has probably been the most stable code I've
 ran since Junos 10.

Meep?   14.1R3 is the point on 14.1 train for MX960, MX480   11.4
is the only one up past R9, a quick check on juniper.net shows 11.4R13
...  Just curious since I'm actually getting ready to upgrade some
MX960 kit into the 14.1 train.


 But we've since upgraded to an engineering release of 14.2
 for a specific feature we got Juniper to build us. Apart
 from some dodgy RPD madness on re1 (the backup RE), it's
 still rock solid despite it's not under general release.

 So for now, can't really complain about 14.1 or 14.2. But,
 as always, YMMV.

 Mark.

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Spanning tree RJ45 SFP on QFX5100

[Michael Loftis]

On Mon, Oct 20, 2014 at 7:41 AM, Richard Hartmann
richih.mailingl...@gmail.com wrote:
 Dear all,

 we are not done debugging yet, but as of right now, we are having a
 rather strange effect...


 Our setup looks as follows:

 QFX5100 = CStest
 sw1 = 2960g
 sw2 = 2960g
 sw3 = EX3300
 sw4 = 2960g
 sw5 = 2960S

 CStest RJ45 1G sw1
 CStest SM 1G sw2
 CStest SM 10G sw3
 CStest RJ45 1G sw4
 CStest SM 1G sw5

 The effect we're seeing is that Spanning Tree works just fine over the
 Single Mode links, but not across the RJ45 SFPs.

 Weirdly enough, LLDP and the like are being transmitted just fine.

 Yes, we tried all available JunOS releases, even a few beta images.
 Yes, we also tried 14.1X53-D10.

 I am kinda stumped as to how this is even possible. While we all hate
 RF45 SFP for various reasons, this is totally new and unexpected.


Might be interesting to know whose RJ45 SFP's?  If third party I'd
personally really tend to suspect/blame the third party...might be a
coding issue, might be the onboard hardware doing something silly.
I'd try a different vendor SFP.  It might be something Juniper is
making worse and is still willing to fix even if it's not necessarily
their problem - like there've been various i2c reading issues they've
dramatically improved behavior for.


 Yes, we're still having fun,
 Richard
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Dear Juniper...

[Michael Loftis]

Your web site now sucks rocks.  Like who decided to ship this?  One
single page for the entire EX switch lineup?  Can't find CRAP anymore.

Seriously?  Did ANYONE think about actually USING the site, or did you
just say make it preettyyy?

/rant

-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Dear Juniper...

[Michael Loftis]

On Thu, Sep 25, 2014 at 1:10 PM, Scott Granados sc...@granados-llc.net wrote:
 I’ll take marketing people run amuck for 1000 Alex.

Even with marketing...like it's horrible design, so much scrolling to
see anything.  And I'm not on a low res display (like a lot of
techs... MBP Retina is my main desktop most of the time) - it's like
their web team only ever looked at it on a big 27 display.

I knew a lot of us in the engineering community were thinking this
but I really had to speak out.  I think they should get tarred and
feathered for it personally.  But I obviously, yes, am not their
target customer market for the web site by a long shot anymore.

The whole Co. used to be focused on technical excellence...now it's
about how to get the buzzwordslockin vertical integration, etc.
And sell more boxes -- MX960, EX9214 - same chassis  one does = the
other || -- even the MIC's you can't keep same spares because they
idprom code differently.  It's retarded that one has to order one
2x40G MIC part for the EX and a different for the MX, the slot is the
same, the MIC is the same, damn boards have the same P/N.  Only
difference is the idprom flash.  Stupid.

-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler

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

Re: [j-nsp] BGP Peer formatting

[Michael Loftis]

For me at least, peer column needs to be wider (IPv6!) and duration
does too ( less than 1w you get a format like 2d 22:22:40)

On Mon, Sep 22, 2014 at 9:11 PM, Ben Dale bd...@comlinx.com.au wrote:

 On 23 Sep 2014, at 1:48 pm, Phil Shafer p...@juniper.net wrote:

 Ben Dale writes:
 Okay, one small caveat to this script - it looks like the use of mutable 
 variables (mvar
 and set) was only introduced in SLAX 1.1 / Junos 12.2, so it's actually not 
 going to wo
 rk on older versions of Junos.

 I know 11.4 is the trusted choice for most people on MX at the moment, so 
 when I get som
 e time I'll attempt a mind-bending re-write using the older immutable var 
 format.

 In this case, you don't need the mvars.  Let sum() do the iteration:

for-each ($neighbour-list/bgp-peer) {
output jcs:printf(%-20s%-15s%-12s%-10s%-10s%-10s%-10s%-5s,
peer-address,
peer-as,
peer-state,
elapsed-time,
   sum(bgp-rib/active-prefix-count),
   sum(bgp-rib/received-prefix-count),
   sum(bgp-rib/accepted-prefix-count),
description);
}

 Thanks,
 Phil

 Love your work Phil : )

 That's a heck of a lot simpler/cleaner than the recursive monstrosity I've 
 been putting together!

 Changes have been pulled into github, so if you're running 11.4 or earlier, 
 give it another try now.

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Route capacity EX4550

[Michael Loftis]

Host routes (ARP/L3 Gateway functionality) are also in the same space
FYI.  IIRC for the 4550 this is 14k total.  (Check the datasheet to be
sure).  You can tell how much your using by using an undocumented
command  - start a shell and do

cprod -A fpc0 -c show route ip table

You're looking at default.0 (unless you've got routing-instances or
similar, then, I'll leave that up to you to find the correct ones for
your routing instances) - it's roughly equivalent to the total of show
route summary + show route forwarding-table summary.



On Fri, May 2, 2014 at 2:12 PM, Morgan McLean wrx...@gmail.com wrote:
 Anybody know what sort of routes an EX4550 could take? Can't find much on
 their specs aside from 2gb memory. Would probably be in a VC setup.

 Considering taking partials or just using two defaults for a customer that
 wants to announce ip space and have a couple providers -- they only push
 maybe 100mbit so no use in getting new gear.

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to clear bgp neighbor

[Michael Loftis]

On Wed, Feb 26, 2014 at 11:29 AM, Jerry Dent effinjd...@gmail.com wrote:
 Just add a line Reset all bgp sessions? [Y/N] for confirmation.

*THWACK* THIS IS NOT WINDOWS.




-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to clear bgp neighbor

[Michael Loftis]

On Thu, Feb 27, 2014 at 8:39 AM, Michael Loftis mlof...@wgops.com wrote:
 On Wed, Feb 26, 2014 at 11:29 AM, Jerry Dent effinjd...@gmail.com wrote:
 Just add a line Reset all bgp sessions? [Y/N] for confirmation.

 *THWACK* THIS IS NOT WINDOWS.

Maybe that was a bit harsh, but still, there's very few things more
annoying than a CLI (well, any UI) that groans and moans and nannys
when you're trying to get work done, stealing your context or focus to
warn you about something dangerous.  Adding all as a requirement
is so much more elegant, easier on the CLI developer too, keeps an
accidental/bumped enter from bombing all BGP sessions just as clearly
as a prompt that is almost certainly going to not be fully read anyway
by a lot of admins.


I'd also add support that there are many other commands in clear that
might like this treatment (as mentioned by some others in the thread)


-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 true power consumption

[Michael Loftis]

The correct answer is it depends on configuration and traffic. Loaded with
LR SFP+s, vc modules, and pushing a significant amount of traffic it will
easily be 400W or more. Around 100W for a base, idle unit with a few optics
sounds right. Each optic module draws several watts depending on the type.
On Oct 23, 2013 10:25 AM, Jonas Frey (Probe Networks) 
j...@probe-networks.de wrote:

 Hello,

 does anybody have real world power consumption specs of the EX4550?
 (EX4550-32F-AFI)
 Juniper has no word about this anywhere in the documentation. There are
 only statements about the power supply itself (650W capacity) and less
 than five watts per 10GB fiber interface.
 I've been able to find various values on non-juniper related sites which
 range from 175W to 345W.

 Best regards,
 Jonas

 ___
 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] EX4550 true power consumption

[Michael Loftis]

I don't know anyone that assumes that the peak capability of a PSU
(especially in network gear) is it's actual consumtion, but thats just
me.  I do agree I wish they'd publish at least approximate figures.
It can be a deciding factor in a lot of environments today.  Keep in
mined 650W is high-line mode (~220/240VAC) - in 120V it's only going
to be around 325W.

On Thu, Oct 24, 2013 at 8:40 AM, Jonas Frey (Probe Networks)
j...@probe-networks.de wrote:
 Michael,

 i understand that it depends on the config. But why is it so hard to
 give some figures? E.g. base xx Watts, each optic xx Watts, VC module xx
 Watts and so on. Even Cisco does this (for example Nexus 3k).
 Right now it appears (with the only 650W power supply figure) as if the
 EX4550 is a power hog (compared to similar units like the above
 mentioned Nexus 3k).

 -J


 Am Donnerstag, den 24.10.2013, 08:28 -0700 schrieb Michael Loftis:
 The correct answer is it depends on configuration and traffic. Loaded
 with LR SFP+s, vc modules, and pushing a significant amount of traffic
 it will easily be 400W or more. Around 100W for a base, idle unit with
 a few optics sounds right. Each optic module draws several watts
 depending on the type.

 On Oct 23, 2013 10:25 AM, Jonas Frey (Probe Networks)
 j...@probe-networks.de wrote:
 Hello,

 does anybody have real world power consumption specs of the
 EX4550?
 (EX4550-32F-AFI)
 Juniper has no word about this anywhere in the documentation.
 There are
 only statements about the power supply itself (650W capacity)
 and less
 than five watts per 10GB fiber interface.
 I've been able to find various values on non-juniper related
 sites which
 range from 175W to 345W.

 Best regards,
 Jonas

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 true power consumption

[Michael Loftis]

On Thu, Oct 24, 2013 at 3:02 PM, Chuck Anderson c...@wpi.edu wrote:
 On Thu, Oct 24, 2013 at 09:38:43AM -0700, Michael Loftis wrote:
 I don't know anyone that assumes that the peak capability of a PSU
 (especially in network gear) is it's actual consumtion, but thats just
 me.  I do agree I wish they'd publish at least approximate figures.
 It can be a deciding factor in a lot of environments today.  Keep in
 mined 650W is high-line mode (~220/240VAC) - in 120V it's only going
 to be around 325W.

 This deserves clarification.  The power usage in Watts for a given
 hardware configuration should be the same either way--it is just that
 in high-line mode 208/220/240V, you will draw less current in Amps, by
 about half for twice the voltage (ohms law approximately, with a Power
 Factor Correction thrown in), and because of this the power supply is
 designed so that you can consume up to 650W of power only if you use
 high-line mode, and if you max-out the supply in low-line 120V mode
 you will only be able to consume up to 325W.  This implies that if you
 use low-line mode, you won't be able to install as many
 modules/optics/whatever-else-uses-power before hitting the max or
 losing power supply redundancy (being that both PSUs will be required
 to power everything).

Yeah sorry, I was quoting the PSU wattage ratings from memory at the
input voltage ranges, not usage.  So yes, barring efficiency
differences between 120V (low-line) and 240V (high-line) mode the
wall usage is, of course, the same.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Michael Loftis]

We were told by JTAC to reinstall from USB media but I don't think whomever
handled out ticket even looked at the TSB nor the ( externally invisible)
PR. If it was a reinstall I would suspect the TSB would just state that.

On Monday, October 7, 2013, Pierre-Yves Maunier wrote:

 Hello,

 I have affected REs, and before I had the knowledge of the KB, I found a
 workaround to repair the filesystem because the TAC was unable to tell me
 anything about this KB.

 After an upgrade from 12.2R1.8 to 12.3R4.6 I got this :

 === Bootstrap installer starting ===
 Initialized the environment
 Routing engine model is RE-S-1800x4
 HW model is Intel(R) Xeon(R) CPU   C5518  @ 1.73GHz
 [: kontron: unexpected operator
 Discovered that flash disk = ad0 , hard disk = ad1
 mount: /dev/ad1s1f : Invalid argument
 ERROR: mount_partition: Mount /dev/ad1s1f /mnt failed
 You are now in a debugging subshell (you may not see a prompt)…
 #

 And after a reboot I got this :

 Automatic reboot in progress...
 ** /dev/ad1s1a
 FILE SYSTEM CLEAN; SKIPPING CHECKS
 clean, 1673532 free (124 frags, 209176 blocks, 0.0% fragmentation)
 ** /dev/ad1s1e
 FILE SYSTEM CLEAN; SKIPPING CHECKS
 clean, 201639 free (31 frags, 25201 blocks, 0.0% fragmentation)
 Cannot find file system superblock
 32 is not a file system superblock
 28740192 is not a file system superblock
 ** /dev/ad1s1f


 LOOK FOR ALTERNATE SUPERBLOCKS? yes


 SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
 -b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
 SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).
 tunefs: /var: could not read superblock to fill out disk
 mount: /dev/ad1s1f : Invalid argument
 WARNING:
 WARNING: /var mount failed, building emergency /var
 WARNING:
 Creating initial configuration...mgd: commit complete
 Setting initial options:  debugger_on_panic=NO debugger_on_break=NO.
 Starting optional daemons:  usbd.
 Doing initial network setup:
 .
 Initial interface configuration:


 So the /var partition on /dev/ad1s1f (SSD) needed a fsck but it failed
 because of a 'bad superblock'

 Going in the shell as root, I issued the following command to get a lisk of
 'backup' super-blocks :

 root@CORE-01% newfs -N /dev/ad1s1f
 /dev/ad1s1f: 18342.8MB (37566076 sectors) block size 16384, fragment size
 2048
  using 100 cylinder groups of 183.69MB, 11756 blks, 23552 inodes.
 super-block backups (for fsck -b #) at:
  32, 376224, 752416, 1128608, 1504800, 1880992, 2257184, 2633376, 3009568,
  3385760, 3761952, 4138144, 4514336, 4890528, 5266720, 5642912, 6019104,
  6395296, 6771488, 7147680, 7523872, 7900064, 8276256, 8652448, 9028640,
  9404832, 9781024, 10157216, 10533408, 10909600, 11285792, 11661984,
 12038176,
  12414368, 12790560, 13166752, 13542944, 13919136, 14295328, 14671520,
  15047712, 15423904, 15800096, 16176288, 16552480, 16928672, 17304864,
  17681056, 18057248, 18433440, 18809632, 19185824, 19562016, 19938208,
  20314400, 20690592, 21066784, 21442976, 21819168, 22195360, 22571552,
  22947744, 23323936, 23700128, 24076320, 24452512, 24828704, 25204896,
  25581088, 25957280, 26333472, 26709664, 27085856, 27462048, 27838240,
  28214432, 28590624, 28966816, 29343008, 29719200, 30095392, 30471584,
  30847776, 31223968, 31600160, 31976352, 32352544, 32728736, 33104928,
  33481120, 33857312, 34233504, 34609696, 34985888, 35362080, 35738272,
  36114464, 36490656, 36866848, 37243040

 Then this command fixed the problem (376224 is the first super-block after
 '32' which seem to have an issue) :

 root@CORE-01% fsck_ufs -y -b 376224 /dev/ad1s1f

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

 Pierre-Yves



 2013/10/4 Phil Mayers p.may...@imperial.ac.uk javascript:;

  Saku Ytti s...@ytti.fi javascript:; wrote:
  On (2013-10-03 18:08 -0400), Paul Stewart wrote:
  
   Article is in review and not yet ready for viewing
  
  http://kb.juniper.net/InfoCenter/index?page=contentid=TSB16210
  
  
  
 
 http://kb.juniper.net/InfoCenter/index?page=contentid=S:TSB16164smlogin=
  
  --
++ytti
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
  Thanks, this is very useful - does look like our new REs are affected :o(
 
  Will contact support to get the fix implemented.
  --
  Sent from my phone with, please excuse brevity and typos
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler

Re: [j-nsp] Steel-Belted RADIUS backups

[Michael Loftis]

On Aug 30, 2013 1:46 AM, Jed Laundry jlaun...@jlaundry.com wrote:

 If it's Linux, are you using LVM as a storage layer?

 LVM snapshots are your friend for making a consistent backup, regardless
of
 if you use a tar script or VM snapshot/image.

Unless developers have made major structural changes to LVM snapshots
they're nearly useless. They require large swaths of contiguous kernel RAM
for the CoW bitmap so once a machine is running for a while and thus has
fragmented its RAM free space you end up with LVM bailing out while trying
to snapshot.  The other side of that is if your snapshot routine doesn't
shutdown services and unmount the filesystem you're essentially
snapshotting a crashed server and hoping filesystem and database recovery
goes well when you restore that backup


 Thanks,
 Jed.

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

Re: [j-nsp] M5 or M10 AC power supplies

[Michael Loftis]

I was pretty sure the old M5/M10 were around 500W, max, total.  You
sure that 700W isn't just the rating on the PSU? I'd bet you only need
A couple hundred total to run it unless it's fully
configured...Something like this -
http://www.trcelectronics.com/View/Mean-Well/HRP-200-48.shtml



On Tue, Sep 10, 2013 at 2:16 PM, Chuck Anderson c...@wpi.edu wrote:
 I have an old M10 (not M10i) with DC power supplies.  Does anyone have
 any AC power supplies they'd be willing to part with or trade for the
 2 DC ones I have?  This is just for playing around in the home lab...

 Alternatively, does anyone know of a cheap way to get enough DC power
 for these in a lab that doesn't have DC power?  Each power supply
 needs 14A at 48V, about 700W.

 This needs to be really cheap or free, because otherwise I'm just
 going to trash the whole router.

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Michael Loftis]

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



On Fri, Aug 23, 2013 at 5:30 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
 Just for curiosity - why is this a thing in JunOS? Why doesn't the
 platform just let you configure the aeX interfaces and figure out the
 count itself?

 It's such a specific thing to have to do I feel sure there's a reason, but
 can't for the life of me guess what :o)
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Michael Loftis]

Heh, thats what I get for making an assumption!

On Fri, Aug 23, 2013 at 9:38 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
 On 23/08/13 17:14, Michael Loftis wrote:

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


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

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

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper MX air filters

[Michael Loftis]

IDK about the MX240 as I haven't seen one, but the MX960 one appears
to be washable.  Juniper makes a bunch of nonsense claims about using
them within a year but the filter that I saw is the same as in most
manufactured homes.  A sort of ... expanded plastic.  You'd have to
make absolutely certain it was dry before putting it back into service
though.  So you'd probably need a couple anyway.

Since you're throwing them away anyway, may as well try?  If it
doesn't work out (IE filter comes apart or rusts or something) you've
only lost some time.

On Wed, Jul 31, 2013 at 9:30 AM, Philip Palanchi palan...@rutgers.edu wrote:
 I find that the air filters for MX240 routers are expensive. $1500 US List.  
 With discount they are still crazy money.  But we buy anyway and change them 
 out because it needs to be done from time to time.
 Can they be cleaned and reused?  If not, what do you do with the old ones? I 
 guess recycle the metal.

 Thanks,
 Phil

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] flow sampling: what packets are chosen?

[Michael Loftis]

On Thu, Jul 25, 2013 at 2:21 PM, Sebastian Wiesinger
juniper-...@ml.karotte.org wrote:
 * sth...@nethelp.no sth...@nethelp.no [2013-07-25 01:21]:
  When using inline IPFIX the only valid rate is 1.  The option
  run-length isn't configurable, because there's no need to sample data
  from the perspective of the microcode in the Trio Lookup Block.  Every
  packet will be inspected and is subject to flow export.

 We're doing inline IPFIX with 1:100 sampling rate, and getting sensible
 data. This is on an MPC-3D-16XGE-SFPP line card. Config snippet:

 I can confirm this, we use a higher sampling rate on MX80 and on the
 MPC-3D-16XGE-SFPP and on both we get valid data.


Good to hear, I remembered reading that mostly because it seemed so
wrong.  I don't think I'm missing any context from the book, and I
don't have any MPC/Trio based gear to test on myself.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] flow sampling: what packets are chosen?

[Michael Loftis]

On Wed, Jul 24, 2013 at 10:10 AM, Phil Sykes p...@atdot.at wrote:

 Run-length appears to be unsupported on newer (e.g. MX3D MPC) hardware.

 Regards,

 Phil


ISTR reading that's because they're 1:1 hardware sampling inside Trio
instead of just punts to the LC CPU or RE CPU, at least for IPFIX on
Trio.  Probably from the O'Reilly Juniper MX ... yup found it.  (any
typos are mine as I'm retyping this)

When using inline IPFIX the only valid rate is 1.  The option
run-length isn't configurable, because there's no need to sample data
from the perspective of the microcode in the Trio Lookup Block.  Every
packet will be inspected and is subject to flow export.

Which seems like a dumb/dense view of things since even Trio has
limits on the flow rates/etc and - while I haven't done the math at
all - I'd bet it's entirely possible to exceed those limits.

--

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Vlan question MX

[Michael Loftis]

vlan-tagging tells JunOS to treat the interface as multiple separate
L3 interfaces, identified by VLAN ID.  Their end is almost certainly
similarly configured (maybe as a MPLS PE)

On Mon, Jul 8, 2013 at 10:26 AM, Keith kwo...@citywest.ca wrote:
 Have this setup in the lab on some srx's but want to get some info
 on this.

 We have an upstream provider that we use a config:

 set interfaces ge-0/1/0 vlan-tagging
 set interfaces ge-0/1/0 encapsulation flexible-ethernet-services
 set interfaces ge-0/1/0 unit 1500 vlan-id 1500
 set interfaces ge-0/1/0 unit 1500 family inet address x.x.x.x/30


 We are turning up a second connection to them that will be terminated on a
 10G
 link and want us to use the same thing, vlan 1500, just a different IP
 address.

 Will this cause a problem by having the same vlan id on both links to the
 same provider? (I am guessing we are being terminated on different routers
 on their side).

 My lab router didn't complain so I'm guessing its probably ok.

 Thanks,
 Keith

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PS Supply on MX480

[Michael Loftis]

http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/mx-series/mx480/index.html#planning

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/power-supply-mx480-ac.html

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/mx480-power-components.html

So the answer is it depends.  Your exact system configuration
(including line voltages!) needs to be taken into account for how much
power you're using and have available.  I also do not know if you can
mix-n-match PSUs like that, I'll leave that up to others to answer.

On Wed, May 8, 2013 at 5:37 PM, John pp luklaupda...@gmail.com wrote:
 Hey everyone,

 Few questions here that nobody seems to know!
 the MX480 requires two PSU's to run
 I purchased a MPC line card (16xge sfpp), so I need the high capacity fans
 however how many *REGULAR *PSU's are needed for the high capacity fans..
 I'm finding these bigger 2520W PSU's, do I need these to run the high
 capacity fans? Or will regular suffice? I want to have some fault
 redundancy,

 i.e if the the regular can run it with 4 PSU then I'd go with the bigger
 psu anyway as if one psu fails then we'll run into issues..

 hope someone can help me here

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Are we under some weird SPAM attack?

[Michael Loftis]

Traffic on the list seems absolutely through the roof here...And a lot
of the messages are double posts, or following the same form.  They're
not like a markov generator or anything but they're kind of out of
character for this list.

Did the list posted somewhere new for the GWF crowd?

--

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX - Static Routing Out Same Interface

[Michael Loftis]

You'll need a hairpin rule eg:

set security policies from-zone trust to-zone trust policy hairpin match
source-address any
set security policies from-zone trust to-zone trust policy hairpin match
destination-address any
set security policies from-zone trust to-zone trust policy hairpin match
application any
set security policies from-zone trust to-zone trust policy hairpin then
permit

There is no implicit accept back into source zone.




On Wed, Nov 3, 2010 at 5:33 AM, Bruce Buchanan bbuch...@nexicomgroup.netwrote:

  Hi List –

 ** **

 Can anyone give any suggestion/guidance on the following.

 ** **

 I’m trying to do a static route **out** the same interface that the
 traffic came **in** on.  This is on an SRX-240

 ** **

 Here are the details:

 “Private”: 192.168.20.0/24

 “Public”: 216.168.x.x/32

 Static route: 172.30.200.0/24 to gateway – 192.168.20.224 to
 192.168.20.121

 ** **

 192.168.20.121 is the IP on a VPN appliance.

 ** **

 Traffic from a client computer never gets routed to the VPN appliance.
 This works on a Cisco 2800 without a problem, but I can’t get it working on
 the SRX.

 ** **

 Thanks,

 Bruce

 ** **

 *Bruce Buchanan*
 Senior Network Technician
 Nexicom
 5 King St. E., Millbrook, ON, LOA 1GO
 Phone: 705-932-4147
 FAX: 705-932-3027
 Cell: 705-750-7705
 Web: http://www.nexicom.net
 *Nexicom – Connected. Naturally.*

 [image: Click to call 
 me]http://messaging.nexicom.net/demo/callme.html?Token=%2BMG4FqUv2NeHeDa1hskfYtfJuno3cQZPLYABdYJ%2FSzqBopBqHiON5tp2gJxEFzvYJEVgFhguIyM94VT%2F5gSYKQPnNXfHtvtV4SL6WuBmtmrG9lu3W5DQJcNnjVetEwcMmynAZcsFspCj4zNyGZPVNQ9cD3MGYjzhJDuAztmmlY30X%2BInJFzGAIlxND9W0RghG63yJ4vYC%2BrYtAv33AYFzjqErh1nzDUutVR6cmGs%2BS9ymGDFRZ80IXTOm%2FRWr5AdjBr4L8EUO6tadfT3JSWBZdN1U9hDimBYYZgNaSPOUFLZBq5uwsyU%2Bf67gYm0NPIV6kggg%2B59ypWRWTDccFUF6ph3msB0k83cnY3FAWynyM5w2BYZZQmFIXVBCTMjkE01ulNAUnyyZh%2BMLmKXuci9RmrF1kq7tvNcCOtEFvYckpBHUjyH6%2FtX9wjXqATwcmgNU7ZVPdG5JvhdwS4m5tlusg%3D%3D
 

 ** **

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




-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
image001.png___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Inserting security policies on SRX

[Michael Loftis]

I've found the insert and similar commands often get confused as to what
you mean and where unless you move into the hierarchy closest to where
you're working first by doing edit security policies from-zone it_staff
to-zone untrust then doing your insert X before Y statement from that part
of the hierarchy.


On Mon, Jul 18, 2011 at 1:07 PM, James S. Smith jsm...@windmobile.cawrote:

 I have an SRX240 running 11.1R2.3, and occasionally I have to add new
 policies.  The obvious choice would seem to be use the insert command but
 I’m getting some weird errors.  For example, I have a number of policies
 for the different protocols going between the IT staff and the untrust
 zone.  When trying to insert a new policy the SRX complains the policy does
 not exist.

 ** **

 jsmith@fw01# insert security policies from-zone it_staff to-zone untrust
 policy it_staff-untrust-windows-rdp before policy it_staff-untrust-default
 

 error: statement 'it_staff-untrust-windows-rdp' not found

 ** **

 ** **

 ** **

 *James S. Smith *Network Architect

 *WIND Mobile *207 Queen's Quay West, Suite 710* *Toronto, ON M5J 1A7

 ** **

 *Email: *jsm...@windmobile.ca**

 *Direct:* 416-640-9792

 ** **

 *Fax: *416-987-1203  

 * *

 http://www.windmobile.ca/ 
 http://www.facebook.com/WINDmobilehttp://www.twitter.com/WINDmobile
 

 http://www.windmobile.ca/

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




-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
image002.pngimage001.pngimage004.pngimage003.png___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Michael Loftis]

On Thursday, May 2, 2013, Benny Amorsen wrote:

 joel jaeggli joe...@bogus.com javascript:; writes:

  There's literally no options in between. so a 1/10Gb/s TOR like the
  force10 s60 might have 2GB of shared packet buffer, while an like an
  arista 7050s-64 would have 9MB for all the ports, assuming you run it
  as all 10Gb/s rather than 100/1000/1/4 mixes of ports it can
  cut-through-forward to every port which goes a long way toward
  ameliorating your exposure to shallow buffers.

 Why does cut-through help so much? In theory it should save precisely
 one packets worth of memory, i.e. around 9kB per port. 500kB extra
 buffer for the whole 50-port switch does not seem like a lot.

 Lots of people say that cut-through helps prevents packet loss due to
 lack of buffer, so something more complicated must be happening.


My guess is it just hides the problem better...putting the burden of a
retransmit on the host NIC or similar by causing an old hub style collision.




 /Benny

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Michael Loftis]

I was finally able to get this explained via a third party who designs
these things ...

Basically in SF you have an input and output queue, per port.  When
port 1 sends to port 2 frames are moved from 1's input queue to 2's
output queue. If 2's out queue fills, it blocks back into 1's input
queue.  This causes drops not only for frames destined for port 2 but
unrelated frames as well.  In CT mode they get rid of the input queue,
and use that space for the output.  When a port's output queue fills,
drops for that port still happen, but drops for other, unaffected
ports, now do not happen.  CT mode also means the frame is transmitted
much earlier in the 1G-1G and 10G-1G modes (as soon as the ethernet
header is there) when there's no congestion.  So frames w/o an
interframe gap aren't as problematic either (which is the case
sometimes for microburst drops, insufficient interframe gap for the
CRC computation and the switching to occur before buffers fill)

Atleast now I understand how/why it improves things more than just
deeper buffers.  Basically unrelated traffic is unaffected, whereas
with SF mode, unrelated traffic can get backed up and lots of frames
get dropped that have nothing to do with the actual bottleneck.




On Thu, May 2, 2013 at 2:22 PM, joel jaeggli joe...@bogus.com wrote:
 On 5/2/13 1:24 PM, Benny Amorsen wrote:

 joel jaeggli joe...@bogus.com writes:

 There's literally no options in between. so a 1/10Gb/s TOR like the
 force10 s60 might have 2GB of shared packet buffer, while an like an
 arista 7050s-64 would have 9MB for all the ports, assuming you run it
 as all 10Gb/s rather than 100/1000/1/4 mixes of ports it can
 cut-through-forward to every port which goes a long way toward
 ameliorating your exposure to shallow buffers.

 Why does cut-through help so much? In theory it should save precisely
 one packets worth of memory, i.e. around 9kB per port. 500kB extra
 buffer for the whole 50-port switch does not seem like a lot.


 Until there's contention for the output side, you should only have one
 packet in the output queue at a time for each port on a cut through switch.
 which is like 96K of buffer for 1500 byte frames on a 64 port switch

 Store and forward means you hold onto the packet a lot longer mechanically
 even if nominally you are able to forward at line rate so long as there's
 always a packet in the ouput queue to put on the wire. consider that the
 fastest cut-through 10Gb/s switches now are around .4usec and your 1500 byte
 packet takes ~1.2usec to arrive.

 when adding rate conversion, consider that when having a flow come from a
 10Gb/s to 1Gb/s port that another 1500byte packet can arrive every ~1.2usec
 but you can only clock them back out every 12usec. jumbos just push the
 opportunities to queue for rate conversion out that much furthure



 Lots of people say that cut-through helps prevents packet loss due to
 lack of buffer, so something more complicated must be happening.


 /Benny


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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Are we under some weird SPAM attack?

[Michael Loftis]

And answered my own ? by reading the rest of my inbox.

Back under my rock now.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Quick way to delete multiple licenses on SRX

[Michael Loftis]

On Jan 31, 2013, at 8:40, Mark Menzies m...@deimark.net wrote:

 Thanks bud, but I still want to remove them.  Cos we run different classes
 we can easily confuse the students if they have a gazillion licenses and
 they only expect to see 1.
 
 I might end up trying to chin someone at Juniper to see if there is any way
 that we can play with license files etc.
 

If they're confused by extra licenses then they need to go back to working at 
McDonalds or Wal-Mart and save us all the pain of cleaning up after them.

 
 On 31 January 2013 16:34, Eugeniu Patrascu eu...@imacandi.net wrote:
 
 On Wed, Jan 30, 2013 at 5:34 PM, Mark Menzies m...@deimark.net wrote:
 Hi folks
 
 I have a quick question here.
 
 Is there any way other than the very slow request system license delete
 license ID command, to get rid of multiple licenses all at once?
 
 Basically we have several SRX units for training purposes and each of
 them
 has around 10 licenses each for various UTM and VPN features etc.  As not
 all of the courses require these licenses we need to add and remove them
 for each course when required.
 
 I am just a bit tired of the original command and was wondering if there
 is
 a quicker shortcut for this.
 
 Maybe not an answer to your question, but since they are for training,
 why not just leave the licenses there and use whatever features you
 need for a certain class ? I see no reason in why you feel like
 deleting and adding licenses all day.
 
 Eugeniu
 ___
 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] Embedded VPN JunOS Pulse client

[Michael Loftis]

The client installer executables are stored in the jail area...you can
start shell from the CLI with appropriate permissions, but you'll
probably have to be root to replace them - /jail/html/dynamic-vpn/client




On Sat, Dec 29, 2012 at 11:54 AM, Robert Hass robh...@gmail.com wrote:

 Hi
 I'm using SRX as VPN gateway. It's running JunOS 11.4R6.5. When new
 user downloads VPN client from SRX then JunOS Pulse Client version
 2.0.3.11013 is provided.
 But we occurring some problems (no communications over GSM) with this
 old version. This issue which was resolved in latest JunOS Pulse - eg.
 version 3.1R2.

 Is any way to upgrade Embedded JunOS Pulse client to version 3.1 ? I
 would like to new users fetch 3.1 instead of 2.0.

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




-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Embedded VPN JunOS Pulse client

[Michael Loftis]

Not sure how *easy* it is to modify any of it, but, there's gotta be a way
once you get into the shell :)  Maybe something to do with some sort of
OEM modifications or similar possibly.  IDK.  But you have root on the
box, it is FreeBSD, and I don't think there's any RBAC/MLS stuff preventing
you from doing whatever you want to as rootso as long as you don't muck
with the boot stuff you should be able to do it.

So there might possibly be shenanigans (like doing a remount in rc.local)
to get it done, IDK, but there's very little preventing you from doing it.
 Just make sure you document it for your own sake in case an upgrade undoes
anything you do.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] FIB Capacity on older platform

[Michael Loftis]

FIB capacity is determined solely by the FEB/CFEB on those platforms. I am a 
bit rusty on that line and not in front of one but I believe it is under show 
chassis ... Show chassis feb ... In terms of number of routes I don't think 
there is direct correlation because the FIB depends on your number of peers and 
interfaces.

Sent from my iPhone

On Dec 15, 2012, at 7:45, Robert Hass robh...@gmail.com wrote:

 Hi
 What is maximum FIB capacity on older M-Series platforms ? Eg. Juniper
 M5 w/RE600 or Juniper M20
 
 Rob
 ___
 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.?

[Michael Loftis]

On Thu, Dec 6, 2012 at 8:35 AM, Mike Devlin juni...@meeksnet.ca wrote:

 Its ironic this thread has started, since my company is in the process of
 replacing the core infrastructure, and we have it narrowed down to HP IRF
 on 5900 and 5800 platform vs Juniper EX4550 and EX4200 VChassis.

 I was considering asking the list about any experiences they have had
 comparing the 2 platforms.


The biggest thing I miss over Cisco is VTP.  Managing VLAN's is a huge pain
without it when you've got dozens of switches that all need the same VLAN
config. The pros on both HP and Juniper though tend to outweigh Cisco
anymore.  HP was (is?) giving lifetime software updates, and the out the
door prices are better than Cisco or Juniper.  When deploying a HP 5406 ZL
some years back at a previous job I was having some pretty painful issues
with 802.1x that they were able to debug with engineers and get us a
non-released build with fixes. HP Procurve Tech support was pretty
responsive at the time for those units, but that has been quite a few years
ago now, though from what I've heard they're still pretty on the ball.

At my current day job we just turned up the first EX4500 (the 4550 wasn't
available in our timeframe since they'd JUST started shipping at the time)
and so far so good.  We're not using the VC and might not end up using it,
but it's nice to have if we decide to go that route/need to.  So don't
really have much experience with those yet.  Majority of the switches at
the current day job are PowerConnect 6248's - they mostly work pretty well
as a plain switch, we're not doing L3 on them at all.


I have a series of 3rd party test results related to both technologies that
 ive been reviewing, but that can only give me so much info.  1st hand
 experience is really what im looking to hear about here.

 Does anyone have any experience with both technologies they wouldnt mind
 sharing with the group?

 Thanks,

 Mike

 On Thu, Dec 6, 2012 at 5:06 AM, Jonathan Lassoff j...@thejof.com wrote:

  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 
  h.a.sel...@hotmail.com
   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
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Routing Instance BGP Full Routing High Memory persists

[Michael Loftis]

This is actually expected behavior of Unix-like OSes in general.  RPD may
in fact have released the memory (using free()) but will still have that
RAM associated with it.  This is due to the fact that Unix (BSDlike esp)
generally use brk() or sbrk() under the hood during malloc() to request
more RAM from the OS.  There's actually no way for a process to return
memory to the OS.  Recent versions of POSIX have removed brk/sbrk from the
standard...but I believe at heart that libc/glibc still use this mechanism
to extend their address space/request more RAM from the OS.  brk() can in
theory reduce this allocation but I do not believe free() attempts this,
and the only thing brk() can do anyway is set the end of the address space,
so unless your memory space is defragmented you may end up with memory used
at the end of the space keeping everything allocated.

Memory management under the hood gets really complicated obviously.  In
general on Unix-like OSes it's expected a processes memory utilization will
grow to a peak, and then stay there.  So the OS and it's interfaces are
built around this (very reasonable, and in general very true) assumption.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2L SRX - Linux

[Michael Loftis]

Lookup route-based VPN's at Juniper's site, that will give you
everything you need for that side.  For the Linux side the details
depend on your distro, but in general it's simple and straight
forward, just remember to turn on ip_forward and setup firewall rules
appropriately (by default f/ex you'll be able to route packets into
the VPN from anywhere...source routed packets = bad in this case)

On Fri, Oct 26, 2012 at 6:35 AM, bizza biz...@gmail.com wrote:
 Hi,
 I need to configure a lan 2 lan vpn between a srx and a rhel server.
 There is anything I need to know before starting?
 Does anyone has a production l2l and could share the config snippet?

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



-- 

Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Backup u-boot image on SRX210?

[Michael Loftis]

Sent from my Motorola Xoom
On Oct 4, 2012 11:42 AM, Elle Plato techg...@gmail.com wrote:

 On Thu, Oct 4, 2012 at 11:25 AM, prd::S prd.s...@gmail.com wrote:
  Hi, All.
 
  A power outage occured when I was flashing the u-boot image on an
  SRX210 via tftp.
  Then there's no output on the serial console even after several resets.
  I suspect that the primary u-boot image might be corrupted.
 
  The questions are:
  Does SRX210 has a backup u-boot image?
  If so, how to boot from that image?
 

 SRX-210 devices should be configured for dual boot partition by
 default.  When you login after the primary
 is corrupted the login banner should warn you that the device booted
 from the alternate image,
 something like:  WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS
IMAGE
 and show system alarms should provide an alarm indicating the same
thing.


UBoot is the BIOS more or less. None of this helps him since it effectively
doesn't have a working BIOS to get that far.

I would ping JTAC - pretty sure the unit has a backup uboot image it can
fall back to but not having one I have no idea how to get at it myself.
Usually there's a jumper or a button one can hit to get the CPU to address
an alternate startup location.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper M10i PIC problems

[Michael Loftis]

Really sounds like somehow the chassis/backplane is toast, or that RE
is toast.  I'd open a JTAC case.  I don't know of any JunOS versions
that would cause the symptoms you're showing from the syslog at all.
The RE is clearly having trouble communicating with the chassis
components, whether thats a PCI bus issue, or, the internal switch/MAC
complex I don't know at all.


On Sat, Mar 31, 2012 at 7:41 AM, Emmanuel Kwarteng
emml.kwart...@gmail.com wrote:
 Hello,

 I have a Juniper M10i with one 2x STM-1 interface card and 1xGE card in FEC
 0. It's been working for more than a year now.

 It started with all the lights on the box going off. After a reboot, the
 STM-1 interface came up but the GE interface didn't come up.
 The RE active light also takes a long time to come up.

 After swapping the slots I realized it's not localized to the slot.
 Now both STM-1 and GE cards dont boot up at all.

 Any help would be very much appreciated.

 Please find some logs below:


 -
 *Mar 30 09:14:25  bbn-perimeter-rtr4 /kernel: SMB device error (bus_addr
 0x4c, index 0xaa)*
 *Mar 30 09:14:25  bbn-perimeter-rtr4 /kernel: SMB read failed addr 0x4c,
 off 0xaa, group 0x4, flags 0xd, len 0x2*
 *Mar 30 09:14:25  bbn-perimeter-rtr4 cfmd[1374]: -- Unable to fetch cfm
 system mac address. Setting up for retry*
 *Mar 30 09:14:25  bbn-perimeter-rtr4 cfmd[1374]:
 cfmd_get_system_mac_timer_expiry:329 Error fetching reserved mac address.
 Starting timer for retry*
 *Mar 30 09:14:26  bbn-perimeter-rtr4 cfmd[1374]: -- Unable to fetch cfm
 system mac address. Setting up for retry*
 *Mar 30 09:14:26  bbn-perimeter-rtr4 cfmd[1374]:
 cfmd_get_system_mac_timer_expiry:329 Error fetching reserved mac address.
 Starting timer for retry*
 *Mar 30 09:14:27  bbn-perimeter-rtr4 cfmd[1374]: -- Unable to fetch cfm
 system mac address. Setting up for retry*
 *Mar 30 09:14:27  bbn-perimeter-rtr4 cfmd[1374]:
 cfmd_get_system_mac_timer_expiry:329 Error fetching reserved mac address.
 Starting timer for retry*
 *Mar 30 09:14:28  bbn-perimeter-rtr4 cfmd[1374]: -- Unable to fetch cfm
 system mac address. Setting up for retry*
 *Mar 30 09:14:28  bbn-perimeter-rtr4 cfmd[1374]:
 cfmd_get_system_mac_timer_expiry:329 Error fetching reserved mac address.
 Starting timer for retry*
 *Mar 30 09:14:29  bbn-perimeter-rtr4 cfmd[1374]: -- Unable to fetch cfm
 system mac address. Setting up for retry*
 *Mar 30 09:14:29  bbn-perimeter-rtr4 cfmd[1374]:
 cfmd_get_system_mac_timer_expiry:329 Error fetching reserved mac address.
 Starting timer for retry*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB device error (bus_addr
 0x4a, index 0xaa)*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB read failed addr 0x4a,
 off 0xaa, group 0x4, flags 0xd, len 0x2*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB device error (bus_addr
 0x4b, index 0xaa)*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB read failed addr 0x4b,
 off 0xaa, group 0x4, flags 0xd, len 0x2*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB device error (bus_addr
 0x4c, index 0xaa)*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB read failed addr 0x4c,
 off 0xaa, group 0x4, flags 0xd, len 0x2*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB device error (bus_addr
 0x4a, index 0xaa)*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB read failed addr 0x4a,
 off 0xaa, group 0x4, flags 0xd, len 0x2*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB device error (bus_addr
 0x4b, index 0xaa)*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB read failed addr 0x4b,
 off 0xaa, group 0x4, flags 0xd, len 0x2*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB device error (bus_addr
 0x4c, index 0xaa)*
 *Mar 30 09:14:30  bbn-perimeter-rtr4 /kernel: SMB read failed addr 0x4c,
 off 0xaa, group 0x4, flags 0xd, len 0x2*
 *
 *
 *
 ar 30 08:59:47  bbn-perimeter-rtr4 chassisd[1413]:
 CHASSISD_I2C_GENERIC_ERROR: smb_cnh_re_offline_req: unable to read Routing
 Engine remove request
 Mar 30 09:00:02  bbn-perimeter-rtr4 /kernel: b_op_ok : master perms not
 sufficient..
 Mar 30 08:59:47  bbn-perimeter-rtr4 chassisd[1413]:
 CHASSISD_I2C_FIC_PRESENCE_READ: fic_presence_masks: FIC unable to get
 presence masks (Input/output error)
 Mar 30 09:00:01  bbn-perimeter-rtr4 chassisd[1413]:
 CHASSISD_I2C_FIC_PRESENCE_READ: fic_presence_masks: FIC unable to get
 presence masks (Input/output error)
 Mar 30 08:59:48  bbn-perimeter-rtr4 chassisd[1413]:
 CHASSISD_I2C_FIC_PRESENCE_READ: fic_presence_masks: FIC unable to get
 presence masks (Input/output error)
 Mar 30 09:00:01  bbn-perimeter-rtr4 chassisd[1413]:
 CHASSISD_I2C_GENERIC_ERROR: smb_cnh_re_offline_req: unable to read Routing
 Engine remove request
 Mar 30 08:59:49  bbn-perimeter-rtr4 chassisd[1413]:
 CHASSISD_I2C_GENERIC_ERROR: smb_cnh_re_offline_req: unable to read Routing
 Engine remove request
 Mar 30 08:59:49  bbn-perimeter-rtr4 chassisd[1413]:
 CHASSISD_I2C_FIC_PRESENCE_READ: fic_presence_masks: FIC unable to get
 presence masks 

Re: [j-nsp] M7i

[Michael Loftis]

On Sat, Apr 9, 2011 at 5:01 AM, Mark Tinka mti...@globaltransit.net wrote:
 On Friday, March 25, 2011 12:27:01 AM Michael Loftis wrote:

 M7i and M10i are essentially the same router, the M10i
 has redundant everything and four more PIC slots (on an
 extra FPC), the M7i only has an option for a redundant
 CFEB.

 Ummh, not really.

 The M7i eats only one CFEB at a time.

Woops, you're most definitely right, I am not at all sure what i was
thinking about when I wrote that.


 Mark.

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

Re: [j-nsp] Max. Bgp routes for M10i RE-850 1536MB

[Michael Loftis]

On Thu, Apr 7, 2011 at 7:13 AM, Serrano Samaca, Edinson (EXT-Other -
MX/Mexico City) edinson.serrano_samaca@nsn.com wrote:
 Hello, somebody could help us to get the maximum bgp ipv4 routes for a m10i 
 with RE850 and 1536 MB? We tried to searching at juniper website but we do 
 not find.

 Best Regards,


Kind of asking the wrong question possibly too, as someone metnioned
probabyl around ~6M RIB entries, but it's the FIB that could be (and
is more likely to be) your scaling limit, and that depends on which
CFEB you have.  I'm not exactly sure what the limits are but it seemed
like the 128M CFEBs could do in the area of ~1M entries before they
run out of memory.  Someone else might be able to give a more precise
number, and that number depends on the number of active feeds,
multi-path, etc as well since the FIB entries are boiled down from the
RIB (BGP).  This is also IPv4, I don't have any applicable IPv6
experience with M7i/M10i hardware.

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

Re: [j-nsp] M7i

[Michael Loftis]

On Thu, Mar 24, 2011 at 1:24 AM, Jonathan Lassoff j...@thejof.com wrote:
 On Wed, Mar 23, 2011 at 11:49 PM, cjwstudios cjwstud...@gmail.com 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.

Actually not all M7i's have the on-board GE, it depends on the BASE,
the base will either be M7iBASE-AC-2FETX which includes 2x 100mbit
copper Fast Ethernet ports on the inboard FPC, or M7iBASE-AC-1GE for a
single SFP gig-e port on board.  These ports are seperate from the
100mbit management only port on the RE itself, you can NOT route
packets through the management port, it is only there to talk to the
RE, the RE can talk over it to export flows/etc, OR the RE can use any
of the PICs as normal.  Those are AC power supply versions, there are
DC versions of same (that said I am pretty sure you can trade AC for
DC power supplies IIRC).

The M7i is a very solid platform itself, even though development is
slowing down, I kinda think the main reason for that is the platform
has pretty much reached all it can do.  It can not support 10GE, the
forwarding plane/FPC complex just doesn't have the bandwidth.  Even
the smallest CFEB shipped for the M7i has enough memory for full BGP
feeds.  If you plan on feeding it a LOT fo full views you might
consider an E series CFEB

M7i PIC ports are wire speed (well, almost all Juniper M series ports
are, with a few exceptions of oversubscription in some configurations)
and will very handily push 200mbit of small packets even.

M7i and M10i are essentially the same router, the M10i has redundant
everything and four more PIC slots (on an extra FPC), the M7i only has
an option for a redundant CFEB.

Basically the ONLY time an M7i or M10i might not be able to do wire
speed is when you add services from the ASPIC or ASM (M7i only).  And
if your'e not doing stateful firewalls or NAT (or a handful of other
time consuming not-exactly-router things) you'll never be able to hit
the limits on an M7i.  The M10i if fully packed with Gig-E or other
highest speed ports can be marginally oversubscribed.

What was said later about EX series is true, if you don't need to
support anything but ethernet, and aren't doing advanced services,
it'd be a good fit for you, though they're still teething a little bit
(see other threads on this list).

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

Re: [j-nsp] M20 / RE2 Full table

[Michael Loftis]

It actually depends on other factors than just the RE. The SSB may not have
enough memory depending on number of neighbors and ports.



Sent from my Motorola Xoom
On Mar 1, 2011 4:12 AM, Patrik Lagerman p...@connect2ip.se wrote:
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Recommandation for PIC slots on m10i routers

[Michael Loftis]

On Wed, Jan 12, 2011 at 2:27 AM, meryem Z merye...@hotmail.com wrote:

 Hello Community,

 When a juniper router is delivered , PICs are usually already installed.
 I need to know for an M10i router for example,  what is the default hardware 
 layout (slots used by default for each type of PICs) ? I didn't find any 
 recommandation about slots to be used for each type of PIC in the software 
 release notes or m10i hardware guide ..


M10i  has 8 PIC slots, grouped as two groups of four slots (each
called a FPC), each group of four slots supporting 4Gbit (FDX, 8Gbit
HDX) which unless you buy other options like an ASPIC2(+) or GigE PICs
will be unpopulated.  Unlike the M7i which will connect the second FPC
slot to inbuilt FE or GigE's (depending on your BASE) the M10i (to my
knowledge) has no such options.  So you can plug up to 8 PICs into it.
 There are certain combinations/limits, and there's a tech bulletin
about PIC Combination Rules which they keep updated.

In the M10i all PIC slots are equal,  The chassis is designed for PE-*
series PICs (with Ejector) but many of us successfully use PB-* series
PICs without the ejector but you have to be aware they can be a bugger
to get out...I don't actually know what Juniper's stance on that is,
but I'd assume it's unsupported.

Hope this answers your question, if not, please clarify.

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

Re: [j-nsp] Question regarding ISP Filtering

[Michael Loftis]

--On March 27, 2008 10:17:08 PM -0400 Stefan Fouant [EMAIL PROTECTED] 
wrote:

 Hey folks,

 This isn't specifically a Juniper question, so I do apologize for the
 improper venue...  however there are some pretty knowledgeable people on
 this list so here goes...

 I know that Verio, ATT, and Verizon support filtering through mitigation
 devices.  Are there any other ISPs which offer mitigation services?  Also,
 are there any ISPs out there that are currently supporting flowspec at
 their edge for traffic filtering applications?

I'm not sure there are devices supporting flowspec at all, much less 
carrier class devices.  Are there?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp