Re: [j-nsp] Inline IPFIX sampling rate

[Scott Granados]

I can confirm the rate=1 regardless of behavior up through 13.2 up through the 
PFE programming blocked by flow PR when that bug was addressed.


> On Jul 25, 2017, at 1:39 PM, Euan Galloway  wrote:
> 
> Let's try that again, but to the list this time...
> 
> *sigh*
> 
> Euan
> 
> On 25 July 2017 at 10:30, Pavel Lunin  wrote:
> 
>> AFAIR sampling rate config hadn't had any meaning for inline IPFIX until
>> some version of JUNOS. It used to be always 1, no matter what you have in
>> the config.
>> Question 1: If correct, which version it was when it's changed?
>> 
> 
> Although often said/documented/quoted, I've never actually seen this
> behavior (rate = 1 regardless of configuration).
> I'm *fairly* (but not 100%) sure that this didn't happen in late 11.x (even
> though referenced in MX book v1)
> It *certainly* doesn't happen in 12.3+
> 
> 
>> As of the 2nd edition of the MX book, "input rate" must follow the formula
>> “input_rate=2^n-1”. But it's somewhat poorly explained what it means.
>> Question 2: Do I correctly understand that the value, configured with
>> ”sampling instance  rate ”, must conform to this rule. Here  is
>> not the index of power of two (aka n in the formula above), it is the
>> actual sampling rate (result of the formula), right?
>> 
> 
> Right below the formula is a table of valid rates (described as
> "input-rate" throughout, rather than "rate")
> Shown as valid are 1 / 3 / 255 / 1023,
> 
>> 
>> Question 3. Given that I correctly understand the previous point, what if I
>> configured something that does not conform to this rule e. g. "rate 100"? I
>> suspect that it should lead to "rate 1" being programmed in the PFE but
>> 
> 
> It works (tested on 15.1F), no obvious difference in the % error for
> setting rate to 2 / 3 / 4 / 5 / 7 / 10.
> (Even though 3 and 7 are somehow "valid" and the rest not).
> 
> I suspect in some prior version it rounded up to the next valid number
> (since that's what commonly happens for other similar "you asked me to do
> something I can't, so I'll try my best to get close"). Also, I'm sure I've
> seen that behavior described by other users.
> 
> 
>> can't find a way to check this out. Anyone knows a uKernel command to
>> verify what is actually applied at the PFE level? It seems that "show
>> sample instance summary" just replicates the config values.
>> 
> Since it IS actually using the configured value, it's possible this IS the
> value programmed into the hardware.
> (but no, I don't know another command).
> I'll see what it shows on other versions, perhaps it used to round (I
> really doubt it ever just ignored you and did "1" if you missed the magic
> number).
> ___
> 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] Inline IPFIX sampling rate

[Scott Granados]

I would be interested in this as well.  My understanding was that the sampling 
rate in hardware was always set to 1:1 and the sample rate value was sent as 
the scaling factor for the sampling / reporting tool.  Changing the rate had no 
practical effect to the actual data.  If this has changed I’d be curious to 
know as well.

> On Jul 25, 2017, at 5:30 AM, Pavel Lunin  wrote:
> 
> Hi list,
> 
> It's been long time I didn't write here :)
> 
> Does anyone know in details how sampling-rate works (if it does) for inline
> IPFIX on MX/Trio?
> 
> AFAIR sampling rate config hadn't had any meaning for inline IPFIX until
> some version of JUNOS. It used to be always 1, no matter what you have in
> the config.
> Question 1: If correct, which version it was when it's changed?
> 
> As of the 2nd edition of the MX book, "input rate" must follow the formula
> “input_rate=2^n-1”. But it's somewhat poorly explained what it means.
> Question 2: Do I correctly understand that the value, configured with
> ”sampling instance  rate ”, must conform to this rule. Here  is
> not the index of power of two (aka n in the formula above), it is the
> actual sampling rate (result of the formula), right?
> 
> Question 3. Given that I correctly understand the previous point, what if I
> configured something that does not conform to this rule e. g. "rate 100"? I
> suspect that it should lead to "rate 1" being programmed in the PFE but
> can't find a way to check this out. Anyone knows a uKernel command to
> verify what is actually applied at the PFE level? It seems that "show
> sample instance summary" just replicates the config values.
> 
> 
> Regards,
> Pavel
> ___
> 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] Netflow analyzer / collector

[Scott Granados]

I would check out the good ol NFCAPD and NFDUMP.

Pretty good set of open source tools for collection of data and then reporting.

Thanks

> On May 22, 2017, at 2:21 AM, John Luthcinson  wrote:
> 
> Hi list
> 
> Could you recommend good Netflow/IPFIX analyzer / collector tools for SP
> environment? In the past (over 10 years ago) I have used e.g. flow-tools
> but it seems not well maintained nowadays.  Scripting and data export
> options are appreciated.
> 
> Goal is to export flow data mostly from Juniper MX devices (inline j-flow)
> 
> 
> Thanks
> ___
> 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] MX104 limitation

[Scott Granados]

Hi, in hardware flow sampling like inline Flow, I believe all sampling is done 
at 1/1 and the sample rate is only a scaling factor and doesn’t effect the 
physical sampling rate of the card.  It’s been a while though, I may be wrong 
on this but this was the case in code up through 13.2 or so.  

> On Mar 23, 2017, at 1:37 PM, Nitzan Tzelniker  
> wrote:
> 
> Hi,
> 
> If you run with inline jflow what was your sampling rate ?
> IIRC there is some bw limitation for inline sampling but I dont know if it
> include the sampling calculation or not
> 
> Nitzan
> 
> On Thu, Mar 23, 2017 at 11:12 AM, Saku Ytti  wrote:
> 
>> It's still about 75Gbps (i.e. for example 35Gbps+40Gbps) and 55Mpps.
>> 
>> But memory bandwidth is dependant on how well packet aligns into
>> cells, in manufactured example you could have packet which cause
>> singly byte to be transferred on second cell, essentially doubling
>> internal memory bandwidth requirement.
>> Traffic hitting QX will also experience significantly lower memory
>> bandwidth.
>> 
>> This is not MX104 specific, same applies to MX80, and MPC1, MPC2, MPC3
>> on per Trio basis.
>> 
>> On 23 March 2017 at 03:31, Javier Rodriguez 
>> wrote:
>>> Hi,
>>> 
>>> As Nitzan suggested, I deactivated the inline jflow and the traffic has
>>> increased.
>>> Now I ask, what is the real forwarding capacity of this box? 40G in + 40G
>>> out? (now it didn't reach 40G in total)
>>> 
>>> Javier.
>>> 
>>> 2017-03-20 12:15 GMT-03:00 Javier Rodriguez :
>>> 
 Nitzan, thank you very much, I'll keep that in mind.
 Anyway I can not understand how the router "eats" the packets without
 being counted That gives me panic!
 I can't find discarded packets anywhere!
 
 JR.
 
 2017-03-20 2:31 GMT-03:00 Nitzan Tzelniker >> :
 
> We saw a limitation around 40Gbps when running MX80 with RE based jflow
> (inline works good ) we didnt got good explanation why it limit the
>> traffic
> so try to disable some features and see if it help
> 
> Nitzan
> 
> On Mon, Mar 20, 2017 at 6:14 AM, Javier Rodriguez <
> rodriguezsot...@gmail.com> wrote:
> 
>> Mmm no, I think it doesn't  work on MX80 / MX104.
>> 
>> JR.
>> 
>> 
>> 2017-03-19 23:14 GMT-03:00 Olivier Benghozi <
>> olivier.bengh...@wifirst.fr
>>> :
>> 
>>> What about bypass-queuing-chip on MIC interfaces ? Would it work on
>>> MX80/104 ?
>>> 
 On 20 march 2017 at 01:32, Saku Ytti  wrote :
 
 Ok that's only 31Gbps total, without having any actual data, my
>> best
 guess is that you're running through QX. Only quick reason I can
>> come
 up for HW to limit on so modest traffic levels.
 
 On 20 March 2017 at 02:25, Javier Rodriguez <
>> rodriguezsot...@gmail.com>
>>> wrote:
> Soku,
> 
> Maybe there was a misunderstanding , the inbound traffic on
>> fpc2's
>> LAG
>>> was
> 4Gbps , and the outbound traffic was 27Gbps aprox. That outbound
>> traffic
> enters by the fpc1 and fpc0.
> It's IMIX traffic, the average packet size is 1250Bytes (out)
>> 200Bytes
>>> (in).
> I tried to see dropped packets with "show precl-eng 5 statistics
>> "
>> and
>>> "show
> mqchip 0 drop stats" at pfe shell but it's 0. Does it save
>> historical
>>> data?
> 
> 
> <--27G-- | | <--27G--
> |FPC2 FPC 0/1 |
> --4G--> | | --4G-->
> 
> Regards,
> 
> Javier.
> 
> 
> 2017-03-19 20:43 GMT-03:00 Saku Ytti :
>> 
>> Hey,
>> 
>> There aren't multiple FPCs on the box really, there is only
>> single
>> MQ
>> chip out of where all ports sit, usually MIC ports behind
>> additional
>> IX chip, which is not congested. It's architecturally single
>> linecard
>> fabricless box.
>> You're saying you're pushing on the 4x10GE fixed ports
>> 31+31Gbps,
>> e.g.
>> 62Gbps? It might be possible on (perhaps artificially)
>> unfortunate
>> cell alignment that it could be congested on so low values. Are
>> all
>> the packets same size, i.e is this lab scenario or just IMIX
>> traffic?
>> MQ pfe exceptions and MQ=>LU counters might be interesting to
>> see.
>> 
>> If you use QX chip, 62Gbps would be really good, QX chip is not
>> dimensioned for line rate _unidir_ (i.e. can't do even 40Gbps).
>> If
>> you
>> don't know if you're using QX or not, just deactive whole
>> class-of-service and scheduer config in interfaces.
>> 
>> On 20 March 2017 at 01:26, Javier Rodriguez <
>> rodriguezsot...@gmail.com
 
>> wrote:
>>> Hi,
>>> 
>>> Thanks for your reply Saku.
>>> The problem is that fpc2 (fixed ports) can't overcome 31Gbps
>

Re: [j-nsp] Netflow/Jflow

[Scott Granados]

+1, this is how I have set things up as well and yes, changing the table sizes 
will cause an FPC reboot.

> On Nov 3, 2016, at 9:04 PM, Olivier Benghozi  
> wrote:
> 
> Hi Keith,
> 
> Adjusting the size of the flow hash table will reboot the FPC.
> In 14.2 and previous, you have everything (15) for IPv4 and only a few 
> entries for IPv6 and VPLS (0). Each unit is 256K flows (except for 0).
> Starting from 15.1R, all flow tables have a default size of "0" (that is, a 
> mini-minimum of space, 1024 flows), so in 15.1+, fixing the sizing of the 
> flow-tables is more or less mandatory.
> 
> 
> This is the kind of generic config we use here to avoid an FPC reboot, would 
> we need some unplanned stuff with inline-jflow (that you may adjust according 
> to your needs, would you have plenty of IPv6 flows...). You have 15 units of 
> 256K to spend.
> 
> 
> groups {
>chassis-fpc-netflow {
>chassis {
>fpc <*> {
>sampling-instance sample-1;
>inline-services {
>flow-table-size {
>ipv4-flow-table-size 12;
>ipv6-flow-table-size 2;
>vpls-flow-table-size 1;
>ipv6-extended-attrib;
>}
>}
>}
>}
>}
> }
> chassis {   
>fpc 0 {
>apply-groups chassis-fpc-netflow;
>}
> }
> 
> 
> Olivier
> 
> 
>> On 3 nov. 2016 at 23:43, Keith  wrote :
>> 
>> One thing about inline that Juniper config docs say is about the flow-table 
>> size. I had someone
>> tell me enabling inline jflow will cause the fpc to reboot, but from what I 
>> read adjusting the size
>> of the flow hash table will cause that.
>> 
>> Any idea what is correct here? I would think that just enabling it would not 
>> cause an FPC to restart.
> 
> ___
> 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] Netflow/Jflow

[Scott Granados]

Hi, it’s been a while so if I’m wrong I’m happy to be corrected but in your 
case you’d sample on the input side of each of the individual interfaces facing 
the customer.

The load shouldn’t be an issue providing you’re running later code with out the 
JFlow related bugs such as the PR (I don’t recall the number) for the bug where 
flow processing blocked the PFE from accepting routes from the RE.  These were 
pre 13.2 on the 480 if memory serves but this is going back in the haze a bit 
so feel free to sanity check.  Inline JFlow does not have the same impact to 
processing of other platforms so you can be less concerned. 
The other thing to remember is that all sampling takes place at 1:1 and 
the sampling rate knob is more of a scaling factor rather than actually 
adjusting the rate of sampling.  Setting this to 1/1 instead of 1/1000 or what 
ever value will help the data appear correctly.

Thanks
Scott

> On Nov 2, 2016, at 1:34 PM, Keith  wrote:
> 
> We have a small network with one customer with ten connections all from an 
> MX480
> w/MPCE 2 3D,  RE2000 acting as a PE
> router.
> 
> All interfaces are L3VPN and have multiple vrf's on them.
> 
> Unit 11
> Unit 101
> Unit 102
> Unit 1000 - our management
> 
> The CPE at the customer is an EX4200 at each location.
> 
> The customer would like to see top talkers etc on each site.
> 
> We have flow capture setup on our peering/transit locations, but use
> unit 0 on those interfaces, and is pretty simple.
> 
> Would I put the sampling on each unit on each interface that from where
> we want to capture?
> 
> When setting up multiple captures on several interfaces is this going to
> be too much to do load wise?
> 
> The sites in question schools, are low bandwidth, mostly 30 megs with one at 
> 90.
> 
> Thanks,
> Keith
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Very basic question about MPLS and RSVP's place in the design

[Scott Granados]

Hi, I totally agree.  I was just trying to learn about RSVP and it’s uses in a 
lab setting.  Call this more of a personal growth and improving of skills, I’m 
not trying to build anything production related.  I did build an LDP based 
environment and you’re right it was pretty straight forward and was in fact 
where I started.  So, no I’m not sure I need RSVP at all but it seemed 
important to learn.  I think I’ll take a step back, read the book suggested and 
bone up on the basics further first.

> On Oct 26, 2016, at 2:43 AM, sth...@nethelp.no wrote:
> 
>> I�$,1rym trying to wrap my head around MPLS and have built a small lab.  I 
>> understand how provider routers label switch packets and how provider edges 
>> use VRF instances and their distinguishers and targets to address each 
>> other.  Per the Juniper examples I have LDP and RSVP enabled on all the 
>> transit interfaces along with MPLS and obviously the correct interface 
>> families (MPLS) attached to the same transit interfaces.  
> 
> Are you sure you need RSVP and bandwidth reservation? If you can do
> without this, a basic MPLS network with LDP but without RSVP is quite
> a bit easier to build and understand.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

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

Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design

[Scott Granados]

This sounds like a great place to start.  I assume the Cisco books aren’t 
overly Cisco specific as I’m trying to get my head around the basics with out 
depending on a single vendor.  It seems for example that cisco employs some 
shortcuts that I shouldn’t use at my starting point to learn the fundamentals.  
I’ll give these a shot and appreciate your suggestion.


On Oct 26, 2016, at 2:41 AM, Mark Tinka 
mailto:mark.ti...@seacom.mu>> wrote:



On 26/Oct/16 02:34, Scott Granados wrote:


Hi, this is a very basic question at least I think it is, apologies for being 
so green in advance.

If you are going to operate an MPLS network, it is very important that you nail 
the basics down.

You can learn a lot from this list, but I'd emphasize that doing some studying 
on your own will be even more helpful. I'd recommend the below:

http://www.ciscopress.com/store/mpls-and-vpn-architectures-9781587050022

The book is old, but it covers the fundamentals pretty well.

If you're done with that and want to take things deeper, I'd recommend Volume 
II of the same:


http://www.ciscopress.com/store/mpls-and-vpn-architectures-volume-ii-9781587051128

Anything beyond that will be gravy.

Mark.

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

Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design

[Scott Granados]

Hi Alex, thanks for these pointers.  I’m not sure I grasp all this yet but I 
think this will get me started.  As someone else mentioned I think I’ll start 
reading one of the fundamentals books and get my head around proper design.  
Maybe this sort of thing isn’t something I should be doing or concerned with.

Thank you again

On Oct 26, 2016, at 2:06 AM, Alexander Arseniev 
mailto:arsen...@btinternet.com>> wrote:


Hello,

Some answers:

A. bandwidth reservation is per outgoing interface that RSVP LSP takes and it 
is not truly global meaning that of course ingress LSR knows all the link 
bandwiths in given IGP domain but if there is "no bandwidth" signaled by 
upstream nodes, then ingress LSR router takes it at face value and Your LSP 
setup will fail. In fact, there could be BW attained by "repacking of existing 
LSPs to outgoing interfaces" in a different way but JUNOS does not do 
repacking. To achieve a truly global view of available and reserved BW, You 
need a centralised controller called Northstar but I digress.

B. To map different VRFs to different LSPs You'd need forwarding-table policy 
with "install-lsp" knob

http://www.gossamer-threads.com/lists/nsp/juniper/21830

Only equal-cost LSPs are considered in this policy. If Your two parallel LSP 
have different cost (by default they shouldn't as the default LSP cost is the 
minimum IGP cost to destination loopback) then You'd need to play with 
"no-install-to" and "install" knobs coupled with VRF nexthop rewriting to map 
different VRFs to different LSPs

https://www.juniper.net/documentation/en_US/junos13.3/topics/usage-guidelines/mpls-configuring-the-ingress-and-egress-router-addresses-for-lsps.html#id-95801

Thanks

Alex

On 26/10/2016 01:34, Scott Granados wrote:

Hi, this is a very basic question at least I think it is, apologies for being 
so green in advance.

I’m trying to wrap my head around MPLS and have built a small lab.  I 
understand how provider routers label switch packets and how provider edges use 
VRF instances and their distinguishers and targets to address each other.  Per 
the Juniper examples I have LDP and RSVP enabled on all the transit interfaces 
along with MPLS and obviously the correct interface families (MPLS) attached to 
the same transit interfaces.

I then per the doc built a label switched path something like.

set protocol MPLS label-switched-path r1-r4 to 10.0.0.4
;destination loopback of R4 which is acting as a PE
I have an equal return to 1 built as well
I also have a bandwidth reservation defined
set protocol MPLS label-switched-path R1-R4 bandwidth 10M
and a reverse reservation as well

As I understand you build these relationships between the loopbacks.  My 
question is how does this relate to the VPN VRF entries on the provider edges?  
Is this a global value that reserves 10 megabits between R1 and R4?  What if 
you want to reserve 10 megabits and 5 megabits between R1-R4-VRF1 <> R4-r1-vrf1 
 and r1-r4-vrf2 <> r4-r1-vrf2 where you have two matching sets of VRFs on the 
same PE pairs.  Is this possible or do I have the function of RSVP confused?

Again sorry for the n00by question I’m just trying to figure out how all the 
pieces fit together.  If anyone has any reference pointers that might be  a 
good start that explains this I would be interested as well.  The Juniper 
documentation is quite good but I can’t figure this out via searching so far.  
Any pointers would be most appreciated.

Thank you

Scott

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


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

[j-nsp] Very basic question about MPLS and RSVP's place in the design

[Scott Granados]

Hi, this is a very basic question at least I think it is, apologies for being 
so green in advance.

I’m trying to wrap my head around MPLS and have built a small lab.  I 
understand how provider routers label switch packets and how provider edges use 
VRF instances and their distinguishers and targets to address each other.  Per 
the Juniper examples I have LDP and RSVP enabled on all the transit interfaces 
along with MPLS and obviously the correct interface families (MPLS) attached to 
the same transit interfaces.  

I then per the doc built a label switched path something like.

set protocol MPLS label-switched-path r1-r4 to 10.0.0.4
;destination loopback of R4 which is acting as a PE
I have an equal return to 1 built as well
I also have a bandwidth reservation defined
set protocol MPLS label-switched-path R1-R4 bandwidth 10M
and a reverse reservation as well

As I understand you build these relationships between the loopbacks.  My 
question is how does this relate to the VPN VRF entries on the provider edges?  
Is this a global value that reserves 10 megabits between R1 and R4?  What if 
you want to reserve 10 megabits and 5 megabits between R1-R4-VRF1 <> R4-r1-vrf1 
 and r1-r4-vrf2 <> r4-r1-vrf2 where you have two matching sets of VRFs on the 
same PE pairs.  Is this possible or do I have the function of RSVP confused?

Again sorry for the n00by question I’m just trying to figure out how all the 
pieces fit together.  If anyone has any reference pointers that might be  a 
good start that explains this I would be interested as well.  The Juniper 
documentation is quite good but I can’t figure this out via searching so far.  
Any pointers would be most appreciated.

Thank you

Scott

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

Re: [j-nsp] dhcp not working across lacp link

[Scott Granados]

Do you have any config snippets?  Sounds pretty straight forward, maybe someone 
knows something obvious that I don’t but config pieces may shed some light.
 
> On Aug 9, 2016, at 1:30 PM, joe mcguckin  wrote:
> 
> Ok, test setup is 2) ex2200 switched, reset back to factory defaults.
> 
> Configuring a 2 port trunked LAG between the switches results in dhcp not 
> working across the link. Regular web traffic seems ok.
> Is there some magic command  make this work?
> 
> Thanks,
> 
> Joe
> 
> 
> Joe McGuckin
> ViaNet Communications
> 
> j...@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
> 
> 
> 
> ___
> 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] Wireless

[Scott Granados]

I’d also add Aerohive to the mix of consideration if they are still out there 
doing it.  Had good luck with their products and great support.

> On May 26, 2016, at 10:47 AM, Tammy Firefly  wrote:
> 
> 
> 
> On 5/26/16 8:45 AM, Jared Mauch wrote:
>> On Thu, May 26, 2016 at 07:35:35PM +0530, Mehul Gajjar wrote:
>>> Hi to all,
>>> 
>>> Can someone tell me how juniper in wireless compare to Aruba and cisco.
>> 
>>  If for an office or similar I would just look at UniFi.  Works well,
>> gives good intelligence and you can do automation against it.
>> 
>>  - Jared
>> 
> 
> 
> I/we highly recommend UniFi as well.
> 
> --Tammy
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Routing Engine filtering on EX with VRF

[Scott Granados]

I believe this is correct.  In order for a specific filter to have effect with 
in an routing instance you have to apply that filter to the loopback else I 
believe and am more than willing to be corrected but I believe the instance 
takes on the characteristics of the global filter when no filter is applied to 
the loopback within the instance.

> On Mar 22, 2016, at 12:28 PM, Luca Salvatore via juniper-nsp 
>  wrote:
> 
> Try putting an loopback interface into the vrf e.g lo0.1 and applying the
> filer to that.
> 
> On Sat, Mar 19, 2016 at 4:02 PM, Raphael Mazelier  wrote:
> 
>> 
>> 
>>> 
>>> On EX, you should be able to protect the RE using a filter on lo0 in the
>>> main routing instance (not in the VRF itself).
>>> But be aware that this does not work on tha ACX-series (for some strange
>>> reason)...
>>> 
>>> 
>> Yep the firewall filter work for interfaces that are on the main
>> routing-instance. But for some reason the filter does not apply on traffic
>> coming from interface placed in a vrf to the RE.
>> 
>> 
>> --
>> Raphael Mazelier
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> 
> 
> -- 
> Luca Salvatore
> Manager, Network Team | DigitalOcean
> Phone: +1 (929) 214-7242
> ___
> 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] MX960 Power Options

[Scott Granados]

8 AC inputs, I was always amazed by he amount of power the MX 960 used.  My 
drier uses less.:)  Then again when you think about being able to seat 100G 
cards and all sorts of goodies I suppose the power draw makes sense.

> On Jan 26, 2016, at 8:23 AM, sth...@nethelp.no wrote:
> 
>>> I recommend 4 x 208V.  The MX960 uses "power zones" in a 2+2
>>> arrangement where half of the chassis is powered by 2 PEMs, and the
>>> other half of the chassis is powered by the other 2 PEMs.  Make sure
>>> the 1st PEM for each zone is powered by the A feed, and the 2nd PEM
>>> for each zone is powered by the B feed.  For dual-input PEMs, you
>>> should put both inputs of a single PEM on the same branch circuit,
>>> either A or B.
>> 
>> Hi Chuck,
>> 
>> why would one want to put both inputs on the same circuit? That kind
>> of defeats the purpose in my mind. Are there caveats?
> 
> He's talking about dual-input PEMs. 4 PEMs, 8 inputs. In this case it
> makes sense to both inputs of a single PEM on the same branch circuit
> (this is explicitly what Juniper recommends).
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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] RTBH

[Scott Granados]

As a side note, this is how I’ve always seen it done.  I believe even the RFC 
refers to this method.

> On Jan 14, 2016, at 8:07 PM, chip  wrote:
> 
> A strategy that I've seen used is to pick some ip address and add a static
> route for it pointing to discard on every router.  Then when you receive
> the route to black-hole, set the next-hop to the discard route.  This way
> all routers will drop traffic for the prefix as soon as it enters the
> router instead of running through your network first.
> 
> 
> 
> On Thu, Jan 14, 2016 at 4:10 PM, Johan Borch  wrote:
> 
>> Hi!
>> 
>> I have implemented RTBH in my small network of 8 routers. DFZ is running in
>> a L3VPN and each router has an multihop ibgp-session with my RTBH-router
>> and it works, but I have one thing that annoys me.
>> 
>> If I announce an offending IP to be black holed, only one of the routers
>> will point to the discard route. The other 7 will see the announced route
>> via BGP från the one that got it first I guess and send the traffic to that
>> one where is is discarded. If I do show extensive on the route it is prefer
>> because of IGP. I can't figure out how to get each router to prefer the
>> discard localy. If I do local pref on one router the other 7 will send the
>> traffic there instead.
>> 
>> Every router has
>> 
>> route a.b.c.d/32 {
>>discard;
>>install;
>>}
>> 
>> And from sending RTBH router, they are announced with next-hop a.b.c.d.
>> 
>> Idéas? :)
>> 
>> Regards
>> Johan
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> 
> -- 
> Just my $.02, your mileage may vary,  batteries not included, etc
> ___
> 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] MX960 with 3 RE's?

[Scott Granados]

Sounds correct, only 2 routing engines at a time.

> On Jan 13, 2016, at 11:59 AM, Colton Conor  wrote:
> 
> Just to confirm though, its the extra RE that is different and not
> supported in this config right? The MX960 can use 3 SCB's at once, but only
> 2 REs? Or do I have the wrong too?
> 
> 
> 
> On Wed, Jan 13, 2016 at 8:16 AM, Mark Tinka  wrote:
> 
>> 
>> 
>> On 13/Jan/16 12:42, Jérôme Nicolle wrote:
>> 
>>> Looks like the broker had a few spare SCB and REs and no functionnal
>>> chassis to slap them in, so he invented a bundle and didn't fully test
>> it.
>> 
>> If the price is right, I'd take the extra RE and SCB as backup, in case
>> not including them does not yield any significant saving.
>> 
>> 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

Re: [j-nsp] juniper hack news

[Scott Granados]

So I wonder about your statements about the governments.  I would tend to agree 
and trust me there’s little about the scumbags in Washington (or insert your 
nations capitol here) that would surprise me but I’m not convinced.  There’s 
been a ton of bellyaching at least in the US and probably globally about strong 
cryptography.  For example here in the US the folks in jackboots are trying to 
convince us that strong cryptography was used in the Paris attacks and if we 
could only break the cyphers the world would be a  safer place. Maybe if we 
send all our snail mail on post cards as well.  But this bellyaching makes me 
think they aren’t nearly as good at this signals thing as we’re lead to 
believe.  So while I have heard of hacks before and it is absolutely with in 
the realm of possibility the NSA or whom ever has backdoors in everything but 
if they did would they cry so much about being able to get in the middle and do 
what spooks do?  Or is this complaining a false cover and they are so 
intertwined and back door hacked in to everything it doesn’t matter and they 
want to create a false sense to throw off potential baddies?  This is something 
I’ve been very curious about and the Government’s ability to collect this 
intelligence fascinates me.  I also wonder, if in fact this was in the ScreenOS 
source code does that mean that an agency or 2 has plants in Juniper?  I think 
something similar to this happened with a company producing SIM cards and a 
plant on the inside was able to gather information enabling the cards to be 
compromised by the NSA.  Wonder how far this is spread and how many vendors.

Excuse me while I go fashion a hat out of tin foil and stock up on canned 
goods.:)

Thank you
Scott




> On Dec 26, 2015, at 6:08 PM, Aaron Dewell  wrote:
> 
> 
> While that may be completely correct (while not completely provable, it is 
> entirely reasonable to assume it), the immediate question was whether this 
> particular vulnerability affected JunOS also, or only ScreenOS.
> 
> The answer to that more narrow question is that it only affects ScreenOS.
> 
> I think we can assume that most of the software we use today (Windows, MacOS, 
> IOS, JunOS, Linux, FreeBSD, etc.) all contain some form of government-induced 
> weakness.  Exactly what those are have yet to be discovered.  I for one am 
> confident that they all contain at least one if not many.  
> 
> However, the question asked only concerned this particular vulnerability, for 
> which JunOS is not affected.  The malicious code in question was introduced 
> into ScreenOS source code and not into JunOS.
> 
>> On Dec 26, 2015, at 3:21 PM, Chris Cappuccio  wrote:
>> 
>> Hugo Slabbert [h...@slabnet.com] wrote:
>>> 
>>> Am I missing something that indicates this is known to affect Junos as well?
>>> 
>> 
>> I just gave you a link to a formal NSA/GCHQ "TOP SECRET" documentation -- 
>> from
>> 2011 -- which says they are DOING IT. It only takes NSA ~90 days to develop
>> a new vulnerability in this class of software.
>> 
>> I think the best we can hope is that Juniper was privately informed and has
>> quietly patched any JunOS vulnerabilities.
>> 
>> Juniper has a lot of international business to lose from public
>> vulnerabilities in core Internet infrastructure. Cisco already took a large
>> hit.
>> 
>> I don't know what else to say. Anyone who thinks that the NSA did not develop
>> this capability in 2011 needs to read. Anyone who thinks NSA can't develop
>> this capability again (once their old vulnerabilities are burned) does not
>> understand the class of this attacker.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Analyzing traffic content

[Scott Granados]

This sounds like a job for inline Flow or more generically called NetFlow 
although if memory serves that may be a Cisco term.  (Flow is the Juniper term)

You can collect this data with something like NFSEN / NFDUMP and glean from 
that the data you’re looking for using all sorts of included filters.  There 
are paid packages that are also very good but good ol open source NFSEN / 
NFDUMp has been the way I’ve done it for a while now.

Good luck

> On Aug 26, 2015, at 6:29 AM, Cydon Satyr  wrote:
> 
> Hello experts.
> This is not directly tied to Juniper, but any help is welcomed.
> What I'm curios about is what kind of tools you use in your network to
> gather statistics/analyze traffic patterns on your links to other upstream
> provider/peering partners.
> 
> For example, how do you analyze how much of your bandwidth your customers
> use for video content, p2p traffic, vpn, web-surfing, etc? How much of your
> % is youtube traffic, how much is email traffic?
> 
> I hope the question makes sense.
> 
> Best regards
> ___
> 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] Breaking an EX cluster?

[Scott Granados]

Ah thanks for the link.

I tried googling and didn’t find much so this will be helpful.

Thank you

> On Aug 17, 2015, at 2:39 PM, Kevin Wormington  wrote:
> 
> I don't know if sub-versions would matter or not, IIRC my case was something 
> like 12.x and 13.x.  It's been a while, I may have also followed the 
> instructions from:
> 
> http://forums.juniper.net/t5/Ethernet-Switching/Disable-Virtual-Chasis-on-EX4200/td-p/46663
> 
> On 08/17/2015 01:32 PM, Scott Granados wrote:
>> Ah very interesting.  I didn’t think of that.
>> 
>> The switches all have what ever they were shipped and manufactured with.  
>> 13.2X51 but not sure if the sub version matches.  I will give that a look 
>> and match them up if they aren’t a matching set.
>> 
>> 
>>> On Aug 17, 2015, at 2:29 PM, Kevin Wormington  wrote:
>>> 
>>> Are these units all running the same version of JunOS?  If the lab units 
>>> have a new version or vice-versa it could spell trouble.  I ran into a 
>>> similar issue with 4300's and zeroing them and upgrading JunOS to the 
>>> latest recommend version with no VCP modules/cables installed and then 
>>> forming the chassis one unit at a time did the trick.
>>> 
>>> Kevin
>>> On 08/17/2015 01:19 PM, Scott Granados wrote:
>>>> So let me  be a bit more clear.
>>>> 
>>>> I have an existing lab chassis.  It’s just something we use to test on 
>>>> etc.  We received 2 more decommissioned 4300 members from the field to add 
>>>> to the stack.  Right now it’s a stack of 2 and I’d like to make this 4.  
>>>> The existing 2 member chassis boots fine, all the VCP ports show adjacency 
>>>> and all is good in the hood.:)
>>>> When I take the 3rd member whether I zeroize the new member to join it 
>>>> restarts but a link is never formed with the VCP ports.  I’m using the 
>>>> built in 40G ports and juniper cables that I obtained from Juniper for the 
>>>> back plain wiring on the stack.  No matter what I try I can’t get physical 
>>>> link between the two existing member chassis and one of my proposed 
>>>> repurposed members or member 3 in this case.  (line card roll)
>>>> 
>>>> I’m leaning towards hardware problem because I can’t get link no matter 
>>>> what I attach to the new switches VCP port but the two in the original 
>>>> functional chassis form adjacencies on all 4 cables.  So it’s adding the 
>>>> new to an existing that’s the problem.  Could be process and a very real 
>>>> possibility it’s the guy behind the keyboard writing this that’s the 
>>>> problem but not getting physical link was pointing me at hardware 
>>>> problems.  I just wanted to make sure I cleaned out the previous configs 
>>>> from the proposed new member well enough to not cause it to fail to join.
>>>> 
>>>> Does that make a bit more sense?
>>>> 
>>>> Thanks for you and everyone else responses as well. It’s very much 
>>>> appreciated.
>>>> 
>>>> Scott
>>>> 
>>>> 
>>>> On Aug 17, 2015, at 1:59 PM, Levi Pederson 
>>>> mailto:levipeder...@mankatonetworks.net>>
>>>>  wrote:
>>>> 
>>>> Scott,
>>>> 
>>>> I was under the assumption you wanted to zerorize and remove a unit from a 
>>>> Virtual Chassis.  Hence the use of system zeorize.
>>>> 
>>>> If you wanted to completely erase and re-setup a new VC with old members 
>>>> of a previous that is a different story.
>>>> 
>>>> I think you issue might be process related.
>>>> 
>>>> I would erase and and pre-setup (partially) the first switch in the NEW VC 
>>>> with no VC cables attached.
>>>> 
>>>> Then connect the VC cables and power on the next member (previously 
>>>> zeroized).
>>>> 
>>>> That should bring up the VC between the two devices.
>>>> 
>>>> The other option would be to statically assign the VC nodes using the 
>>>> serial numbers.
>>>> 
>>>> Thank you,
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Levi Pederson
>>>> Mankato Networks LLC
>>>> cell | 612.481.0769
>>>> work | 612.787.7392
>>>> levipeder...@mankatonetworks.net<mailto:levipeder...@mankatonetworks.net>
>>>> [http://www.mankatonetworks.com/images/mn_logo_email.

Re: [j-nsp] Breaking an EX cluster?

[Scott Granados]

Ah very interesting.  I didn’t think of that.

The switches all have what ever they were shipped and manufactured with.  
13.2X51 but not sure if the sub version matches.  I will give that a look and 
match them up if they aren’t a matching set.


> On Aug 17, 2015, at 2:29 PM, Kevin Wormington  wrote:
> 
> Are these units all running the same version of JunOS?  If the lab units have 
> a new version or vice-versa it could spell trouble.  I ran into a similar 
> issue with 4300's and zeroing them and upgrading JunOS to the latest 
> recommend version with no VCP modules/cables installed and then forming the 
> chassis one unit at a time did the trick.
> 
> Kevin
> On 08/17/2015 01:19 PM, Scott Granados wrote:
>> So let me  be a bit more clear.
>> 
>> I have an existing lab chassis.  It’s just something we use to test on etc.  
>> We received 2 more decommissioned 4300 members from the field to add to the 
>> stack.  Right now it’s a stack of 2 and I’d like to make this 4.  The 
>> existing 2 member chassis boots fine, all the VCP ports show adjacency and 
>> all is good in the hood.:)
>> When I take the 3rd member whether I zeroize the new member to join it 
>> restarts but a link is never formed with the VCP ports.  I’m using the built 
>> in 40G ports and juniper cables that I obtained from Juniper for the back 
>> plain wiring on the stack.  No matter what I try I can’t get physical link 
>> between the two existing member chassis and one of my proposed repurposed 
>> members or member 3 in this case.  (line card roll)
>> 
>> I’m leaning towards hardware problem because I can’t get link no matter what 
>> I attach to the new switches VCP port but the two in the original functional 
>> chassis form adjacencies on all 4 cables.  So it’s adding the new to an 
>> existing that’s the problem.  Could be process and a very real possibility 
>> it’s the guy behind the keyboard writing this that’s the problem but not 
>> getting physical link was pointing me at hardware problems.  I just wanted 
>> to make sure I cleaned out the previous configs from the proposed new member 
>> well enough to not cause it to fail to join.
>> 
>> Does that make a bit more sense?
>> 
>> Thanks for you and everyone else responses as well. It’s very much 
>> appreciated.
>> 
>> Scott
>> 
>> 
>> On Aug 17, 2015, at 1:59 PM, Levi Pederson 
>> mailto:levipeder...@mankatonetworks.net>> 
>> wrote:
>> 
>> Scott,
>> 
>> I was under the assumption you wanted to zerorize and remove a unit from a 
>> Virtual Chassis.  Hence the use of system zeorize.
>> 
>> If you wanted to completely erase and re-setup a new VC with old members of 
>> a previous that is a different story.
>> 
>> I think you issue might be process related.
>> 
>> I would erase and and pre-setup (partially) the first switch in the NEW VC 
>> with no VC cables attached.
>> 
>> Then connect the VC cables and power on the next member (previously 
>> zeroized).
>> 
>> That should bring up the VC between the two devices.
>> 
>> The other option would be to statically assign the VC nodes using the serial 
>> numbers.
>> 
>> Thank you,
>> 
>> 
>> 
>> 
>> Levi Pederson
>> Mankato Networks LLC
>> cell | 612.481.0769
>> work | 612.787.7392
>> levipeder...@mankatonetworks.net<mailto:levipeder...@mankatonetworks.net>
>> [http://www.mankatonetworks.com/images/mn_logo_email.png]
>> 
>> On Mon, Aug 17, 2015 at 12:33 PM, Scott Granados 
>> mailto:sc...@granados-llc.net>> wrote:
>> Hi Ross, I had tried this but still no link.  I believe I have a hardware 
>> problem at work causing the vc ports not to link.  Zeroize seemed to do the 
>> trick but with out connectivity I’m Dead in the water.  Time to RMA I think.
>> 
>> Thanks
>> Scott
>> 
>>> On Aug 17, 2015, at 1:20 PM, Ross Halliday 
>>> mailto:ross.halli...@wtccommunications.ca>>
>>>  wrote:
>>> 
>>> Since you want to nuke the config anyway, break the switch out of the VC 
>>> and use
>>> 
>>>   request system zeroize
>>> 
>>> You may want to assign the soon-to-be-former member an RE role, if it's not 
>>> an automatically elected cluster, just to make things a little easier.
>>> 
>>> Cheers
>>> Ross
>>> 
>>> 
>>> -Original Message-
>>> From: juniper-nsp 
>>> [mailto:juniper-nsp-boun...@puck.nether.net<mailto:juniper-nsp-boun...@puck.nether

Re: [j-nsp] Breaking an EX cluster?

[Scott Granados]

So let me  be a bit more clear.

I have an existing lab chassis.  It’s just something we use to test on etc.  We 
received 2 more decommissioned 4300 members from the field to add to the stack. 
 Right now it’s a stack of 2 and I’d like to make this 4.  The existing 2 
member chassis boots fine, all the VCP ports show adjacency and all is good in 
the hood.:)
When I take the 3rd member whether I zeroize the new member to join it restarts 
but a link is never formed with the VCP ports.  I’m using the built in 40G 
ports and juniper cables that I obtained from Juniper for the back plain wiring 
on the stack.  No matter what I try I can’t get physical link between the two 
existing member chassis and one of my proposed repurposed members or member 3 
in this case.  (line card roll)

I’m leaning towards hardware problem because I can’t get link no matter what I 
attach to the new switches VCP port but the two in the original functional 
chassis form adjacencies on all 4 cables.  So it’s adding the new to an 
existing that’s the problem.  Could be process and a very real possibility it’s 
the guy behind the keyboard writing this that’s the problem but not getting 
physical link was pointing me at hardware problems.  I just wanted to make sure 
I cleaned out the previous configs from the proposed new member well enough to 
not cause it to fail to join.

Does that make a bit more sense?

Thanks for you and everyone else responses as well. It’s very much appreciated.

Scott


On Aug 17, 2015, at 1:59 PM, Levi Pederson 
mailto:levipeder...@mankatonetworks.net>> 
wrote:

Scott,

I was under the assumption you wanted to zerorize and remove a unit from a 
Virtual Chassis.  Hence the use of system zeorize.

If you wanted to completely erase and re-setup a new VC with old members of a 
previous that is a different story.

I think you issue might be process related.

I would erase and and pre-setup (partially) the first switch in the NEW VC with 
no VC cables attached.

Then connect the VC cables and power on the next member (previously zeroized).

That should bring up the VC between the two devices.

The other option would be to statically assign the VC nodes using the serial 
numbers.

Thank you,




Levi Pederson
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipeder...@mankatonetworks.net<mailto:levipeder...@mankatonetworks.net>
[http://www.mankatonetworks.com/images/mn_logo_email.png]

On Mon, Aug 17, 2015 at 12:33 PM, Scott Granados 
mailto:sc...@granados-llc.net>> wrote:
Hi Ross, I had tried this but still no link.  I believe I have a hardware 
problem at work causing the vc ports not to link.  Zeroize seemed to do the 
trick but with out connectivity I’m Dead in the water.  Time to RMA I think.

Thanks
Scott

> On Aug 17, 2015, at 1:20 PM, Ross Halliday 
> mailto:ross.halli...@wtccommunications.ca>>
>  wrote:
>
> Since you want to nuke the config anyway, break the switch out of the VC and 
> use
>
>   request system zeroize
>
> You may want to assign the soon-to-be-former member an RE role, if it's not 
> an automatically elected cluster, just to make things a little easier.
>
> Cheers
> Ross
>
>
> -Original Message-
> From: juniper-nsp 
> [mailto:juniper-nsp-boun...@puck.nether.net<mailto:juniper-nsp-boun...@puck.nether.net>]
>  On Behalf Of Scott Granados
> Sent: Thursday, August 13, 2015 9:23 PM
> To: juniper-nsp
> Subject: [j-nsp] Breaking an EX cluster?
>
> Hi,
> Have some EX 4300s that I want to break apart and start like they were 
> factory new and reboot.  I know about the factory default button on the front 
> and the configuration option but no matter how I apply that I still have the 
> node boot thinking it’s a member of the previous chassis.  How do I delete 
> it’s membership when it’s active / a stand alone node?
>
> Any pointers are most appreciated.
>
> Thank you
> Scott
>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto: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] Breaking an EX cluster?

[Scott Granados]

Hi Ross, I had tried this but still no link.  I believe I have a hardware 
problem at work causing the vc ports not to link.  Zeroize seemed to do the 
trick but with out connectivity I’m Dead in the water.  Time to RMA I think.

Thanks
Scott

> On Aug 17, 2015, at 1:20 PM, Ross Halliday 
>  wrote:
> 
> Since you want to nuke the config anyway, break the switch out of the VC and 
> use 
> 
>   request system zeroize
> 
> You may want to assign the soon-to-be-former member an RE role, if it's not 
> an automatically elected cluster, just to make things a little easier.
> 
> Cheers
> Ross
> 
> 
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Scott Granados
> Sent: Thursday, August 13, 2015 9:23 PM
> To: juniper-nsp
> Subject: [j-nsp] Breaking an EX cluster?
> 
> Hi,
> Have some EX 4300s that I want to break apart and start like they were 
> factory new and reboot.  I know about the factory default button on the front 
> and the configuration option but no matter how I apply that I still have the 
> node boot thinking it’s a member of the previous chassis.  How do I delete 
> it’s membership when it’s active / a stand alone node?
> 
> Any pointers are most appreciated.
> 
> Thank you
> Scott
> 
> ___
> 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] Breaking an EX cluster?

[Scott Granados]

I tried this one and it errors out because the node was active.

Thanks
Scott

> On Aug 13, 2015, at 9:34 PM, Giuliano (WZTECH)  wrote:
> 
> Request virtual-chassis recycle and renumber you can put the switch as a 
> master stand alone
> 
> Sent from my iPhone
> 
>> On Aug 13, 2015, at 22:23, Scott Granados  wrote:
>> 
>> Hi,
>> Have some EX 4300s that I want to break apart and start like they were 
>> factory new and reboot.  I know about the factory default button on the 
>> front and the configuration option but no matter how I apply that I still 
>> have the node boot thinking it’s a member of the previous chassis.  How do I 
>> delete it’s membership when it’s active / a stand alone node?
>> 
>> Any pointers are most appreciated.
>> 
>> Thank you
>> Scott
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[j-nsp] Breaking an EX cluster?

[Scott Granados]

Hi,
Have some EX 4300s that I want to break apart and start like they were factory 
new and reboot.  I know about the factory default button on the front and the 
configuration option but no matter how I apply that I still have the node boot 
thinking it’s a member of the previous chassis.  How do I delete it’s 
membership when it’s active / a stand alone node?

Any pointers are most appreciated.

Thank you
Scott

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

Re: [j-nsp] MX104 Limitations

[Scott Granados]

I have set up the 104 in over seas pops and taken several views with out issue.
At a minimum 2 full table feeds + some peering.  SHouldn’t be a problem.

> On Jul 9, 2015, at 10:44 AM, sth...@nethelp.no wrote:
> 
>>> But MX104 can't hold the full internet routing table in forwarding-table so 
>>> it's good only for peering or can it indeed?
>> 
>> Can't it? I've assumed it can. Haven't actually deployed one yet.
> 
> It sure can. Last info I got from Juniper: 1.8M IPv4 or IPv6 prefixes
> (or a combination of the two).
> 
> We have quite a few MX104s in production with a full table, plus
> assorted L3VPNs.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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] MX104 Limitations

[Scott Granados]

I’m not sure about the BFD thing.

As I recall and I would definitely suggest you take this with a few grains of 
salt and research a second source but BFD on directly connected paths will 
distribute to the line card.  BFD say loopback to loopback or over a non direct 
path will be handled by the RE although I believe this was being addressed in 
future releases to have it distributed as well.


> On Jul 9, 2015, at 9:27 AM, Adam Vitkovsky  wrote:
> 
> Interesting facts. 
> Now the Juniper MX104 win over Cisco ASR903 (max prefix limit) is not that 
> clear anymore.
> 
> Since the chassis is 80Gbps in total I'd assume around 40Gbps towards 
> aggregation and 40Gbps to backbone.
> 
> Also if BFD is really not offloaded into HW it would be a bummer on such a 
> slow CPU.
> 
> With regards to 1588 I'd like to know if or how anyone deployed this on MPLS 
> backbone if the 4G is in a VRF???
> In other words 1588 runs in GRT/inet.0 so how do you then rely the precise 
> per hop delay/jitter info to a 4G cell which sits in a VRF?
> Never mind that the cell doesn't really need this precision and running 1588 
> with the server in 4G VRF across the 1588-blind MPLS core is enough.
> 
> It seems Juniper is still waiting for a big customer that is not willing to 
> wait for BGP to converge millions of MAC addresses if DF PE fails (PBB-EVPN)
> 
> 
> 
> adam
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>> Of Colton Conor
>> Sent: 24 June 2015 14:09
>> To: juniper-nsp@puck.nether.net
>> Subject: [j-nsp] MX104 Limitations
>> 
>> We are considering upgrading to a Juniper MX104, but another vendor (not
>> Juniper) pointed out the following limitations about the MX104 in their
>> comparison. I am wondering how much of it is actually true about the
>> MX104?
>> And if true, is it really that big of a deal?:
>> 
>> 1.   No fabric redundancy due to fabric-less design. There is no switch
>> fabric on the MX104, but there is on the rest of the MX series. Not sure if
>> this is a bad or good thing?
>> 
>> 2.   The Chassis fixed ports are not on an FRU.  If a fixed port fails,
>> or if data path fails, entire chassis requires replacement.
>> 
>> 3.   There is no mention of software support for MACSec on the MX104,
>> it appears to be a hardware capability only at this point in time with
>> software support potentially coming at a later time.
>> 
>> 4.   No IX chipsets for the 10G uplinks (i.e. no packet
>> pre-classification, the IX chip is responsible for this function as well as
>> GE to 10GE i/f adaptation)
>> 
>> 5.   QX Complex supports HQoS on MICs only, not on the integrated 4
>> 10GE ports on the PMC. I.e. no HQoS support on the 10GE uplinks
>> 
>> 6.   Total amount of traffic that can be handled via HQoS is restricted
>> to 24Gbps. Not all traffic flows can be shaped/policed via HQoS due to a
>> throughput restriction between the MQ and the QX. Note that the MQ can
>> still however perform basic port based policing/shaping on any flows. HQoS
>> support on the 4 installed MICs can only be enabled via a separate license.
>> Total of 128k queues on the chassis
>> 
>> 7.   1588 TC is not supported across the chassis as the current set of
>> MICs do not support edge time stamping.  Edge timestamping is only
>> supported on the integrated 10G ports.  MX104 does not presently list 1588
>> TC as being supported.
>> 
>> 8.   BFD can be supported natively in the TRIO chipset.  On the MX104,
>> it is not supported in hardware today.  BFD is run from the single core
>> P2020 MPC.
>> 
>> 9.   TRIO based cards do not presently support PBB; thus it is
>> presently not supported on the MX104. PBB is only supported on older
>> EZChip
>> based MX hardware.  Juniper still needs a business case to push this forward
>> 
>> 10.   MX104 operating temperature: -40 to 65C, but MX5, MX10, MX40, MX80
>> and MX80-48T are all 0-40C all are TRIO based. Seems odd that the MX104
>> would support a different temperature range. There are only 3 temperature
>> hardened MICs for this chassis on the datasheet: (1) 16 x T1/E1 with CE,
>> (2) 4 x chOC3/STM1 & 1 x chOC12/STM4 with CE, (3) 20 x 10/100/1000 Base-T.
>> 
>> 11.   Air-flow side-to-side; there is no option for front-to-back cooling
>> with this chassis.
>> 
>> 12.   Routing Engine and MPC lack a built-in Ethernet sync port.  If the
>> chassis is deployed without any GE ports, getting SyncE or 1588 out of the
>> chassis via an Ethernet port will be a problem.  SR-a4/-a8 have a built-in
>> sync connector on the CPM to serve this purpose explicitly.
>> ___
>> 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] eBGP Failover

[Scott Granados]

I vote for #1 and #3.

Both should give you fast fault detection.


> On Jun 30, 2015, at 4:09 AM, Peter Ehiwe  wrote:
> 
> Possible options :
> 1) link bundling technologies   And run single  ebgp session over the
> bundle
> 2) two ebgp sessions with shorter keep Alive
> 3) two ebgp sessions with bfd
> 
> Sent from a mobile .
> 
> On Tuesday, June 30, 2015, Mohammad Khalil  wrote:
> 
>> Hi all
>> I have a case where my router is connected to the upstream provider via two
>> physical links , we decided to configured eBGP over a loopback interface
>> The issue is that when the remote peer goes down (over which I have learned
>> the loopback from through static routing) , the route will still be
>> installed in my routing table (because from my side it's up) , so I will
>> lose connectivity and my eBGP neighbor will go down
>> So , what is the best redundancy solution I can implement so that I will
>> not lose my peering and switch over to the other static route without
>> disrupting my service?
>> 
>> Thanks
>> 
>> BR,
>> Mohammad
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> 
> -- 
> Sent from Mobile
> ___
> 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] Juniper 10G Switch Options

[Scott Granados]

+1 for the EX 4600 or QFX 5100.  For aggregation a 4600 should do the trick.

On Jun 4, 2015, at 9:19 AM, Colton Conor  wrote:

> We need a Juniper switch with at least 24 built in SFP+ ports. Looks like
> Juniper has a ton of options including the EX4500, EX4550, EX4600, and the
> QFX line which I don't know much about. This switch will be for aggregation
> purposes for an access network that has GPON OLT's with 10G uplinks on
> them. What do you recommend? Which has the latest hardware? Which is the
> most cost effective? Any limitations to be aware of?
> ___
> 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] AP oddness

[Scott Granados]

I’m sorry but I have to say it, GUI is for the weak.

These devices, especially network devices have no business having a web front 
end.  That just causes laziness and dumbs down the target audience. 

Vendors of equipment, especially serious equipment really need to get ahold of 
this fact and stop wasting time developing half assed web interfaces that 
really anyone worth their salt would never use anyway.

Just my $.02
 

On Jun 2, 2015, at 1:23 PM, Jonathan Call  wrote:

> - Have you double checked that the APs are configured with an identical set 
> of profiles on all radios?
> 
> - Are you terminating end user traffic at the AP via a local switching 
> profile, or tunelling everything back to the controller (the default)? If the 
> latter, the only thing that the EX4200 port configuration is relevant to is 
> the AP getting back to the controller.
> 
> And here is where trusting/using the web interface bit me. The affected (and 
> new) APs were missing the correct traffic termination since we put the 
> authenticated users into their respective VLANs directly from the APs:
> 
> set ap XX local-switching mode enable vlan-profile company-operations
> 
> As far as I can tell this mode can only be configured via the CLI.
> 
> - Have you verified that the users are actually ending up on the right VLAN 
> via "show sessions network"?
> 
> Yep. All of this was working smoothly.
> 
> - What code rev are you on? I had quite a few problems during the brief 
> time I ran 9.1, so I'd recommend the latest 9.0 release (MR4, I believe).
> 
> We're on 8.0.4.3.0, does 9.0 perform better? The both the GUI and SSH 
> connections are incredible unstable on our WLC.
> 
> Thank you,
> 
> Jonathan
> 
> 
> 
> 
>> Date: Mon, 1 Jun 2015 22:29:12 -0400
>> From: f...@wpi.edu
>> To: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] AP oddness
>> 
>> 
>> A few basic questions:
>> 
>> - Have you double checked that the APs are configured with an identical set
>> of profiles on all radios?
>> 
>> - Are you terminating end user traffic at the AP via a local switching
>> profile, or tunelling everything back to the controller (the default)? If the
>> latter, the only thing that the EX4200 port configuration is relevant to is
>> the AP getting back to the controller.
>> 
>> - Have you verified that the users are actually ending up on the right VLAN
>> via "show sessions network"?
>> 
>> - What code rev are you on? I had quite a few problems during the brief
>> time I ran 9.1, so I'd recommend the latest 9.0 release (MR4, I believe).
>> 
>> If nothing obvious jumps out, you may also have luck enabling trace debugging
>> for the afflicted client:
>> 
>> set trace dot1x level 10 mac 
>> set trace sm level 10 mac 
>> set trace radius level 10 mac 
>> 
>> You can then use "show log trace" to view the buffer, and "clear trace all" 
>> to
>> disable the debugging when you're done.
>> 
>> http://kb.juniper.net/InfoCenter/index?page=content&id=KB20351
>> 
>> Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
>> Manager of Network Operations | is simple, elegant, and wrong.
>> Worcester Polytechnic Institute | - HL Mencken
>> 
>> On 6/1/2015 4:47 PM, Jonathan Call wrote:
>>> 
>>> I have two APs connected to the same EX4200. Both are controlled by the 
>>> same (and only) WLC. When a client enables WIFI near the first AP that 
>>> person is able to access the Internet. When the same client enables WIFI 
>>> under the second AP they cannot connect to the Internet. The port 
>>> configuration for each AP is identical.
>>> 
>>> The WLC is configured to authenticate clients via Steel Belted Radius 
>>> (PEAP/802.1X) and put the clients into different VLANs based on their SBR 
>>> profile. In the case of the first AP the logs show the client IP changing 
>>> from 0.0.0.0 to the correct IP for their VLAN. In the latter, the client IP 
>>> is observed changing from 0.0.0.0 to 169.254.x.x as if DHCP (or VLAN 
>>> assignment) failed.
>>> 
>>> Both ports have the same configuration and any new APs added to the WLC 
>>> have the same problem.
>>> 
>>> Jonathan
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[j-nsp] Upgrading firmware on an EX 4300 virtual chassis?

[Scott Granados]

Hi,
I’ve downloaded the latest recommended firmware from the web site which is 
indicated as jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz.  I’ve been 
googling and keep finding procedures for upgrading that involve NSSU which I’ve 
seen go very badly all be it quite a while ago, before the feature was 
supported.  Will the normal method work?  Will something like the following do 
the job

>request system software add 
>/var/tmp/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz validate no-copy 
Once completed and valided
>request system reboot

Will this fit the bill or do I have to use the new procedures?  If this will 
work is there any need to define all members or is that assumed?  What’s my 
best upgrade procedure to proceed?  Also, any comments on the version that the 
site presented as acceptable, should I go with this release or is something 
else more preferred?

I’m presently running a buggy version of 13.2 that was shipped with the devices.

Any pointers would be most appreciated.

Thank you
Scott

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

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

[Scott Granados]

I’m not sure exactly what you’re looking for but the peer group system under 
JunOS is fairly efficient.  If you set your export and import policies per 
group the bgp process will place these in a peer group and dynamically break 
off slow members in to their own groups so that one slower peer won’t cause the 
other members in the same peer group to synchronize as slowly.  Cisco does not 
or at least did not do this as I understand things.  In the cisco case if a 
peer group member lags it causes the other members of the same peer group to 
lag and doesn’t allow updates until the slowest member catches up.  Since BGP 
under Junos breaks this slow guy off on it’s own you don’t have the same 
limitation.  This all happens dynamically.

On May 18, 2015, at 7:00 AM, Adam Vitkovsky  wrote:

> Hey buddy,
> 
> 
>> Saku Ytti
>> Sent: 18 May 2015 11:12
>> 
>> On (2015-05-18 10:04 +), Adam Vitkovsky wrote:
>> 
>> Hey Adam,
>> 
>>> I'd like to ask if the "90's" way of BGP generating updates per peer-group 
>>> is
>> a cause for concern on a modern gear.
>>> And if not then anyways am I the only one missing some flexibility in BGP
>> peers configuration in Junos?
>>> It's really annoying that every time one needs to adjust something for a
>> peer, might even be something session related, a new peer-group has to be
>> carved up.
>> 
>> Is there some efficient 2010's way you're thinking about?
>> 
>> Spamming same TCP datagram to multiple hosts has great efficiency
>> benefits,
>> but to be able to capitalize this, you need to group neighbours who are to
>> receive same set of routes, or TCP messages.
> 
> Yes I'm thinking about "BGP Dynamic Update Peer-Groups" 
> - the improved BGP update message generation where the update-group 
> memberships is calculated automatically/dynamically by the system based on 
> common egress policies assigned to peers.
> And of course the configuration using templates (i.e. session templates and 
> policy templates) and inheritance.  
> I've been relying on the above since ever in Cisco world and I miss that much 
> in Junos.
> 
>> 
>> Making 1 peer == 1 update-group would be easy, but it would make already
>> hella
>> slow rpd lot worse.
>> 
> You see this is what I mean, the RPD is slow so why not use the above to 
> speed things up.
> 
>> It is best to optimize advertised routes to as few sets as possible, to gain
>> best benefits. I would recommend not setting export filters on per-
>> neighbour
>> basis, only on group-level.
>> (i.e. not micro-optimize neighbours to receive exactly what is needed, if
>> extra routes are not actively harmful)
>> 
>> --
>>  ++ytti
> 
> That is an interesting approach indeed though it's a sacrifice we are forced 
> into because the update generation is not optimal in Junos.
> 
> adam
> ---
> This email has been scanned for email related threats and delivered safely by 
> Mimecast.
> For more information please visit http://www.mimecast.com
> ---
> ___
> 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] vMX availability

[Scott Granados]

And the world is a better place for you spending your day job in BGP land.:)

On May 6, 2015, at 8:39 AM, Jeff Haas  wrote:

> 
>> On May 6, 2015, at 12:13 AM, Nathan Ward  wrote:
>> 
>> On 6 May 2015 at 12:20:21, Jeff Haas (jh...@juniper.net 
>> ) wrote:
>>> -- Jeff (who regularly uses VMX in-house for control plane testing) 
>>> 
>> 
>> Have you done any BNG stuff on it? I’ve got a number of customers doing BNG 
>> on MX, and don’t really want to fork out for one of my own right now. A vMX 
>> with BNG would be handy. I’m told the code is there but not validated or 
>> supported. That’s fine by me, I don’t need to test QoS etc. - but do want to 
>> be able to test RADIUS integration, putting subscribers in VRFs, all that 
>> fun stuff.
> 
> I spend most of my day-job in BGP-land, so I have no experience with BNG in 
> general.
> 
> -- Jeff
> 
> ___
> 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] Buying a used Juniper

[Scott Granados]

Depends on the vendor and the application.  This is probably a more true 
statement with Juniper than Cisco because there is so much used Cisco out there 
that you could buy a large router of similar size and all the spare parts you 
want far less expensively than buying the hardware new even with deep discounts.

Juniper gear can be more rare and as a result cost more on the used market or 
you may not find the MX-480 used at all with out looking.  I do know for 
example if you don’t mind ordering out of Poland or other European countries 
that Juniper gear can be had for 10 cents on the dollar and again even with 
spares that’s hard to beat.  Depends on how many years you need to catch up on 
the service contract side and a lot of factors.


On May 5, 2015, at 1:00 PM, Levi Pederson  
wrote:

> Colton,
> 
> When it comes to important gear, something that would require the muscle of
> a MX480, I am hesitant to recommend used.  With all the hassles and hoops
> and handstands that could possibly be required , might be easier to get
> new.  Have you contacted your Sales Rep?  If not I can recommend a few.
> 
> Thank you,
> 
> *Levi Pederson*
> Mankato Networks LLC
> cell | 612.481.0769
> work | 612.787.7392
> levipeder...@mankatonetworks.net
> 
> 
> On Tue, May 5, 2015 at 11:47 AM, Colton Conor 
> wrote:
> 
>> What are the limitations of buying a used Juniper MX router? I assume there
>> will be no JTAC support, but what would it take to licenses a used router
>> to get JTAC support? Does JTAC offer a one time support call fee for
>> unlicensed routers?
>> 
>> Assuming I already have access to all the latest releases of JUNOS, not
>> sure the other reasons to pay for JTAC.
>> 
>> The router in question would be a MX480. Used, we can get them for under
>> 20K with redundant everything and 4 10G ports. New from Juniper I don't
>> even want to know what these would cost.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Replacing a member of a virtual chassis?

[Scott Granados]

Perfect and request virtual-chassis renumber to renumber the member from the 
newly assigned to the replaced value correct?

Thanks for the pointers, I just found this article shortly after posting.


On Apr 7, 2015, at 12:45 PM, Jonathan Call 
mailto:lordsit...@hotmail.com>> wrote:

Shut off defective member and remove it
With the replacement still powered off connect one VCP port to the VC stack
Power on the replacement and confirm it is showing up properly
Cable the other VCP into the VS stack

A more detailed explanation is given here:

http://www.juniper.net/techpubs/en_US/junos13.2/information-products/pathway-pages/ex-series/virtual-chassis-4300-x51.pdf

Jonathan


> From: sc...@granados-llc.net
> To: juniper-nsp@puck.nether.net
> Date: Tue, 7 Apr 2015 16:32:01 +
> Subject: [j-nsp] Replacing a member of a virtual chassis?
>
> Good afternoon,
>
> I have an EX4300 stack consisting of 6 members connected together using the 
> cables on the back in to a single chassis. I have VC-Ports flapping on member 
> 3 which is leading me to believe I have a bad member on a hardware level. I 
> have looked for a procedure to remove the member from service and install a 
> spare and haven’t found one through Google. I’ve opened a TAC case and am 
> told I’ll receive the instructions but I’m wondering if anyone has done this 
> and has a pointer to the KB article or a simple set of steps to complete. The 
> Virtual chassis is not pre provisioned so I don’t have any static mappings of 
> serial numbers to mappings. Any pointers would be most appreciated. Do I 
> simply install the new member and it auto configures as member 3 or are there 
> request commands and the like I should issue first? Any KB articles or 
> general advise would be greatly appreciated.
>
> Thank you
> Scott
>
>
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[j-nsp] Replacing a member of a virtual chassis?

[Scott Granados]

Good afternoon,

I have an EX4300 stack consisting of 6 members connected together using the 
cables on the back in to a single chassis.  I have VC-Ports flapping on member 
3 which is leading me to believe I have a bad member on a hardware level.  I 
have looked for a procedure to remove the member from service and install a 
spare and haven’t found one through Google.  I’ve opened a TAC case and am told 
I’ll receive the instructions but I’m wondering if anyone has done this and has 
a pointer to the KB article or a simple set of steps to complete.  The Virtual 
chassis is not pre provisioned so I don’t have any static mappings of serial 
numbers to mappings.  Any pointers would be most appreciated. Do I simply 
install the new member and it auto configures as member 3 or are there request 
commands and the like I should issue first?  Any KB articles or general advise 
would be greatly appreciated.

Thank you
Scott


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

Re: [j-nsp] MX80 BGP Convergence

[Scott Granados]

Yes, similar issues on the MX480 with Sampled when inline flow was enabled.


On Mar 23, 2015, at 6:30 AM, Adam Vitkovsky  wrote:

> Does this affect other MX series boxes as well please?
> 
> adam
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>> Of Jordan Whited
>> Sent: 20 March 2015 17:41
>> To: Tan Heng Chai
>> Cc: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] MX80 BGP Convergence
>> 
>> observed with inline sampling enabled, 1.5m in RIB, and one v4 feed (~250k
>> active-paths) changing state
>> 
>> 11.4R7.5 - 10+ minutes
>> 12.3R8.7 - ~220 seconds
>> 14.2R1.9 - ~200 seconds
>> 
>> YMMV
>> 
>>> On Mar 20, 2015, at 1:09 PM, Tan Heng Chai  wrote:
>>> 
>>> Hi J-NSP,
>>> 
>>>   Just wondering if anyone has benchmark/feedback on BGP
>> convergence times on the MX80 with and without sampling on versions
>> higher than 11.4R7.5, especially with reference to PR836197 and the sampling
>> issue?
>>> --
>>> 
>>> Yours Sincerely,
>>> 
>>> Tan Heng Chai
>>> Chief Technical Officer - SG.GS
>>> http://www.sg.gs
>>> ___
>>> 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
> ---
> This email has been scanned for email related threats and delivered safely by 
> Mimecast.
> For more information please visit http://www.mimecast.com
> ---
> 
> ___
> 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] MX80 BGP Convergence

[Scott Granados]

Depends on the version of code you’re running.  At best you’re looking at 
minutes and in some cases as much as 10 minutes.  With the wrong version of 
Code where the sampled bug is still present you might never get routes 
installed in the FIB.

The fix applied for the PR does allow for convergence but you see a lot of log 
jams and programming issues during a convergence event.  Tends to install 
routes in a very bursty way.



On Mar 20, 2015, at 1:09 PM, Tan Heng Chai  wrote:

> Hi J-NSP,
> 
>Just wondering if anyone has benchmark/feedback on BGP convergence 
> times on the MX80 with and without sampling on versions higher than 11.4R7.5, 
> especially with reference to PR836197 and the sampling issue?
> -- 
> 
> Yours Sincerely,
> 
> Tan Heng Chai
> Chief Technical Officer - SG.GS
> http://www.sg.gs
> ___
> 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] Recommended Junos version for EX-4500 virtual chassis

[Scott Granados]

I’ve honestly never seen NSSU or NSSD work and while I was working at Juniper 
they told us not to use it for the specific customer we were working with but 
that may have changed over the last year or so.   I was just going to use the 
request system software add junos-a.b.c.d validate all members method and 
reboot the cluster.

On Mar 19, 2015, at 9:19 AM, Laurent CARON  wrote:

> On 19/03/2015 13:57, Scott Granados wrote:
>> If I want to downgrade from 13.2 to 12.3R8 or R7.7 are there any special 
>> steps and or a document I should follow for this procedure or do I use the 
>> standard method?  I did some googling and didn’t find anything that applied 
>> or a KB article dealing with downgrading.
> 
> Please note it'll be a disruptive downgrade as NSSU (in your case NSSD) 
> soesn't support downgrade.
> 
> ___
> 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] Recommended Junos version for EX-4500 virtual chassis

[Scott Granados]

Ok, I’m running 13.2X51-D26.2 now and can’t find out much about this code other 
than that’s what was installed when they shipped the units.

I’m thinking going to the recommended version makes the most sense.  Thank you 
and the others who have responded, most helpful.

On Mar 19, 2015, at 9:09 AM, Tore Anderson mailto:t...@fud.no>> 
wrote:

* Scott Granados mailto:sc...@granados-llc.net>>

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

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

Tore

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

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

[Scott Granados]

If I want to downgrade from 13.2 to 12.3R8 or R7.7 are there any special steps 
and or a document I should follow for this procedure or do I use the standard 
method?  I did some googling and didn’t find anything that applied or a KB 
article dealing with downgrading.


Thanks
Scott

On Mar 19, 2015, at 8:49 AM, Mark Tinka  wrote:

> 
> 
> On 19/Mar/15 14:40, Laurent CARON wrote:
>> 
>> 
>> Hi,
>> 
>> Currently running 12.3R7.7 with no apparent trouble.
>> 
>> Previous versions were exhibiting memory leaks.
> 
> We've also been on 12.3R7.7 since July last year.
> 
> It's rock solid, but we are seeing issues where SNMP has issues processing 
> queries. This is solved by a hard reboot, but in cases where we've seen this 
> issue post RFS of the box, we can't afford a reboot.
> 
> Sadly, a warm or cold SIGHUP of the snmpd process does nothing.
> 
> Not sure if this a code thing or something else.
> 
> 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

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

[Scott Granados]

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

Thanks
Scott

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

Re: [j-nsp] show system boot-messages

[Scott Granados]

Great point, thanks for clarification.

On Jan 20, 2015, at 1:51 PM, Saku Ytti  wrote:

> On (2015-01-20 13:48 -0500), Scott Granados wrote:
> 
> Hey,
> 
>> Can’t you execute the dmesg command from the shell and watch the output 
>> there?
> 
> That's only what FreeBSD sees, the linecards are their own computers running
> own operating system. They won't talk to the FreeBSD system until they've been
> booted up.
> And for RE messages, the FreeBSD 'dmesg' won't see bios stuff at the start,
> so if you really want to see all, it won't work for RE either.
> 
> -- 
>  ++ytti
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] show system boot-messages

[Scott Granados]

Can’t you execute the dmesg command from the shell and watch the output there?

On Jan 20, 2015, at 1:38 PM, Saku Ytti  wrote:

> On (2015-01-20 11:26 +), Adam Vitkovsky wrote:
> 
> Hey Adam,
> 
>> I assume the cmd "show system boot-messages" shows just the Junos booting 
>> process
>> Is there a way to see the whole boot dumps- you know HW booting 
>> (MPCs/PEMs/SCBs/REs) -or is that even recorded somewhere please?
> 
> You need to observe console port during boot to see all. For MPC connect to
> them 'start shell pfe direct fpcX' before booting.
> 
> -- 
>  ++ytti
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80 JFlow Setup

[Scott Granados]

You will definitely have to poke a hole in your firewall on your loopback.  
Also, make sure the loopback is part of the main routing instance not in 
another grouting instance, your source until very recent releases has to be in 
the global table.  Use TCPDump to make sure that flow packets are reaching your 
collector as well for testing.


On Jan 15, 2015, at 12:18 AM, Andy Litzinger  
wrote:

> Yes I do. Sounds like I need to pole a hole?
> 
> 
> 
>> On Jan 14, 2015, at 6:14 PM, Eduardo Schoedler  wrote:
>> 
>> Do you have a firewall in your loopback?
>> 
>> --
>> Eduardo
>> 
>> Em quarta-feira, 14 de janeiro de 2015, Andy Litzinger <
>> andy.litzinger.li...@gmail.com> escreveu:
>> 
>>> Levi,
>>> did you get this working?  My MX80 appears to be collecting flows, but I
>>> don't see any output to my flow server.  The server ip is reachable from my
>>> MX 80.
>>> 
>>> # show chassis
>>> 
>>> tfeb {
>>>   slot 0 {
>>>   sampling-instance tp-sampling-instance;
>>>   }
>>> }
>>> 
>>> # show forwarding-options sampling
>>> traceoptions {
>>>   file ipfix.log size 10k;
>>> }
>>> instance {
>>>   tp-sampling-instance {
>>>   input {
>>>   rate 1000;
>>>   }
>>>   family inet {
>>>   output {
>>>   flow-server  {
>>>   port 2055;
>>>   version-ipfix {
>>>   template {
>>>   ipfix-ipv4-template;
>>>   }
>>>   }
>>>   }
>>>   inline-jflow {
>>>   source-address ;
>>>   }
>>>   }
>>>   }
>>>   }
>>> }
>>> 
>>> # show services
>>> flow-monitoring {
>>>   version-ipfix {
>>>   template ipfix-ipv4-template {
>>>   ipv4-template;
>>>   }
>>>   }
>>> }
>>> 
>>> # show interfaces ge-1/0/0
>>> 
>>> unit 0 {
>>>   family inet {
>>>   sampling {
>>>   input;
>>>   }
>>>   address ;
>>>   }
>>> }
>>> 
>>> # run show services accounting status inline-jflow
>>> Status information
>>>   TFEB Slot: 0
>>>   IPV4 export format: Version-IPFIX, IPV6 export format: Not set
>>>   VPLS export format: Not set
>>>   IPv4 Route Record Count: 516479, IPv6 Route Record Count: 4
>>>   Route Record Count: 516483, AS Record Count: 143756
>>>   Route-Records Set: Yes, Config Set: Yes
>>> 
>>> # run show services accounting flow inline-jflow
>>> Flow information
>>>   TFEB Slot: 0
>>>   Flow Packets: 1445, Flow Bytes: 1419455
>>>   Active Flows: 22, Total Flows: 935
>>>   Flows Exported: 764, Flow Packets Exported: 752
>>>   Flows Inactive Timed Out: 623, Flows Active Timed Out: 290
>>> 
>>> regards,
>>> -andy
>> 
>> -- 
>> Eduardo Schoedler
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80-1 JFlow

[Scott Granados]

You do not want to run version 9 in this case.

set forwarding-options sampling instance blah family output flow-server 
199.b.c.d port  version-ipfix template ipv4

set forwarding-options sampling instance blah family inet output inline-jflow 
source-address 199.loopback.0.address 
(or similar)
note that you can not originate flow data for capture from with in a routing 
instance, source must be in the global router.

Thanks
Scott

On Dec 23, 2014, at 1:14 PM, Levi Pederson  
wrote:

> All,
> 
> Sorry for the inconvenience.  There is a request to move to version9 under
> Forwarding options and Services but as I implement I'm getting tons of
> requests for config changes that do not make much sense.
> 
> Sending Errors Now
> 
> -mx80-1# commit check
> [edit forwarding-options sampling instance calix family inet output]
>  'flow-server'
>Output 'interface' or 'inline Jflow' should be configured with
> flow-server
> [edit forwarding-options sampling instance calix family inet output
> flow-server 199.71.143.217]
>  'version9'
>Service PIC or inline-jflow (j-series and SRX only) must be specified
> for version9
> error: configuration check-out failed: (statements constraint check failed)
> 
> Any help or direction pointing would be helpful.
> 
> Thank you,
> 
> *Levi Pederson*
> Mankato Networks LLC
> cell | 612.481.0769
> work | 612.787.7392
> levipeder...@mankatonetworks.net
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80 JFlow Setup

[Scott Granados]

Hi there, what you have will work well with a  few modifications.

If you’re using inline sampling you might as well set the rate to 1, the 
sampling is happening at 1:1 regardless and all the rate adjusts in this config 
is the scaling factor.
You’re config also needs sample points so something like

set interfaces xe-0/0/0.0 family inet sampling input
place an input sampling statement on the interfaces that face your upstream and 
that face your inside network, do not sample on the output channel.

You also don’t need to define everything on the template level
you can just do services monitoring flow sampling template ipv4 ipv4-template

you can set your flow sizes on the forwarding options sampling instance input 
section and finally you want to define an ipv4 and ipv6 flow-table size on the 
tfeb.

set chassis tfeb slot 0 sampling instance blah ipv4 and ipv6 table-size 

note that the tfeb will restart when configured  to reprogram with the new flow 
table size settings.

Settings are 1-15 where the number is x*256K flows.  You can define ipv4 only 
if you do not have any ipv6.

Hope that helps.


On Dec 23, 2014, at 12:16 PM, Levi Pederson  
wrote:

> All,
> 
> Trying to get an MX80 to output Flow to an external collector.  I've been
> reading several pieces of documentation and I keep getting differing views
> and opinions on how this is supposed to be done.  I'm looking for the
> simplest option right now and if I need to expand I can move to more
> detailed processes after
> 
> I'm currently using the following
> 
> [edit chassis]
> -   tfeb {
> -   slot 0 {
> -   sampling-instance calix;
> -   }
> -   }
> [edit]
> -  forwarding-options {
> -  sampling {
> -  instance {
> -  calix {
> -  input {
> -  rate 50;
> -  }
> -  family inet {
> -  output {
> -  flow-server [ipaddress] {
> -  port 2058;
> -  version-ipfix {
> -  template {
> -  ipv4;s
> -  }
> -  }
> -  }
> -  inline-jflow {
> -  source-address [ipaddress];
> -  }
> -  }
> -  }
> -  }
> -  }
> -  }
> -  }
> -  services {
> -  flow-monitoring {
> -  version-ipfix {
> -  template ipv4 {
> -  flow-active-timeout 60;
> -  flow-inactive-timeout 70;
> -  template-refresh-rate {
> -  seconds 30;
> -  }
> -  option-refresh-rate {
> -  seconds 30;
> -  }
> -  ipv4-template;
> -  }
> -  }
> -  }
> -  }
> 
> 
> Edited for Anonymity.
> 
> Thank you,
> .
> *Levi Pederson*
> Mankato Networks LLC
> cell | 612.481.0769
> work | 612.787.7392
> levipeder...@mankatonetworks.net
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80 Sampling - High CPU

[Scott Granados]

Mikrotek, ouch, the only thing I found they were good for is target practice.:)


On Dec 11, 2014, at 12:19 AM, Eduardo Schoedler  wrote:

> Em quarta-feira, 10 de dezembro de 2014, Jordan Whited 
>  escreveu:
> I found the issue still present in 12.3R8.7 running on an MX80. In 11.4R7.5
> with sampling enabled it was taking upwards of 12 minutes for routes to
> propagate to the FIB when taking in a full ipv4 with ~250k active-paths, in
> 12.3R8.7 I measured it closer to 3 minutes. Seems to be improved, but still
> unacceptable.
> 
> What do you expect from a PowerPC processor that's used for mikrotik's 
> routerboards?
> 
> Thake a look in dmesg. 
> 
> --
> Eduardo Schoedler
> 
> 
> -- 
> Eduardo Schoedler
> 

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

Re: [j-nsp] MX80 Sampling - High CPU

[Scott Granados]

I have 12.3R8.7 running on 2 MX-80s and 2 MX-480s with mixed results.  The good 
news is the routers will reconverge with sampling enabled now and the PFE 
programming won’t block hard.  The process is still slow however and while we 
did some testing it still seems that the processes hang during large updates 
although they do eventually un-wedge and complete.  The CPU spikes though seem 
pretty few and far between so that is an improvement.  I’m hoping the rewrite 
of the sampled and PFE programming in the 13.3 code is improved.  With sampling 
enabled these boxes reconverge to slowly, especially for modern hardware.  


On Dec 1, 2014, at 6:09 PM, Jordan Whited  wrote:

> Has anyone else made the jump to 12.3R8 yet?
> 
> On Wed, Oct 1, 2014 at 8:35 AM, Justin M. Streiner 
> wrote:
> 
>> On Wed, 1 Oct 2014, Sebastian Wiesinger wrote:
>> 
>> * Graham Brown  [2014-09-23 22:33]:
>>> 
 12.3R8 and 13.3R4 are due out anytime now with the fixes in place. I
 think
 there are many people waiting for these two releases...
 
>>> 
>>> So, 12.3R8 is out. Any practical experiences if inline jflow /
>>> sampling is faster now?
>>> 
>> 
>> Not sure yet.  I need to load it on my lab routers, but I won't know how
>> it behaves at full scale until I load it in production.
>> 
>> jms
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

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

[Scott Granados]

I’ll take marketing people run amuck for 1000 Alex.

On Sep 25, 2014, at 3:52 PM, Scott Harvanek  wrote:

> I agree with this more than the former.  I haven't had any issues 
> finding specs etc. but it's certainly "fatty block buzzword" design.
> 
> Scott H.
> 
> On 9/25/14, 3:44 PM, Daniel Rohan wrote:
>> I have to agree, but from a different angle. The "How Do We" section made
>> me laugh out loud, so filled with buzzwords: 'multi-dimensional core'
>> 'super-core', 'service-centric'. Better question is "how do I make sense of
>> what question is being asked here without reading each and every article?"
>> 
>> I actually didn't have any trouble getting to the spec sheets of the
>> products I care most about though.
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Sep 25, 2014 at 12:25 PM, Michael Loftis  wrote:
>> 
>>> 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"?
>>> 
>>> 
>>> 
>>> --
>>> 
>>> "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
>>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80 Sampling - High CPU

[Scott Granados]

+1 here, definitely awaiting these releases.

On Sep 23, 2014, at 4:28 PM, Graham Brown  wrote:

> 12.3R8 and 13.3R4 are due out anytime now with the fixes in place. I think
> there are many people waiting for these two releases...
> 
> Cheers,
> 
> Graham Brown
> Twitter - @mountainrescuer 
> LinkedIn 
> 
> On 24 September 2014 03:18, Justin M. Streiner 
> wrote:
> 
>> Sounds like you are running into bugs PR963060 or PR671136.
>> 
>> This is supposed to be fixed in 12.3R8 which is supposed to be released
>> very soon.
>> 
>> We ran into this behavior on a pair of MX480s and had to disable sampling
>> for the time being.
>> 
>> jms
>> 
>> 
>> On Tue, 23 Sep 2014, Ritz Rojas wrote:
>> 
>> We have a few MX80s (MX80-48T) that we're looking to deploy in certain
>>> applications where they'll be taking full Internet tables (v4 and v6).  We
>>> also have a need to gather flow data on our routers, and have noticed an
>>> interesting trend in the lab.
>>> 
>>> We are not using an MS-MIC currently.
>>> 
>>> This test box is running 12.3R7.7 at the moment, but we've seen this same
>>> thing in 11.4 too.
>>> 
>>> When set up with full Internet routes and sampling is enabled, each time a
>>> commit is made for any change at all, RPD and sampled take turns grinding
>>> the CPU up to 100%, for up to 5-10 minutes or more post-commit, and we see
>>> changes to BGP policy sometimes stall and take a decent amount of time (on
>>> the order of several minutes or more) to actually take effect.
>>> 
>>> First RPD will climb up to almost 100% CPU utilization, chew it for a few
>>> minutes, then it'll go down and sampled will climb up to almost 100% for
>>> it's couple minutes turn and chew a bit.  Then sampled goes back down and
>>> RPD takes back over to 100% for a few more minutes.  Eventually it all
>>> finally calms back down and normalizes back to expected levels.
>>> 
>>> Turn off sampling, and any CPU spikes post-commit are only on the order of
>>> seconds, not minutes, and any policy changes take effect pretty much
>>> immediately.
>>> 
>>> We've seen this regardless of how flow is configured; we've configured
>>> flow
>>> with a "simple" config, as well as inline jflow, pretty much with the same
>>> results.  We're curious if anyone's had any of these same problems with
>>> jflow killing the CPU on MX80s (yeah, I know these PPC boxes are pretty
>>> weak sisters), and if there's any fix beyond the usual "Doctor, it hurts
>>> when I do this, what should I do?".  "Don't do that!".
>>> 
>>> It's a nice feature, shame that using it seems to come with this heavy a
>>> price.
>>> 
>>> As an aside, we also see a bit of a slowdown in the RIB/FIB
>>> learning/purging on BGP session turnup/reset, which we're well aware is a
>>> known issue with sampling enabled, so I won't be shocked if this is just
>>> "how it is".  I'd love to be wrong.
>>> 
>>> Here's our sampling config, quick and dirty, regular and inline jflow, in
>>> case we're missing something.
>>> 
>>> "Normal" Sampling:
>>> 
>>> router> show configuration forwarding-options
>>> sampling {
>>>   input {
>>>   rate 8192;
>>>   run-length 0;
>>>   max-packets-per-second 2;
>>>   }
>>>   family inet {
>>>   output {
>>>   flow-server x.x.x.x {
>>>   port x;
>>>   version 5;
>>>   }
>>>   }
>>>   }
>>> }
>>> 
>>> router> show configuration interfaces xe-0/0/0
>>> unit xxx {
>>>   vlan-id xxx;
>>>   family inet {
>>>   sampling {
>>>   input;
>>>   output;
>>>   }
>>> }
>>> 
>>> 
>>> Inline Jflow Sampling:
>>> 
>>> router> show configuration forwarding-options
>>> sampling {
>>>   instance {
>>>   BLAH-INSTANCE {
>>>   input {
>>>   rate 5000;
>>>   }
>>>   family inet {
>>>   output {
>>>   flow-server x.x.x.x {
>>>   port ;
>>>   autonomous-system-type origin;
>>>   no-local-dump;
>>>   version-ipfix {
>>>   template {
>>>   BLAH-TEMPLATE;
>>>   }
>>>   }
>>>   }
>>>   inline-jflow {
>>>   source-address x.x.x.x;
>>>   }
>>>   }
>>>   }
>>>   }
>>>   }
>>> }
>>> 
>>> router> show configuration chassis
>>> tfeb {
>>>   slot 0 {
>>>   sampling-instance BLAH-INSTANCE;
>>>   }
>>> }
>>> 
>>> 
>>> router> show configuration services
>>> flow-monitoring {
>>>   version-ipfix {
>>>   template BLAH-TEMPLATE {
>>>   flow-active-timeout 10;
>>>   flow-inactive-timeout 10;
>>>   template-refresh-rate {
>>>   packets 1;
>>>   seconds 10;
>>>   }
>>>   option-refresh-rate {
>>>   packets 1;
>

Re: [j-nsp] Practice lab environments, any suggestions?

[Scott Granados]

So VFIrefly is a good idea.  I happen to have a copy from the time I was 
working for J.  I can probably get a good part of the way with that.  I’ve seen 
some pretty complicated topologies created using that environment.  Basically 
it seems to be a virtual SRX which you can then put in to packet mode and make 
simulate a J series router.  Might be a good low cost starting point.

On Sep 4, 2014, at 12:38 PM, Tyler Christiansen 
mailto:ty...@adap.tv>> wrote:

It also depends on what certifications you're going for.  Also need to keep in 
mind that EX2200 and EX3200, while capable of virtual chassis, do not have 
dedicated virtual chassis ports.  None of those devices will let you do some of 
the switching features necessary for SP exams, and the J2300 and J4300 are end 
of sale.  I haven't used the J series, but if they require a different Junos 
image than the J4350 or J2320, it may be difficult to find a new(er) Junos 
image.

I would honestly just buy a few EX4200s and use Junos Firefly (or whatever it's 
called now) for the routing.  If you can afford it, Junosphere is excellent.  
Not that it's expensive, but it does cost money, and if you don't use it for a 
significant portion of the day, it can be a "waste" of money.  Junosphere is 
due for v4 soon (there used to be a notice about potential downtime while 
systems are upgraded to support it--or something to that effect).

--tc


On Thu, Sep 4, 2014 at 9:17 AM, Scott Granados 
mailto:sc...@granados-llc.net>> wrote:
This actually looks interesting, thanks for the pointer.

On Sep 4, 2014, at 12:11 PM, ryanL 
mailto:ryan.lan...@gmail.com><mailto:ryan.lan...@gmail.com<mailto:ryan.lan...@gmail.com>>>
 wrote:

something like this might be overkill, but might save you a lot of money on 
rack rentals if you plan on spending loads of time on this.

http://www.ebay.com/itm/MUST-SEE-1OFAKIND-JUNIPER-JNCIE-JNCIS-JNCIA-CCIE-CCNP-COUNTERPART-CISCO-LAB-/141393100611?pt=US_Wired_Routers&hash=item20ebaf7f43

(not my listing, just an example, buyer beware, etc etc)



On Thu, Sep 4, 2014 at 11:58 AM, Scott Granados 
mailto:sc...@granados-llc.net><mailto:sc...@granados-llc.net<mailto:sc...@granados-llc.net>>>
 wrote:
Hi,
I’m starting down the path of certifications and wondering what people use for 
practice labs in terms of hardware?   I did some googling but have mostly found 
rack rental services.  Is this the primary method?  Is there anyone putting 
together bundles for sale of used equipment like you might find for Cisco 
hardware?  If not what hardware do people suggest for a home lab that’s 
reasonably cost effective.  Any suggestions would be most appreciated.  Any 
pointers to pre made kits or other solutions would also be greatly appreciated.

Thanks
Scott


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


___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto: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] Practice lab environments, any suggestions?

[Scott Granados]

This actually looks interesting, thanks for the pointer.

On Sep 4, 2014, at 12:11 PM, ryanL 
mailto:ryan.lan...@gmail.com>> wrote:

something like this might be overkill, but might save you a lot of money on 
rack rentals if you plan on spending loads of time on this.

http://www.ebay.com/itm/MUST-SEE-1OFAKIND-JUNIPER-JNCIE-JNCIS-JNCIA-CCIE-CCNP-COUNTERPART-CISCO-LAB-/141393100611?pt=US_Wired_Routers&hash=item20ebaf7f43

(not my listing, just an example, buyer beware, etc etc)



On Thu, Sep 4, 2014 at 11:58 AM, Scott Granados 
mailto:sc...@granados-llc.net>> wrote:
Hi,
I’m starting down the path of certifications and wondering what people use for 
practice labs in terms of hardware?   I did some googling but have mostly found 
rack rental services.  Is this the primary method?  Is there anyone putting 
together bundles for sale of used equipment like you might find for Cisco 
hardware?  If not what hardware do people suggest for a home lab that’s 
reasonably cost effective.  Any suggestions would be most appreciated.  Any 
pointers to pre made kits or other solutions would also be greatly appreciated.

Thanks
Scott


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


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

[j-nsp] Practice lab environments, any suggestions?

[Scott Granados]

Hi,
I’m starting down the path of certifications and wondering what people use for 
practice labs in terms of hardware?   I did some googling but have mostly found 
rack rental services.  Is this the primary method?  Is there anyone putting 
together bundles for sale of used equipment like you might find for Cisco 
hardware?  If not what hardware do people suggest for a home lab that’s 
reasonably cost effective.  Any suggestions would be most appreciated.  Any 
pointers to pre made kits or other solutions would also be greatly appreciated.

Thanks
Scott


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

Re: [j-nsp] NAT update commit script for SRX210

[Scott Granados]

Can you use the interface tag instead of the IP.

So something like match interface or the inverse of how you build a source nat?

On Aug 26, 2014, at 6:25 PM, Mike Devlin  wrote:

> Hey Guys,
> 
> Anyone know of a tested commit script that will update NAT config based on
> a DHCP interface changing IP addresses?
> 
> The scenario is this.  I have a location that the IP address is changing
> roughly every month.  I have a CNAME created for the FQDN pointing to
> dynamic DNS name that allows the DNS to get updated fairly quickly when
> this occurs, however im still stuck manually updating static NATs after
> this happens.
> 
> Im looking for a commit script that will look at the IP address of external
> interface (fe-0/0/7.0) and essentially do a "replace pattern  address> with "
> 
> any suggestions?
> 
> 
> Thanks,
> 
> Mike
> ___
> 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] ipv4/ipv6-flow-table-size

[Scott Granados]

That’s about the size of it.

Good luck on your sampling project.  I’ve had pretty good luck with it so far 
and gotten some great pointers from the list so post away if you have questions.

Thanks
Scott


On Aug 25, 2014, at 4:15 PM, Scott Harvanek  wrote:

> Thanks, I believe this does;
> 
> Assumptions based on this data;
> - I can operate on the defaults for my application [ very little 
> IPv6/VPLS ].
> - I can change it later if needed but that will cause the FPC to reboot.
> 
> -SH
> 
> On 8/25/14, 4:00 PM, Scott Granados wrote:
>> Here’s a bit more that I received that may help clear things up.
>> 
>> 
>> Scott,
>> 
>> A total of 4M flows can be created per 1 LU chip. Now it depends on the size 
>> that we allocate to ipv4-flow-table size,ipv6-flow-table-size and 
>> vpls-flow-table-size.
>> If only ipv4 template is to be used, then all the memory on the pfe could be 
>> reserved only for the ipv4 family.
>> 
>> For eg:  if 15 is allocated for IPv4 then total flows that can be created = 
>> 15*256*1024 = 3932160 and 1k IPv6 flows and 1K vpls flows (default).
>> Each unit in flow hash table size corresponds to memory size of 256k 
>> (256x1024).
>> 
>> In your case,
>> flow-table-size for ipv4 = 5, Total-flows that can be created = 5*256*1024 = 
>> 1310720
>> you are exporting @ 7k flows/sec to the flow-collector
>> If all of your traffic belongs to ipv4: Number of flows getting created = 
>> 7*1024*10 = 71680 flows/sec [ 10 = number of flow-records per 1 packet sent 
>> to flow-collector ]
>> 
>> 
>> On Aug 25, 2014, at 3:56 PM, Scott Harvanek  wrote:
>> 
>>> Scott,
>>> 
>>> Thanks, my next question then with that is - how/why is the default of
>>> ipv4 15 and ipv6 1?  That would break that constraint of 15 total?
>>> 
>>> Scott H.
>>> Login Inc.
>>> 
>>> On 8/25/14, 3:53 PM, Scott Granados wrote:
>>>> When ever you set the flow table size you initiate a reboot of the FPC.  
>>>> The table size is a combined value of v4 and v6 so 15 total a subset of 
>>>> which is IPV4 and the remainder is IPV6.
>>>> 
>>>> Thanks
>>>> Scott
>>>> 
>>>> On Aug 25, 2014, at 3:02 PM, Scott Harvanek  
>>>> wrote:
>>>> 
>>>>> I'm wondering if anyone can clarify something for me from docs:
>>>>> 
>>>>> "
>>>>> 
>>>>>  * Any change in the configured size of flow hash table sizes initiates
>>>>>an automatic reboot of the FPC.
>>>>>  * The total number of units used for both IPv4 and IPv6 cannot exceed 15.
>>>>> 
>>>>> "
>>>>> 
>>>>> - Does the initial config entry of ipv4/ipv6-flow-table-size cause the
>>>>> FPC to reboot or only if the configured value is changed?
>>>>> 
>>>>> -- I.e. the default for IPv4 size is 15, if that gets changed [ not
>>>>> currently set in config ] does that cause a reboot?
>>>>> 
>>>>> Also, is 15 the maximum aggregate or is it per table:
>>>>> 
>>>>> -- Can you have 15 units assigned to IPv4 and IPv6 at the same time? or,
>>>>> is 15 the maximum between the two?
>>>>> 
>>>>> Thanks!
>>>>> -SH
>>>>> 
>>>>> ___
>>>>> 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] ipv4/ipv6-flow-table-size

[Scott Granados]

Here’s a bit more that I received that may help clear things up.


Scott,

A total of 4M flows can be created per 1 LU chip. Now it depends on the size 
that we allocate to ipv4-flow-table size,ipv6-flow-table-size and 
vpls-flow-table-size. 
If only ipv4 template is to be used, then all the memory on the pfe could be 
reserved only for the ipv4 family.

For eg:  if 15 is allocated for IPv4 then total flows that can be created = 
15*256*1024 = 3932160 and 1k IPv6 flows and 1K vpls flows (default).
Each unit in flow hash table size corresponds to memory size of 256k (256x1024).

In your case, 
flow-table-size for ipv4 = 5, Total-flows that can be created = 5*256*1024 = 
1310720
you are exporting @ 7k flows/sec to the flow-collector
If all of your traffic belongs to ipv4: Number of flows getting created = 
7*1024*10 = 71680 flows/sec [ 10 = number of flow-records per 1 packet sent to 
flow-collector ]


On Aug 25, 2014, at 3:56 PM, Scott Harvanek  wrote:

> Scott,
> 
> Thanks, my next question then with that is - how/why is the default of 
> ipv4 15 and ipv6 1?  That would break that constraint of 15 total?
> 
> Scott H.
> Login Inc.
> 
> On 8/25/14, 3:53 PM, Scott Granados wrote:
>> When ever you set the flow table size you initiate a reboot of the FPC.  The 
>> table size is a combined value of v4 and v6 so 15 total a subset of which is 
>> IPV4 and the remainder is IPV6.
>> 
>> Thanks
>> Scott
>> 
>> On Aug 25, 2014, at 3:02 PM, Scott Harvanek  wrote:
>> 
>>> I'm wondering if anyone can clarify something for me from docs:
>>> 
>>> "
>>> 
>>>  * Any change in the configured size of flow hash table sizes initiates
>>>an automatic reboot of the FPC.
>>>  * The total number of units used for both IPv4 and IPv6 cannot exceed 15.
>>> 
>>> "
>>> 
>>> - Does the initial config entry of ipv4/ipv6-flow-table-size cause the
>>> FPC to reboot or only if the configured value is changed?
>>> 
>>> -- I.e. the default for IPv4 size is 15, if that gets changed [ not
>>> currently set in config ] does that cause a reboot?
>>> 
>>> Also, is 15 the maximum aggregate or is it per table:
>>> 
>>> -- Can you have 15 units assigned to IPv4 and IPv6 at the same time? or,
>>> is 15 the maximum between the two?
>>> 
>>> Thanks!
>>> -SH
>>> 
>>> ___
>>> 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] ipv4/ipv6-flow-table-size

[Scott Granados]

I have a good mail from Juniper that explains this which I’ll try to locate but 
basically as I recall there’s 15 assignable tables that can be split between 
the two and then there’s one remainder which is the container for vpls etc.  

On Aug 25, 2014, at 3:56 PM, Scott Harvanek  wrote:

> Scott,
> 
> Thanks, my next question then with that is - how/why is the default of 
> ipv4 15 and ipv6 1?  That would break that constraint of 15 total?
> 
> Scott H.
> Login Inc.
> 
> On 8/25/14, 3:53 PM, Scott Granados wrote:
>> When ever you set the flow table size you initiate a reboot of the FPC.  The 
>> table size is a combined value of v4 and v6 so 15 total a subset of which is 
>> IPV4 and the remainder is IPV6.
>> 
>> Thanks
>> Scott
>> 
>> On Aug 25, 2014, at 3:02 PM, Scott Harvanek  wrote:
>> 
>>> I'm wondering if anyone can clarify something for me from docs:
>>> 
>>> "
>>> 
>>>  * Any change in the configured size of flow hash table sizes initiates
>>>an automatic reboot of the FPC.
>>>  * The total number of units used for both IPv4 and IPv6 cannot exceed 15.
>>> 
>>> "
>>> 
>>> - Does the initial config entry of ipv4/ipv6-flow-table-size cause the
>>> FPC to reboot or only if the configured value is changed?
>>> 
>>> -- I.e. the default for IPv4 size is 15, if that gets changed [ not
>>> currently set in config ] does that cause a reboot?
>>> 
>>> Also, is 15 the maximum aggregate or is it per table:
>>> 
>>> -- Can you have 15 units assigned to IPv4 and IPv6 at the same time? or,
>>> is 15 the maximum between the two?
>>> 
>>> Thanks!
>>> -SH
>>> 
>>> ___
>>> 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] ipv4/ipv6-flow-table-size

[Scott Granados]

When ever you set the flow table size you initiate a reboot of the FPC.  The 
table size is a combined value of v4 and v6 so 15 total a subset of which is 
IPV4 and the remainder is IPV6.

Thanks
Scott

On Aug 25, 2014, at 3:02 PM, Scott Harvanek  wrote:

> I'm wondering if anyone can clarify something for me from docs:
> 
> "
> 
>  * Any change in the configured size of flow hash table sizes initiates
>an automatic reboot of the FPC.
>  * The total number of units used for both IPv4 and IPv6 cannot exceed 15.
> 
> "
> 
> - Does the initial config entry of ipv4/ipv6-flow-table-size cause the 
> FPC to reboot or only if the configured value is changed?
> 
> -- I.e. the default for IPv4 size is 15, if that gets changed [ not 
> currently set in config ] does that cause a reboot?
> 
> Also, is 15 the maximum aggregate or is it per table:
> 
> -- Can you have 15 units assigned to IPv4 and IPv6 at the same time? or, 
> is 15 the maximum between the two?
> 
> Thanks!
> -SH
> 
> ___
> 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] Full BGP table, one provider w/ 2 routers, slow forwarding convergence

[Scott Granados]

I can confirm with inline flow sampling enabled and even with the code to fix 
the PR convergence is still slower.  I hear there’s a better fix being released 
in later code 14.2 if memory serves but I’m not sure.

On Aug 22, 2014, at 5:13 AM, Euan Galloway 
 wrote:

> On Thu, Aug 21, 2014 at 03:38:32PM -0400, Clarke Morledge wrote:
> 
>> I did upgrade to 13.3R3 to try to resolve PR963060, but I am still seeing 
>> enough traffic loss that it makes me skeptical as to whether I have really 
>> hit this PR, if the issue has not really been resolved, or if something 
>> else is going on.   I still think Junos should converge faster.
> 
> Did you try disabling inline jflow (and sampling if used), which would answer 
> the is it/isn't it on that PR (and someone/something to shout at).
> 
> -- 
> Euan Galloway
> ___
> 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] Using the FXP for flow sources

[Scott Granados]

So the interesting thing is I had opened a ticket to ask this same question and 
I got a totally opposite answer.:)

I guess the best thing to do here is after hours today test out the config and 
see how it goes.  Else spin up another 3600 in the lab and give it a run 
through.  Your answer makes a lot more sense to me but that’s me.  I also 
appreciate the impact of sampling on the RE.  That makes sense since the work 
isn’t punted to the PFE like in the case of the MX hardware.


On Aug 21, 2014, at 1:53 PM, Tyler Christiansen 
mailto:ty...@adap.tv>> wrote:

No problem.

Just keep in mind that with the RE processing flow data, you can quickly kill 
your RE if your sampling rate is too low.  1:1 sampling with the MX isn't as 
problematic since it's processed by the PFE.

--tc


On Thu, Aug 21, 2014 at 10:47 AM, Scott Granados 
mailto:sc...@granados-llc.net>> wrote:
This makes sense to me.  Thanks for such a good response I really feel like I 
have a better bead on this now.

Thanks
Scott

On Aug 21, 2014, at 1:43 PM, Tyler Christiansen 
mailto:ty...@adap.tv>> wrote:

This is platform-dependent.  Some platforms (definitely EX, probably SRX) use 
the RE for processing flow data--so you can use fxp0.  Other platforms (MX) use 
the PFE, which is why fxp0 is not a valid interface.

I did some testing on this a few months ago to confirm that EX switches (at 
least 3200, 3300, 4200, 4500, and 4550) use RE and MX uses PFE.  I think I 
tested our SRX550, too, and saw that it used RE.  I honestly don't recall the 
results of the SRX test, though.

You can find out pretty easily--if you enable it and you can see flow traffic 
using tcpdump on the SRX (or monitor traffic), it's handled by the RE.  If you 
_don't_ see flow data (but you know it's actually being sent), it's handled by 
the PFE.

--tc


On Thu, Aug 21, 2014 at 10:09 AM, Scott Granados 
mailto:sc...@granados-llc.net>> wrote:
Hi,
So I’m still a bit confused on what can or can’t be used in the flow 
monitoring processes.  In this case I have an SRX 3600 with a routing instance. 
 I found a config example that illustrates how to enable flow sampling in this 
type of environment.  It specifically mentions that you use a source IP with in 
the global routing table and not the instance.  In my case the only interface I 
have in the global instance is fxp0.0 (management).  I have read in the case of 
the MX you can’t use the management interface asa flow source.  I haven’t been 
able to find anything regarding the SRX.  Is FXP0 a valid source for flow 
monitoring or do I need to create another interface, maybe a loopback, with in 
the global instance?  Also, is there a good document that details better the 
limitations of flow monitoring on the SRX.  I’ve found some bits and pieces but 
nothing centralized.  Any pointers would be most appreciated.

Thanks
Scott


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



--
[https://adap.tv/sigs/logo.png]
Tyler Christiansen | Technical Operations
tyler<http://adap.tv/>@adap.tv<http://adap.tv/> | 
www.adap.tv<http://www.adap.tv/>
m : 864.346.4095




--
[https://adap.tv/sigs/logo.png]
Tyler Christiansen | Technical Operations
tyler<http://adap.tv/>@adap.tv<http://adap.tv/> | 
www.adap.tv<http://www.adap.tv/>
m : 864.346.4095

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

Re: [j-nsp] Using the FXP for flow sources

[Scott Granados]

This makes sense to me.  Thanks for such a good response I really feel like I 
have a better bead on this now.

Thanks
Scott

On Aug 21, 2014, at 1:43 PM, Tyler Christiansen 
mailto:ty...@adap.tv>> wrote:

This is platform-dependent.  Some platforms (definitely EX, probably SRX) use 
the RE for processing flow data--so you can use fxp0.  Other platforms (MX) use 
the PFE, which is why fxp0 is not a valid interface.

I did some testing on this a few months ago to confirm that EX switches (at 
least 3200, 3300, 4200, 4500, and 4550) use RE and MX uses PFE.  I think I 
tested our SRX550, too, and saw that it used RE.  I honestly don't recall the 
results of the SRX test, though.

You can find out pretty easily--if you enable it and you can see flow traffic 
using tcpdump on the SRX (or monitor traffic), it's handled by the RE.  If you 
_don't_ see flow data (but you know it's actually being sent), it's handled by 
the PFE.

--tc


On Thu, Aug 21, 2014 at 10:09 AM, Scott Granados 
mailto:sc...@granados-llc.net>> wrote:
Hi,
So I’m still a bit confused on what can or can’t be used in the flow 
monitoring processes.  In this case I have an SRX 3600 with a routing instance. 
 I found a config example that illustrates how to enable flow sampling in this 
type of environment.  It specifically mentions that you use a source IP with in 
the global routing table and not the instance.  In my case the only interface I 
have in the global instance is fxp0.0 (management).  I have read in the case of 
the MX you can’t use the management interface asa flow source.  I haven’t been 
able to find anything regarding the SRX.  Is FXP0 a valid source for flow 
monitoring or do I need to create another interface, maybe a loopback, with in 
the global instance?  Also, is there a good document that details better the 
limitations of flow monitoring on the SRX.  I’ve found some bits and pieces but 
nothing centralized.  Any pointers would be most appreciated.

Thanks
Scott


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



--
[https://adap.tv/sigs/logo.png]
Tyler Christiansen | Technical Operations
tyler<http://adap.tv/>@adap.tv<http://adap.tv/> | 
www.adap.tv<http://www.adap.tv/>
m : 864.346.4095

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

[j-nsp] Using the FXP for flow sources

[Scott Granados]

Hi,
So I’m still a bit confused on what can or can’t be used in the flow 
monitoring processes.  In this case I have an SRX 3600 with a routing instance. 
 I found a config example that illustrates how to enable flow sampling in this 
type of environment.  It specifically mentions that you use a source IP with in 
the global routing table and not the instance.  In my case the only interface I 
have in the global instance is fxp0.0 (management).  I have read in the case of 
the MX you can’t use the management interface asa flow source.  I haven’t been 
able to find anything regarding the SRX.  Is FXP0 a valid source for flow 
monitoring or do I need to create another interface, maybe a loopback, with in 
the global instance?  Also, is there a good document that details better the 
limitations of flow monitoring on the SRX.  I’ve found some bits and pieces but 
nothing centralized.  Any pointers would be most appreciated.

Thanks
Scott


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

Re: [j-nsp] flow sampling on redundant ethernet on Branch SRX?

[Scott Granados]

Hi, so I opened a ticket with TAC to confirm and it appears this is correct.  
Flow sampling is supported on what they call “high end SRX” but not on Branch 
SRX.  The work around they suggested is I enable port mirroring on the switches 
and forward to a collector (I would assume something like an NCAP instance).  
Sounds like a lot of work to work around something that should be included but 
that could be over simplifying the problem on my part.

Thanks for the response.



On Aug 20, 2014, at 2:21 PM, Mike Gonnason  wrote:

> It seems like you can do it on Data Center SRX devices, but not branch.
> 
> http://forums.juniper.net/t5/SRX-Services-Gateway/RETH-interfaces-on-branch-SRX-clusters-and-jFlow/td-p/253211
> 
> I cannot find a workaround for this limitation, still seems to be present
> in 12.1x46
> 
> http://www.juniper.net/techpubs/en_US/junos12.1x46/information-products/topic-collections/release-notes/12.1x46/junos-release-notes-12.1X46.pdf
> 
> 
> 
> On Wed, Aug 20, 2014 at 10:55 AM, Scott Granados 
> wrote:
> 
>> Hi, another SRX flow related question.
>> 
>> Doing some googling it appears that you can’t sample flow data on RETH
>> (redundant ethernet) interfaces.
>> 
>> example
>> set interfaces RETH0.30 family inet sampling input
>> 
>> Is there a work around for this?  should I sample on the redundant member
>> interfaces or is this just a no go entirely.
>> 
>> What if any work around is there for this type of sampling?
>> 
>> Thanks
>> Scott
>> 
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] flow sampling on redundant ethernet on Branch SRX?

[Scott Granados]

I enabled on a branch SRX 550 and so far it’s not sending data at all.  Kind of 
a squerrely limitation but there it is.  Thanks for the confirmation.

On Aug 20, 2014, at 3:14 PM, Tyler Christiansen  
wrote:

> I can confirm it works on DC devices. We also did it on branch at last job, 
> but YMMV.
> 
> On Wed, Aug 20, 2014 at 11:30 AM, Mike Gonnason 
> wrote:
> 
>> It seems like you can do it on Data Center SRX devices, but not branch.
>> http://forums.juniper.net/t5/SRX-Services-Gateway/RETH-interfaces-on-branch-SRX-clusters-and-jFlow/td-p/253211
>> I cannot find a workaround for this limitation, still seems to be present
>> in 12.1x46
>> http://www.juniper.net/techpubs/en_US/junos12.1x46/information-products/topic-collections/release-notes/12.1x46/junos-release-notes-12.1X46.pdf
>> On Wed, Aug 20, 2014 at 10:55 AM, Scott Granados 
>> wrote:
>>> Hi, another SRX flow related question.
>>> 
>>> Doing some googling it appears that you can’t sample flow data on RETH
>>> (redundant ethernet) interfaces.
>>> 
>>> example
>>> set interfaces RETH0.30 family inet sampling input
>>> 
>>> Is there a work around for this?  should I sample on the redundant member
>>> interfaces or is this just a no go entirely.
>>> 
>>> What if any work around is there for this type of sampling?
>>> 
>>> Thanks
>>> Scott
>>> 
>>> 
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

[j-nsp] flow sampling on redundant ethernet on Branch SRX?

[Scott Granados]

Hi, another SRX flow related question.

Doing some googling it appears that you can’t sample flow data on RETH 
(redundant ethernet) interfaces.

example
set interfaces RETH0.30 family inet sampling input

Is there a work around for this?  should I sample on the redundant member 
interfaces or is this just a no go entirely.

What if any work around is there for this type of sampling?

Thanks
Scott


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

Re: [j-nsp] Are there any conditions where a forwarding engine will reboot on a Branch SRX when enabling netflow?

[Scott Granados]

Now sample rate doesn’t impact inline sampling does it?  The KB example uses a 
1:1 rate which is what I use on my MXs but I know that’s a different animal.  
Is this an incorrect assumption on my part and I need to go with a much less 
granular rate?

Thanks
Scott

On Aug 20, 2014, at 12:56 PM, Morgan McLean 
mailto:wrx...@gmail.com>> wrote:

I've never had an issues when enabling flow sampling, just make sure the sample 
rate isn't too heavy as the branch firewalls are a bit dinky.

Thanks,
Morgan


On Wed, Aug 20, 2014 at 9:47 AM, Scott Granados 
mailto:sc...@granados-llc.net>> wrote:
Hi, the title just about sums it up but the details are this.  I have several 
different offices with various sized SRX firewalls.  I am enabling inline flow 
sampling on each per the Juniper KB article.  It doesn’t mention any possible 
reboots like you get when enabling inline sampling on an MX.  In the MX case 
the PFE reboots to reprogram the table size.  In the SRX there’s no table size 
set and appears no reboots but I want to confirm that before I start dropping 
configs during business hours.  Any pointers would be appreciated.  I don’t see 
anything while googling but wanted to make sure from the experts here.  Any 
comments would be most appreciated.

Thank you
Scott


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


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

[j-nsp] Are there any conditions where a forwarding engine will reboot on a Branch SRX when enabling netflow?

[Scott Granados]

Hi, the title just about sums it up but the details are this.  I have several 
different offices with various sized SRX firewalls.  I am enabling inline flow 
sampling on each per the Juniper KB article.  It doesn’t mention any possible 
reboots like you get when enabling inline sampling on an MX.  In the MX case 
the PFE reboots to reprogram the table size.  In the SRX there’s no table size 
set and appears no reboots but I want to confirm that before I start dropping 
configs during business hours.  Any pointers would be appreciated.  I don’t see 
anything while googling but wanted to make sure from the experts here.  Any 
comments would be most appreciated.

Thank you
Scott


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

Re: [j-nsp] Viability of EX4300 in a primarily l3 environment?

[Scott Granados]

+1 on the 4200.

Had very good luck with the 4200 series.  Also had good luck with the 4300 but 
there were some bugs.  In a basic operation mode though they are quite stable.  
That being said I was really pleased with the 4200 and you might want to check 
them out assuming the lower arp limit isn’t an issue.
 

On Aug 6, 2014, at 7:30 AM, Yucong Sun  wrote:

> I used ex4200 to do exactly what you did before.  ex4200 releases is pretty
> rock solid, feature extensive, although with lower arp entry limits.
> 
> Given the price difference maybe you can connect each l2 domain to its own
> ex4200 and have them do ospf routing among selves, which maybe give you
> better failure tolerances compare to a single core.
> 
> 
> On Wed, Aug 6, 2014 at 6:35 PM, Giuliano Cardozo Medalha <
> giuli...@wztech.com.br> wrote:
> 
>> we are using ex4300 with the last release available
>> 
>> the setup is pretty simple using virtual chassis, lag, L3 and poe
>> 
>> it works pretty fine and we do not have any serious problems
>> 
>> sometimes the poe controller goes down but we have a case oppened in jtac
>> to try solve it
>> 
>> Sent from my iPhone
>> 
>>> On 06/08/2014, at 07:15, Sebastian Wiesinger 
>> wrote:
>>> 
>>> * Paul S.  [2014-08-02 05:18]:
 Hi folks,
 
 We're considering the EX4300 to run routing (l3) for a few
 hypervisors of ours that are connected via l2.
 
 Primarily interested due to the rather massive arp limit (64, 000)
 on the switch, but we've been told (and searched for ourselves to
 find out) that the 4300 platform has been plagued by random issues
 since launch.
>>> 
>>> I don't have hands-on experience but I looked at the EX4300 platform
>>> for a new deployment. If you look at the current release notes:
>>> 
>>> 
>> http://www.juniper.net/techpubs/en_US/junos13.2/information-products/topic-collections/ex-qfx-series/release-notes/ex-qfx-series-junos-release-notes-13.2X51-D25.pdf
>>> 
>>> There are a lot of (serious) bugs still getting fixed so I'm not sure
>>> how mature this platform is. One big reason for that is probably
>>> because EX4300 uses other chips than the rest of the 4xxx series
>>> (Broadcom).
>>> 
>>> Regards
>>> 
>>> Sebastian
>>> 
>>> --
>>> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
>>> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
>> SCYTHE.
>>>   -- Terry Pratchett, The Fifth Elephant
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] MX80 stops forwarding after enabling inline flow sampling

[Scott Granados]

I found more to bring this thread home.

The problem I had was covered in PR963060.  
Basically, a condition would take place where the sampled process would 
block the programming of the PFE and would break forwarding.  Lots of kernel 
veto messages were recorded in the log and the path from the RE to the PFE was 
blocked.  Several releases are available with the fix in place.

Thanks
Scott



On Jul 10, 2014, at 12:19 PM, Justin M. Streiner  
wrote:

> On Wed, 9 Jul 2014, Scott Granados wrote:
> 
>>  I have an interesting problem.  I have an MX80 where I wish to 
>> enable inline flow sampling.  I used the kb entry as a template and 
>> configured.  When setting the table size the PFE rebooted which is 
>> expected but when it came back online forwarding stopped.  I rebooted 
>> again and had the same issue with the exception of after about 20 
>> minutes forwarding started to work.  Looking at the logs there seemed 
>> to be throttles from the kernel to the PFE and issues that look like 
>> ipsec trying to find a phase 2 policy that might have been causing the 
>> delay.  However, ipsec isn’t enabled on this box and there is an actual 
>> ACL that should block ipsec sessions from establishing so I think this 
>> might be a false signal.  Anyone ever see this sort of long delay or 
>> have any ideas where I should look further.  I’ve engaged TAC but am 
>> looking for things to test in the mean time independently.  Anyone seen 
>> this before or have any ideas?
> 
> What version of code are you running?  I haven't seen this problem, but I 
> don't have any MX80s specifically. I haven't seen this behavior on a pair 
> of MX480s running 12.3R6.6.
> 
> I have a pair of MX5s I could test with, but I havne't had a chance to get 
> them set up in our lab yet.
> 
> jms


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

[j-nsp] MX80 stops forwarding after enabling inline flow sampling

[Scott Granados]

Hi,
I have an interesting problem.  I have an MX80 where I wish to enable 
inline flow sampling.  I used the kb entry as a template and configured.  When 
setting the table size the PFE rebooted which is expected but when it came back 
online forwarding stopped.  I rebooted again and had the same issue with the 
exception of after about 20 minutes forwarding started to work.  Looking at the 
logs there seemed to be throttles from the kernel to the PFE and issues that 
look like ipsec trying to find a phase 2 policy that might have been causing 
the delay.  However, ipsec isn’t enabled on this box and there is an actual ACL 
that should block ipsec sessions from establishing so I think this might be a 
false signal.  Anyone ever see this sort of long delay or have any ideas where 
I should look further.  I’ve engaged TAC but am looking for things to test in 
the mean time independently.  Anyone seen this before or have any ideas?

Thanks
Scott


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

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

[Scott Granados]

Wow, peeks and pokes, I feel like I woke up in 1982 with an Apple 2E.:)
Good times.


On Jun 24, 2014, at 9:17 AM, Chuck Anderson  wrote:

> On Wed, Jun 11, 2014 at 03:49:16PM +0100, Phil Mayers wrote:
>> On 11/06/14 15:01, Chuck Anderson wrote:
>> 
>>> Jun 10 11:40:54  ex4200 chassism[1293]: XCVR: Unit 0, SFP+ of type 0 EEPROM 
>>> is Mis Programmed!!
>> 
>> Yeah, this was the one that caught my eye. I wonder if it's choking
>> on unknown values in the EEPROM.
> 
> After much investigation, and thanks to Juniper not locking down
> access to the internal debugging tools on JUNOS, I was able to
> determine that bytes 3-10 of the SFP ID EEPROM of optic I'm using are
> coded as all 0's.  My reading of the SFF-8472 MSA says that this is
> invalid:
> 
> "Transceiver Compliance Codes [Address A0h, Bytes 3-10]
> 
> The following bit significant indicators define the electronic or
> optical interfaces that are supported by the transceiver. At least one
> bit shall be set in this field."
> 
> The top half of byte 3 is defined as follows, and I would expect any
> MSA Ethernet optic to have at least one of these bits set, even
> CWDM/DWDM optics:
> 
> ByteBitDescription
> 3   7  10G Base-ER
> 3   6  10G Base-LRM
> 3   5  10G Base-LR
> 3   4  10G Base-SR
> 
> My optic vendor doesn't agree and says that those bits only refer to
> "grey" optics--standard wavelengths 850nm or 1310nm, and says that it
> is VALID to have no bits set all all in bytes 3-10.  I'm guessing that
> the SFP driver in EX4200 doesn't like this, but the one in MX doesn't
> care.
> 
> I tried changing the values using "xcvrpeek" and "xcvrpoke" (and
> "i2cpeek"/"i2cpoke").  Reads work fine, writes fail with -EIO in dmesg
> and the values don't change when read back.  I guess the optic is
> "locked" from writing changes to the EEPROM without some sort of OEM
> password or something.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

[j-nsp] Quewstion about IP flow table size for inline flow sampling

[Scott Granados]

Hi,
I am presently using inline flow sampling on a series of MX480s.  There 
is an IP table that can be set from 1 to 15 and is based in multiples of 256.  
I’m not sure how to calculate my IPv4 table size.  It’s presently set to 5 per 
the KB article but I’m wondering if this is correct.  I’m presently exporting 
about 7K flows per second and could theoretically burst much higher than that 
if the CDN in front of my content were to go away or change.  What’s a rule of 
thumb for calculating the correct table size.  Suppose I want to scale say from 
7K to 21K flows per second how would I pick the correct table value / what’s 
the calculation I do to find that value.  Any pointers would be most 
appreciated.

Thanks
Scott


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

Re: [j-nsp] Redundant RE setup useful?

[Scott Granados]

I have seen one of the RE modules fail and the backup saved our bacon.  There 
was a bad batch of SSD drive components that caused issues and the card to 
crash.  I’ve also seen an upgrade fail and the disk not format correctly 
rendering the card useless.  Again very remote possibility of happening to you 
but possible.

On Jun 23, 2014, at 4:07 AM, Joerg Staedele  wrote:

> Hi there,
> 
> i am asking myself if it really makes sense to have a redundant RE setup in M 
> and MX-series. Maybe some of you could tell me if they had a scenario where 
> it really helped to prevent an outage.
> 
> I am not talking about ISSU/NSSU feature where it is needed.
> 
> We didn't have a failed RE since years so for now all our redundant setups 
> seem not make any sense at all.
> 
> What are your experiences?
> 
> Regards,
> Joerg
> 
> 
> ___
> 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 apparently dropping IPv6 RA

[Scott Granados]

I thought that was standard operating procedure for the systems guys to blame 
the network?

:)

On Jun 17, 2014, at 1:59 PM, Morgan McLean  wrote:

> If I had a dollar for every time the systems guys changed something and
> then cried to neteng... :)
> 
> Thanks,
> Morgan
> 
> 
> On Mon, Jun 16, 2014 at 7:11 AM, John Neiberger 
> wrote:
> 
>> This all turned out to be a false alarm. Someone on the server team had
>> changed the configuration on all the servers such that they were ignoring
>> RAs from the MX960. Everyone thought the EX4550 wasn't passing the RAs
>> because the filter they used to catch them wasn't apparently catching them.
>> The counters for ND/NS were incrementing but the counters for RA/RS were
>> not. The RAs clearly are passing through the EX4550, but for whatever
>> reason, the filter isn't counting them. The server issue has been corrected
>> and everything is working now.
>> 
>> Thanks,
>> John
>> 
>> 
>> On Mon, Jun 16, 2014 at 6:31 AM, Benoit Plessis 
>> wrote:
>> 
>>> Hi,
>>> 
>>> It won't help you i fear but i did see exactly the same defect on some
>>> other concurrent platform (cisco 3560G).
>>> 
>>> With the latest IOS software (15.x) a 3560G unit in L3 mode does
>>> correctly send RA and reply to RS, but the same
>>> unit in L2 mode between a router and a server fail to deliver RA/RS
>>> messages ...
>>> "Normal" IPv6 trafic correctly flow thru the 3560G in L2 however.
>>> 
>>> Downgrading the L2 unit to a 12.xx release did solve the problem, and
>>> also did replacing the 3560G
>>> by a 2960G even in IOS 15.
>>> 
>>> Looks like some packet handling code isn't correctly de-activated.
>>> 
>>> 
>>> Le 16/06/2014 07:23, John Neiberger a écrit :
 This does seem to be specific to RA/RS. I haven't been involved in
 troubleshooting over the weekend but the updates I read said that they
>>> took
 some packet captures of RA messages from the Cisco 7600 that the switch
 used to be connected to and compared them with captures taken from the
 MX960. They found some differences and adjusted to the configuration to
 make them the same, but that still did not resolve the problem. The
>> issue
 has been escalated with Juniper. Last I read, no one really has any
>> idea
 yet what is going on. They've got an action plan for tomorrow, so I'll
>>> know
 more after a meeting in the morning. Sure seems awfully funky, though.
>>> JTAC
 seems to be at a loss to explain what is happening.
 
 Thanks,
 John
 
 
 On Sun, Jun 15, 2014 at 5:22 AM, Phil Mayers 
 wrote:
 
> On 14/06/14 22:24, John Neiberger wrote:
> 
> The EX4550 is just layer two. There is no routing configured on it,
>> so
>>> it
>> should just be passing the RAs from the router to the hosts on the
>>> second
>> switch, but that doesn't seem to be happening.
>> 
> Is it RA/RS specific, or is forwarding to fe80::1 and related groups
> broken?
> 
> 
> Have any of you ever seen anything quite like this?
> On other platforms, I've seen IPv6 link-local multicast fail to flow
>> as
> some tiny table, sized with IPv4 assumptions, overflowed.
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
>>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Question about inline flow sampling on MX 480 / Treo based interfaces

[Scott Granados]

So that’s what the book says but the sample rate does seem to have an effect.  
I found some previous threads on this list while googling and they indicate 
that when changing the sample rate the multipliers change on the collector but 
there’s some question about the 1:1 as the only supported rate.  I’m mainly 
just wanting to make sure if I set 1:1 I won’t blow up the boxes.:)

I’m getting more confused the more I google so hopefully we can get some 
definitive answer.


On Jun 11, 2014, at 11:40 AM, Eric Van Tol  wrote:

>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>> Of Scott Granados
>> Sent: Wednesday, June 11, 2014 11:13 AM
>> To: juniper-nsp@puck.nether.net
>> Subject: [j-nsp] Question about inline flow sampling on MX 480 / Treo
>> based interfaces
>> 
>> What's the story on this and are there any
>> pointers to methods of determining the best most granular rate possible?
>> Any help would be most appreciated.
>> 
> 
> It's my understanding that the sample rate has no effect when inline sampling 
> is being done.  It can be configured, but sampling is performed on a 1:1 
> ratio no matter what.  Someone please correct me if I'm wrong.
> 
> -evt
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


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

[j-nsp] Question about inline flow sampling on MX 480 / Treo based interfaces

[Scott Granados]

Hi, 
I am configuring flow sampling for traffic analysis on several MX480 
routers with Treo based cards.  Right now I have the sample rate set to 1:1000 
and things are working / flow data is being generated.  My question is is there 
a rule of thumb or guideline to what sample rate is safe to use with out 
impacting forwarding performance?  I have read some 3rd party articles that 
indicate that 1:1 sampling is possible and that the sample rate won’t impact 
negatively performance when inline flow is used and have read others that 
indicate this is not the case and one has to carefully select a rate.  What’s 
the story on this and are there any pointers to methods of determining the best 
most granular rate possible?  Any help would be most appreciated.

Thanks
Scott


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