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

[Chris Kawchuk via juniper-nsp]

Shall we start taking bets on what stays, and what goes? 

Here’s my List:

Stays:
PE/Edge Routing (MX/Trio) - Stays and continues development. Reasons stated 
already in this thread. It’s the Swiss army knife to solve 
$things-you-didn’t-even-know-you-needed-to-do for some future corner case, and 
is a market leader.
P/Core Routing (PTX/Express) - Stays, mainly as it’s also a good border router 
too. Lots of DC people using it for massive eBGP at scale, but don’t need the 
HQoS and Subscriber-y stuff that MX can do. 
DC Switching (QFX/Trident) - Stays - Nice product HPE can sell to enterprise 
customers. QFabric lives again in new forms (I'm looking at you VCF). Cheap and 
cheerful high speed switching doesn’t go out of style.

Questionable:
EX - Does it make sense to have EX and QFX? or roll them into one? Dunno. I 
like them when "i just need a switch there” which doesn’t sound like a Boeing 
747 on takeoff. I’d like it to stay.
SRX - HPE can have a good security story now, but SRX needs an uplift versus 
what competitor’s NGFWs are up to these days (and no, Contrail isn’t the answer)

So — where does that leave ACX (Jericho2/2c+/Qumran)? My suspicions HPE says 
“What is this metro-E eVPN/VPWS MPLS aggregation stuff?". It doesn’t address 
any Enterprise solution for HPE that I can think of that couldn’t be covered by 
QFX/EX. It also is lagging behind Cisco NCS5700/NCS540 in both product 
maturity, and product breadth. i.e. If you want a nice small MPLS/SR capable 
pizza box that various form factors, power draw, faceplates, PFE speed, 
physical depth and size, etc... theres an NCS540 already built that does that. 
Contrast with… ACX7024 and the 7100. Basically 2 form factors from JNPR 
versus.. 12-15 different NCS540 and umpteen NCS5700 models and variants.

Again, ACX was never a competitor to the ASR920 which I know Mr Tinka was very 
fond of. And the NCS540 "is the new ASR920”. There’s some long roads ahead for 
JNPR to wrestle back some of that marketshare.

ACX also did a ‘reboot’ of the product line in the 7000-series when they went 
Jericho, versus ACX5000 which (correct me if I’m wrong) that was 
QFX/Trident/Trident+ based and earlier ACX series which were 
$no-idea-i-didnt-look-very-hard-at-them…. so its almost “a new product” which 
may not have a lot of customer nor market traction; thus easier to kill off. 
Yes — even though previous generations of ACX did exist and likely had some 
customers..somewhere…., I know of absolutely nobody that bought them nor used 
them in anger for a large Metro-E/MPLS/eVPN/SR network role.

I'm happy to be proven wrong on ACX; as I don’t like the idea of handing an 
entire market segment to a single vendor.

My $0.02

- CK.



> On 11 Jan 2024, at 9:15 am, Richard McGovern via juniper-nsp 
>  wrote:
> 
> #1 jewel HPE (Aruba) is interested in is Juniper/MIST AI. MIST AI and ML is 
> also being integrated into many other facets of Juniper, one being Apstra. 
> See this in announcement - 
> https://www.barrons.com/articles/cisco-stock-arista-juniper-hp-enterprise-acquisition-b94d6024
>  
> 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory - Resolved

[Chris Kawchuk via juniper-nsp]

Indeed. Apologies to all --- I too got an update from JNPR on the "show route" 
vs "show routing" CLI conflict a few weeks ago in early September -- but forgot 
to share it here.


CASE;
2023-0719-733950

Synopsis: 
"show route" and "show routing" operational mode CLI conflict - JunOS 21+

Root Cause:
"show routing" CLI stanza was unhidden to implement "show routing 
transport-class" command for BGP CT (in JunOS 21+)

Resolution: 
For finger memory convenience, hiding 'show routing' stanza again, and moving 
BGP CT command to under 'show route' stanza.
Understanding is: "show route" will now contain both:
- route table related information, AND
- routing daemon related information. 


-

Looks like it's a win for the little guy!.. or at least... my little finger 
that wants to smash that [TAB] key early

- CK.



> On 19 Oct 2023, at 15:11, Mark Tinka via juniper-nsp 
>  wrote:
> 
> 
> 
> On 10/18/23 19:05, Chris Wopat via juniper-nsp wrote:
> 
>> Only complaint is Junos related, with auto tab complete problems as
>> extensively discussed in a different thread.
> 
> I have an update on that...
> 
> Our request was granted, and Juniper are initially targeting to fix this in 
> Junos 24.1. However, there are ongoing discussions to introduce this into 
> 23.3R2.
> 
> So we may soon see the back of this.
> 
> 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

Re: [j-nsp] Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP peering Sessions?

[Chris Kawchuk via juniper-nsp]

FWIW -- We've asked for that feature now in any RFP/RFQs we send to the usual 
gang of $vendors.

Thats our method to get adoption, else they get a black-mark/non-comply in the 
[BGP section] when it comes time to score the responses.

- CK.



> On 27 Sep 2023, at 10:49, Barry Greene via juniper-nsp 
>  wrote:
> 
> Hi Team,
> 
> Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP 
> peering Sessions?
> 
> I’m not touching routers right now. I’m wondering if anyone has deployed, 
> your experiences, and thoughts?
> 
> This is suppose to be the “replacement” for BGP MD5, ‘but’ I’m hearing …..
> 
> 1. The Vendors are not supporting yet. Which means a lot of older systems 
> would not be able to support a BGP session with TCP-AO.
> 2. People have to tried is operationally.
> 
> Sharing you thoughts would be helpful …...
> 
> Thanks,
> 
> Barry
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

[Chris Kawchuk via juniper-nsp]

Hi Jeff

I'll open it with my SE here in Australia (Mark Barrett). Will advise once 
complete.

- CK.


> On Jul 19, 2023, at 01:24, Jeff Haas via juniper-nsp 
>  wrote:
> 
> 
> Juniper Business Use Only
> On 7/12/23, 12:11 PM, "Jeff Haas"  > wrote:
>> On 7/12/23, 11:46 AM, "Mark Tinka" mailto:m...@tinka.afri> 
>> >ca> wrote:
>>> Will any of these issues register significantly on Juniper's roadmap of
>>> how to make customers happier? Likely unlikely.
>> 
>> Cynically, money moves things the best.
>> 
>> But these comments don't fall on deaf ears. Occasionally, they fall on ears 
>> that just solve the problem. Sadly, for this one, that's not in my power to 
>> unilaterally address.
> 
> Apparently not unilaterally.
> 
> I am in need of someone with a current support contract to open a customer
> issue on the "show routing" collision and push for that issue to generate an
> internal PR.  Please unicast me the case#s.
> 
> No promises though.
> 
> -- 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] Junos 21+ Killing Finger Muscle Memory...

[Chris Kawchuk via juniper-nsp]

+1 Mark!

As any good problem begs for a solution, my suggestions to JNPR are as follows, 
as alternative places for this command:

"show route transport-class ..." (or really, is it even a routing thing? might 
be better w/the segment-routing or spring commands)i.e.:
"show segment-routing ..."
"show spring transport-class ."

...but whatever is done, please, for the love of 20+ years of finger-memory 
please do NOT make it conflict with "sh[TAB] rou[TAB]"

- CK.

(P.S. NOTE that since this new 'show' command is part of base JunOS 21 and 
above; it's also present on all EX, QFX, SRX, etc.. devices you would never 
ever think of ever running segment-routing on w/transport classes or colours, 
but that *do* have a basic routing table, so it's not just on PTX/ACX/EVO or 
MX/P/PE devices we run into this...)




> On Jul 12, 2023, at 18:49, Mark Tinka via juniper-nsp 
>  wrote:
> 
> So, this is going to be a very priviledged post, and I have been spending the 
> last several months mulling over even complaining about it either on here, or 
> with my SE.
> 
> But a community friend sent me the exact same annoyance he is having with 
> Junos 21 or later, which has given me a final reason to just go ahead and 
> moan about it:
> 
> tinka@router> show rout
>  ^
> 'rout' is ambiguous.
> Possible completions:
>   routeShow routing table information
>   routing  Show routing information
> {master}
> tinka@router>
> 
> I'm going to send this to my Juniper SE and AM. Not sure what they'll make of 
> it, as it is a rather priviledged complaint - but in truth, it does make 
> working with Junos on a fairly historically commonly used command rather 
> cumbersome, and annoying.
> 
> The smile that comes to my face when I touch a box running Junos 20 or 
> earlier and run this specific command, is unconscionably satisfying :-).
> 
> 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

Re: [j-nsp] JunOS RPKI/ROA database in non-default routing instance, but require an eBGP import policy in inet.0 (default:default LI:RI) to reference it.

[Chris Kawchuk via juniper-nsp]

Great idea! but no dice. :( didn't work. 

Seems the whole "VRF -> back to base table" operations that we'd all love to do 
easily in JunOS rears its ugly head yet again ;)  

FWIW - Some friends in the industry *do* use that knob, but they're "going the 
other way". i.e. The RPKI RV Database  is in inet.0 && Internet is in a VRF. 
Apparently that does work AOK for them; however it's "fiddly" as you say.

FWIW - here's the VRF's config... pretty darned basic.

routing-instances {
admin {
routing-options {
validation {
notification-rib [ inet.0 inet6.0 ];   ## << No impact on the 
default:default LI:RI RV database
group routinator {
session 10.x.x.x {
refresh-time 120;
port 3323;
}
}
}
}
description "Dummy admin vrf - to test RPKI inside a routing-instance";
instance-type vrf;
interface xe-0/0/3.0;   ## << the RPKI server is setting on the 
other end of this /30
vrf-target target::xxx;
}
}

FWIW using a vMX for testing - running JunOS 20.4R3-S4.8.

Basically i'm asking "is there a way to do this without having to stick the 
validator DB config into the basec onfig [routing-options validation {}] 
stanza? 

.If it must, then yeah, it's easy enough to do a rib group, a static /32 
next-table/no-readvertise/no-install, lt-x/x/x stitch, route leak, etc...to get 
the default:default instance to "use the VRF" to reach the RPKI server.  I just 
don't want to go down that road (yet) if I don't have to; as the 'technical 
elegance' (read: OCD) portion of my brain wants to avoid that if it can.

- CK.




> On Jun 5, 2023, at 13:12, David Sinn  wrote:
> 
> I'd try the 'notification-rib' chunk in the 'validation' stanza of the 
> routing-instance and see if setting inet.0 there pushes the DB the way you 
> need. Certain versions of JunOS are quite broken going the other way, so I've 
> had to enumerate all of the routing-instances that I want to be sure have a 
> copy of the validation DB to get them to work correctly. Maybe the other way 
> will work in your case.
> 
> David
> 
>> On Jun 4, 2023, at 7:52 PM, Chris Kawchuk via juniper-nsp 
>>  wrote:
>> 
>> Hi All
>> 
>> Been scratching my head today. As per Juniper's documentation, you can 
>> indeed setup RPKI/ROA validation session inside a routing-instance. You can 
>> also have it query against that instance on an import policy for that VRF 
>> specifically, and if there's no session, it will revert to the default RPKI 
>> RV database (if configured) under the main routing-options {} stanza to 
>> check for valid/invalid, etc...
>> 
>> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp_origin_validation.html
>> 
>> Thats all fine and dandy, but it seems that JNPR's implementation of 
>> RPKI/ROA *assumes* that your RV database is always configured in the main 
>> routing instance (i.e. the main routing-options validation {} stanza, thus 
>> your RPKI server MUST be available via inet.0 ). 
>> 
>> Unfortunately, the situation I am faced with is the opposite.
>> 
>> My RPKI/ROA server is only available via our "admin" VRF (which is how we 
>> manage the device) - Our inet.0 contains the global internet/IGP and links 
>> and loopbacks/Labels/etc. all "admin" related functions RADIUS/TACACS, SNMP, 
>> RPKI, Syslog, ssh, you-name-it, etc. are all "nailed" to our admin VRF. 
>> Hence when I try to do ROA validation of an eBGP peer in inet.0 via a 
>> standard import policy, the RV "validation-database" is unfortunately locked 
>> inside the admin-vrf, and thus isn't queried for valid/invalid/unknown etc. 
>> 
>> Hence, nothing on the eBGP session in inet.0 is being validated.
>> 
>> Is there some KNOB I'm missing, to allow a policy, executed upon routes in 
>> inet.0, to use the RV database in a non-default VRF? Or copy the VRF's RV to 
>> the default's RV? or is this some oversight of JNPR's RPKI implementation, 
>> that it must be inside the default:default LI:RI?
>> 
>> - CK.
>> 
>> 
>> NOTE: my Google-fu and/or "set ?" skills aren't yielding any useful results. 
>> Apologies if there's "a simple fix" for this, or an example of this 
>> situation I haven't found.
>> ___
>> 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] JunOS RPKI/ROA database in non-default routing instance, but require an eBGP import policy in inet.0 (default:default LI:RI) to reference it.

[Chris Kawchuk via juniper-nsp]

Hi All

Been scratching my head today. As per Juniper's documentation, you can indeed 
setup RPKI/ROA validation session inside a routing-instance. You can also have 
it query against that instance on an import policy for that VRF specifically, 
and if there's no session, it will revert to the default RPKI RV database (if 
configured) under the main routing-options {} stanza to check for 
valid/invalid, etc...

https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp_origin_validation.html

Thats all fine and dandy, but it seems that JNPR's implementation of RPKI/ROA 
*assumes* that your RV database is always configured in the main routing 
instance (i.e. the main routing-options validation {} stanza, thus your RPKI 
server MUST be available via inet.0 ). 

Unfortunately, the situation I am faced with is the opposite.

My RPKI/ROA server is only available via our "admin" VRF (which is how we 
manage the device) - Our inet.0 contains the global internet/IGP and links and 
loopbacks/Labels/etc. all "admin" related functions RADIUS/TACACS, SNMP, RPKI, 
Syslog, ssh, you-name-it, etc. are all "nailed" to our admin VRF. Hence when I 
try to do ROA validation of an eBGP peer in inet.0 via a standard import 
policy, the RV "validation-database" is unfortunately locked inside the 
admin-vrf, and thus isn't queried for valid/invalid/unknown etc. 

Hence, nothing on the eBGP session in inet.0 is being validated.

Is there some KNOB I'm missing, to allow a policy, executed upon routes in 
inet.0, to use the RV database in a non-default VRF? Or copy the VRF's RV to 
the default's RV? or is this some oversight of JNPR's RPKI implementation, that 
it must be inside the default:default LI:RI?

- CK.


NOTE: my Google-fu and/or "set ?" skills aren't yielding any useful results. 
Apologies if there's "a simple fix" for this, or an example of this situation I 
haven't found.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vlan-tagging on ospf interface

[Chris Kawchuk]

I also suspect that the OP is running "vMX"... due to the hostname on his 
routers.

And If he's running vMX on ESXi, using vSwitch/VMXNET3, did you actually set 
the underlying vSwitch to MTU=9000 and VLANID=4095, such that the hypervisor 
will Pass VLAN Tags? The vSwitch will not pass inbound tags by default. 

We have a basic lack of information here -- for anyone to do any type of 
accurate troubleshooting

- Ck.



> On 16 Apr 2021, at 3:34 am, Emille Blanc  wrote:
> 
> I would expect to have some kind of encapsulation on the interface.
> eg; set encapsulation flexible-ethernet-services
> 
> -Original Message-
> From: jayshankar nair [mailto:n_jayshan...@yahoo.com] 
> Sent: Thursday, April 08, 2021 5:46 AM
> To: juniper-nsp@puck.nether.net
> Subject: vlan-tagging on ospf interface
> 
> Hi,
>  I have ospf interface ge-0/0/3 on peer routers. I am able to ping from one 
> router to other when vlan-tagging is not enabled. When i enable the 
> vlan-tagging on peer interface. I am unable to ping. Below is the vlan tagged 
> enable configuration. Also the interface is added to ospf protocol
> OSPF-MultiArea
> jcluser@vMX1# show vlan-tagging;unit 600 {vlan-id 600;family inet {   
>  address 10.100.12.1/24;}}--
> jcluser@vMX2# show vlan-tagging;unit 600 {vlan-id 600;family inet {   
>  address 10.100.12.2/24;}}Please let me know if the configuration is 
> right.
> Thanks,Jayshankar
> ___
> 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] MX Reboot with Reason, panic:data storage interrupt trap

[Chris Kawchuk]

Im aware that the MX80's Flash can get worn out over time. 

Ive had to replace a few MX80s flashes with a compatible 3rd party USB/Flash to 
get them back up and running. (yes, voids warranty field-stripping an MX80 to 
get at the 2 flash modules in the rear area of the motherboard) -- but it 
worked. 

Field strip. Swap the flashes, Boot from USB installer, install JunOS, make a 
basic fxp0 config, load latest JunOS, push config back from RANCID, and the 
boxes are back in production and happy.

- Ck.


> On 3 Feb 2021, at 5:10 am, Righa Sha  wrote:
> 
> Hello,
> 
> I recently had an MX80 router reboot with reason being panic:data storage
> interrupt trap.
> 
> Anyone come across such an issue and get to resolve.Any assistance would be
> greatly appreciated.
> 
> Regards,
> Righa
> ___
> 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] Appending customer ASN to BGP

[Chris Kawchuk]

routing-options {
static {
route xx.xx.xx.0/24 {
next-hop yy.yyy.yy.yy;
as-path {
path 12345;
origin igp;
atomic-aggregate;
}
}
}
}

Where:
- xx.xx.xx.0/24 is their block
- yy.yy.yy.yy is the /31 facing them (assuming they're directly connected to 
this router)
- 12345 is their ASN

- CK.




> On 9 Nov 2020, at 7:06 am, Dario Amaya  wrote:
> 
> Hello,
> 
> Our customer has own ASN from ARIN and want us to take care of all
> routing. We already originate the customer prefix from our ASN. What
> is easiest / recommended way to append customer's ASN to the prefixes
> to make it appear as though it's originated from their ASN without any
> routing equipment / BGP from them? This is on Juniper MX, is L3VPN the
> answer?
> ___
> 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] SRX100H

[Chris Kawchuk]

SRX100H is EOL. They don't even list the software for it anymore on that main 
"recommended versions" page anymore as of this month.

>From memory, the max version you can load is JunOS 12.1X46-something due to 
>the lower memory versus the H2 variant.
If you can find the H2 variant, you can use JunOS 12.3X48-Dxxx which works fine 
for most applications. 

We ran SRX110H2-VAs (for the NBN FTTC/FTTN VDSL here in Australia) without 
issue until they were EOS.

If JNPR PLM is watching this ---  I'm still wishing for a fabled "SRX310" 
which is an SRX300 with a VDSL port (i.e. built in w/proper thermal envelope on 
it -- i.e. not the VDSL SFP thing which tends to get very warm...). SRX320 
sometimes is overkill, and really liked the noiseless/fanless capabilities of 
the SRX300 or the SRX110.

- CK.


> On 7 Mar 2020, at 2:12 am, Mehul Gajjar  wrote:
> 
> Hello Techie,
> 
> kindly advice stable version of Juniper SRX100H.
> 
> Thank you,
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] MX960 vs MX10K

[Chris Kawchuk]

Only question is if it needs stateful-ness or not (IPSEC, CGNAT etc...), but 
only the OP can answer that.

- CK.


> On 5 Mar 2020, at 2:39 pm, Mark Tinka  wrote:
> 
> 
> 
> On 5/Mar/20 05:32, Chris Kawchuk wrote:
> 
>> Just to chime in --- for scale-out, wouldn't you be better offloading those 
>> MS-MPC functions to another box? (i.e. VM/Dedicated Appliance/etc..?).
>> 
>> You burn slots for the MSMPC plus you burn the backplane crossing twice; so 
>> it's at worst a neutral proposition to externalise it and add low-cost 
>> non-HQoS ports to feed it.
>> 
>> or is it the case of limited space/power/RUs/want-it-all-in-one-box? and 
>> yes, MS-MPC won't scale to Nx100G of workload.
> 
> And along that line, are the services the OP needs on the MS-MPC not
> available natively in the MX1/960/480/240 line cards?
> 
> 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

Re: [j-nsp] MX960 vs MX10K

[Chris Kawchuk]

Just to chime in --- for scale-out, wouldn't you be better offloading those 
MS-MPC functions to another box? (i.e. VM/Dedicated Appliance/etc..?).

You burn slots for the MSMPC plus you burn the backplane crossing twice; so 
it's at worst a neutral proposition to externalise it and add low-cost non-HQoS 
ports to feed it.

or is it the case of limited space/power/RUs/want-it-all-in-one-box? and yes, 
MS-MPC won't scale to Nx100G of workload.

- CK.



> On 5 Mar 2020, at 1:36 am, Tom Beecher  wrote:
> 
> It really depends on what you're going to be doing,but I still have quite a
> few MX960s out there running pretty significant workloads without issues.
> 
> I would suspect you hit the limits of the MS-MPCs way before the limits of
> the chassis.
> 
> On Wed, Mar 4, 2020 at 6:56 AM Ibariouen Khalid  wrote:
> 
>> dear Juniper community
>> 
>> is there any limitation of using MX960 as DC-GW compared to MX10K ?
>> 
>> juniper always recommends to use MX10K , but i my case i need MS-MPC which
>> is not supported on MX10K and i want to knwo if i will have some limitation
>> on MX960.
>> 
>> 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

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

Re: [j-nsp] QFX10K port shaping

[Chris Kawchuk]

Assuming all your traffic is BE, (which is how I generally setup all my QFXes 
and ensure I never oversubscribe) and after adjusting all the ingress and 
egress shared-buffers from the defaults, (and just go down to a few HQ queues), 
you can create a scheduler with a shaper on the BE queue, + scheduler-map and 
apply it to the physical interface. It's quick n dirty but works in a pinch.

- CK.



> On 20 Feb 2020, at 11:43 pm, Chen Jiang  wrote:
> 
> Hi! Experts
> 
> Sorry for disturbing, we found the "set class-of-service interfaces xxx
> shaping-rate" is missing in QFX platform, is there any other method could
> do port shaping ?
> 
> Thanks for your help.
> 
> -- 
> BR!
> 
> 
> 
>   James Chen
> ___
> 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] arp from correct IP address

[Chris Kawchuk]

Ran into the same bug.

$junos-preffered-source-address for an unnumbered for BNG functions does NOT 
return the "closest/must suitable address" based on the IP+Subnet that was 
given the subscriber... contrary to the BNG template doucmentation. It just 
defaults the actual loopback of the router. (the dynamic template that gets 
created against a demux0. subscriber says $preffered of "NONE")

This means that things like Subscriber "ARP liveliness detection" doesn't 
work/cant work. (since the subscriber won't arp-respond to an ARP requests 
where the source isn't in the local subnet)

I've had a JTAC case open on this for 8 months. Sent full configs, built a full 
lab for them (so they could trigger it remotely), self full PCAPs.

MX204 + JunOS 18.3R + BNG (DHCP/IPoE naturally)

Also on MX80 w/same code - so it's the BNG code, not the platform doing it.

- Ck.




> On 25 Jan 2020, at 10:27 pm, Baldur Norddahl  wrote:
> 
> Hello
> 
> I have a problem where some customer routers refuse to reply to arp from
> our juniper mx204. The arp will look like this:
> 
> 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248
> 
> The problem is that this should have been "tell 185.24.169.1" because the
> client is in the 185.24.169.0/24 subnet. The interface is
> "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and
> 185.24.169.1 among many others. A Linux box would select the nearest
> address but apparently junos does not know how to do this.
> 
> Tried adding in "preferred-source-address $junos-preferred-source-address"
> but this just results in "preferred-source-address NONE" and does nothing.
> Also there is zero documentation on how junos will fill in that variable.
> 
> Is there a solution to this? Is there a radius variable I can set with the
> preferred source address?
> 
> Regards,
> 
> Baldur
> ___
> 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] trying to add double tagged interface and getting errors

[Chris Kawchuk]

Remove the pop-pop and push-push statements against unit xe-0/1/1.300.

JunOS will auto magically "remove" and "add" the VLAN tags to the VPLS 
attachment circuit; since you have declared "vlan-id none" in the VPLS 
definition. (no tags)

It's basically saying "don't try to do manual vlan tag manipulation on this 
attachment circuit (unit) - We will do it for you in order to "normalise" the 
tags to "nothing"

https://www.juniper.net/documentation/en_US/junos-space16.1/topics/concept/layer2-provisioning-vlan-manipulation-understanding.html
 


Basically -- You can only do pop/push operations where you have not declared 
any vlan-id inside a VPLS; (i.e. the vlan  statement is completely absent -- 
meaning you want do your own normalisation), however you need a vlan-id  
statement for an irb.x to work; hence you need to let JunOS "do it's thing" and 
do the pop-swap for you in your case

- Ck.


> On 22 Nov 2019, at 7:13 am, Aaron Gould  wrote:
> 
> How would I accomplish this ?  It's working fine, but when I try to add a
> double tagged interface into the existing vpls bridging environment, I get
> the following error.
> 
> 
> 
> me@ 204-1> show configuration routing-instances 100 | display set
> 
> set routing-instances 100 instance-type vpls
> 
> set routing-instances 100 vlan-id none
> 
> set routing-instances 100 interface xe-0/1/4.100
> 
> set routing-instances 100 routing-interface irb.100
> 
> set routing-instances 100 protocols vpls no-tunnel-services
> 
> set routing-instances 100 protocols vpls vpls-id 1
> 
> set routing-instances 100 protocols vpls mtu 1500
> 
> set routing-instances 100 protocols vpls neighbor 10.102.255.7
> 
> 
> 
> me@ 204-1> show configuration interfaces xe-0/1/1 | display set
> 
> set interfaces xe-0/1/1 flexible-vlan-tagging
> 
> set interfaces xe-0/1/1 mtu 9216
> 
> set interfaces xe-0/1/1 encapsulation flexible-ethernet-services
> 
> set interfaces xe-0/1/1 unit 300 vlan-tags outer 300
> 
> set interfaces xe-0/1/1 unit 300 vlan-tags inner 100
> 
> set interfaces xe-0/1/1 unit 300 input-vlan-map pop-pop
> 
> set interfaces xe-0/1/1 unit 300 output-vlan-map push-push
> 
> 
> 
> me@204-1# set routing-instances 100 interface xe-0/1/1.300
> 
> 
> 
> [edit]
> 
> me@ 204-1# commit check
> 
> [edit routing-instances 100 interface]
> 
>  'xe-0/1/1.300'
> 
>interface with input/output vlan-maps cannot be added to a
> routing-instance with a vlan-id/vlan-tags configured
> 
> error: configuration check-out failed: (statements constraint check failed)
> 
> 
> 
> 
> -Aaron
> 
> ___
> 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] VLAN in SNMP Interface Table

[Chris Kawchuk]

Using the basic SNMP IfMib for per-vlan stats on a switching interface:

EX - No. Just per-port stats. 
QFX - You can declare a sub-unit but per-vlan, but the unit's counters dont 
increase
MX - Yes, per sub-unit stats, but you need to declare the units as 
encapsulation vlan-bridge and manually define each vlan on a port.

If you're talking about IRB.x/VLAN.x, then yes EX, QFX can show L3 statistics 
in/out of the VLAN, but that's just the L3 interface.

Not familiar if any of the vendor-specific Juniper MIBs give you a better view 
of per-vlan on an EX or QFX; never looked that hard.

- CK.


> On 20 Nov 2019, at 8:13 am, juniper-...@ics-il.net wrote:
> 
> I understand that some Juniper switches will expose each VLAN in SNMP so I 
> can monitor traffic on a VLAN independently of over VLANs on that same 
> physical interface. Some of them don't. 
> 
> 
> Which ones do? 
> 
> 
> I prefer a solid used switch. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> ___
> 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] Ex8208 TRAP

[Chris Kawchuk]

Your dates are all over the place

May 19, then Jun 14, then back to May 19th...

Your SFP lost optics. Low power.

So.. what have you done to troubleshoot this w/your optical carrier or fibre 
provider, besides post on j-nsp?

- CK.


On 20 May 2018, at 3:44 pm, Mohammed Abu Sultan  wrote:

> May 19 20:42:52  Core-SW-8208 chassisd[1338]: CHASSISD_SNMP_TRAP10: SNMP trap 
> generated: FRU power on (jnxFruContentsIndex 8, jnxFruL1Index 1, 
> jnxFruL2Index 1, jnxFruL3Index 0, jnxFruName PIC: 8x 10GE SFP+ @ 0/0/*, 
> jnxFruType 11, jnxFruSlot 0, jnxFruOfflineReason 2, jnxFruLastPowerOff 
> 20675705, jnxFruLastPowerOn 20686688)
> May 19 20:42:53  Core-SW-8208 /kernel: pic_listener_connect: conn 
> established: mgmt addr=0x8110,
> May 19 20:42:52  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/0
> May 19 20:42:53  Core-SW-8208 /kernel: kernel overwrite ae0 link-speed with 
> child speed 100
> May 19 20:42:53  Core-SW-8208 /kernel: drv_ge_misc_handler: ifd:148  new 
> address:b0:c6:9a:c9:ae:03
> May 19 20:42:53  Core-SW-8208 /kernel: drv_ge_misc_handler: ifd:149  new 
> address:b0:c6:9a:c9:ae:03
> May 19 20:42:52  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/1
> May 19 20:42:53  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/2
> May 19 20:42:53  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/3
> May 19 20:42:53  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/4
> May 19 20:42:53  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/5
> May 19 20:42:53  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/6
> May 19 20:42:53  Core-SW-8208 chassisd[1338]: CHASSISD_IFDEV_CREATE_NOTICE: 
> create_pics: created interface device for xe-0/0/7
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 2 SFP 
> receive power low  alarm set
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 2 SFP 
> receive power low  warning set
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 3 SFP 
> receive power low  alarm set
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 3 SFP 
> receive power low  warning set
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 7 SFP laser 
> bias current low  alarm set
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 7 SFP output 
> power low  alarm set
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 7 SFP laser 
> bias current low  warning set
> Jun 14 02:32:18  Core-SW-8208 member0-fpc0  chassism[118]:  link 7 SFP output 
> power low  warning set
> May 19 20:42:53  Core-SW-8208 member0-fpc0 pfe_pme_max 24
> May 19 20:42:53  Core-SW-8208 member0-fpc0 
> PFE_L2,mrvl_brg_port_stg_entry_set():7472:Received MSTI-default-rt, not 
> expected
> May 19 20:42:54  Core-SW-8208 member0-fpc0 Error: Adding filter(block_pvst) 
> cntr(pvst) plcr((null)) index(1) entry
> May 19 20:42:52  Core-SW-8208 member0-fpc1  chassism[120]: 
> ccm_fm_hsl2_sid_plane_ctl_ack: FPC SID_PLANE_CTL_ACK fpc 1 sent; err=0
> May 19 20:44:24  Core-SW2-8208 member0-fpc0  chassism[118]: CM: 
> cm_hcm_pfem_resync_done: fpc_slot: 0
> May 19 20:44:24  Core-SW-8208 member0-fpc0  chassism[118]: CM: 
> cm_hcm_pfem_resync_done: FPC PFEM resync_done fpc 0 sent; err:0
> 

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

Re: [j-nsp] MX204

[Chris Kawchuk]

Here's my setup FWIW: (same as Mark's last example), broken out by MIC for 
clarity.

MIC 0: 100G, 100G, 4x10G, 4x10G, MIC1: 8x10G


On 15 May 2018, at 9:53 am, Eric Krichbaum  wrote:

> 3x 40G + 8x 10G
> 
> -Original Message-
> From: juniper-nsp  On Behalf Of Mark 
> Tinka
> Sent: Monday, May 14, 2018 6:20 PM
> To: Tim Jackson ; Bill Blackford 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] MX204
> 
> 
> 
> On 14/May/18 23:49, Tim Jackson wrote:
> 
>> Only kinda weird drawback is you can't use all 4x100G and the 8xSFP+ 
>> onboard. (https://apps.juniper.net/home/port-checker/)
> 
> Yes. Port combinations are:
> 
>- 4x 100Gbps
>- 4x 40Gbps
>- 16x 10Gbps + 8x 10Gbps
>- 2x 100Gbps + 16x 10Gbps
> 
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> ___
> 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] MX204

[Chris Kawchuk]

Testing 2 x MX204's in the JNPR Lab at the moment. 

Have 1 on order and 5 more to come.

- CK.

On 15 May 2018, at 3:41 am, Bill Blackford  wrote:

> Anyone using MX204?
> 
> Thoughts?
> 
> Benefits / Drawbacks?
> 
> Thank you in advance.
> 
> B
> 
> ___
> 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 UDP Amplification Attack - UDP port 111 ?

[Chris Kawchuk]

Hey Pierre,

Yep Agreed -- this goes back to Saku Ytti's et al's discussion ([j-nsp] DDoS to 
core interface - mitigation) a few weeks back re: IP block used just for 
infrastructure...and either filter it, rate-limit it, or simply don't announce 
it. Sage advice. Note that this was a lab-box on my end where I noticed it; 
(vmx1.mel-lab1) hence not really a "production" device and hence not part of 
the protected infrastructure range. (note to self: also de-announce the Lab /24 
...)

vMX 17.4 dropped recently (I was hoping for Mellanox SR-IOV drivers, but I 
think that's an vMX 18.1 thing...) and was just playing around with it since 
yesterday. Looks like the scan-bots found it quick.

- Ck.



On 16 Mar 2018, at 8:12 pm, Pierre Emeriaud  wrote:

> this is definitely not on the host:
> 
> user@mx960> show system connections inet | match .111
> tcp4   0  0  *.111 *.*
>  LISTEN
> udp4   0  0  *.111 *.*
> 
> Chris, besides filters, using un-announced prefixes for your backbone
> would prevent this kind of issues (and some others).

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

Re: [j-nsp] Juniper UDP Amplification Attack - UDP port 111 ?

[Chris Kawchuk]

Yeah, not on the hypervisor. Im SR-IOV'ing that interface via an Intel 
82599-based 10G port into vMX in RIOT-PERF mode

The hypervisor can't see the NIC interface at that point (due to 
PCIe-passthrough).

Anyways - as mentioned, I'll re-write my lo0.0 for 
"accept-useful-stuff-and-deny-all-else" logic as I should have done in the 
first place. =P 
...thats what happens when you do things in a rush.

- CK.



On 16 Mar 2018, at 1:06 pm, Roland Dobbins  wrote:

> 
> On 16 Mar 2018, at 8:59, Chris Kawchuk wrote:
> 
>> Just a heads up; I'm probably not the first person to see this--
> 
> This is rpcbind/portmapper, FYI, which is often abused for 
> reflection/amplification attacks.
> 
> I'm assuming vMX is a virtual MX - if so, are you sure the issue isn't on the 
> hypervisor host?
> 
> If not, definitely seems like a bug which should be reported to JSIRT.

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

[j-nsp] Juniper UDP Amplification Attack - UDP port 111 ?

[Chris Kawchuk]

Just noticed this today:

chr...@vmx1.mel-lab1> monitor traffic interface xe-0/0/0 no-resolve size 1500 
matching "not port 22" 
verbose output suppressed, use  or  for full protocol decode
Address resolution is OFF.
Listening on ge-0/0/0, capture size 1500 bytes

01:50:20.710920  In IP 207.174.181.174.47550 > 43.247.124.125.111: UDP, length 
40
01:50:20.711049 Out IP 43.247.124.125.111 > 207.174.181.174.47550: UDP, length 
368
01:50:20.711454  In IP 207.174.181.174.55654 > 43.247.124.125.111: UDP, length 
40
01:50:20.711506 Out IP 43.247.124.125.111 > 207.174.181.174.55654: UDP, length 
368
01:50:20.721262  In IP 207.174.181.174.22724 > 43.247.124.125.111: UDP, length 
40
01:50:20.721307 Out IP 43.247.124.125.111 > 207.174.181.174.22724: UDP, length 
368
01:50:20.727638  In IP 207.174.181.173.58698 > 43.247.124.125.111: UDP, length 
40
01:50:20.727680 Out IP 43.247.124.125.111 > 207.174.181.173.58698: UDP, length 
368
01:50:20.762255  In IP 207.174.181.173.10131 > 43.247.124.125.111: UDP, length 
40
01:50:20.762393 Out IP 43.247.124.125.111 > 207.174.181.173.10131: UDP, length 
368
01:50:20.777967  In IP 207.174.181.173.17923 > 43.247.124.125.111: UDP, length 
40
01:50:20.778010 Out IP 43.247.124.125.111 > 207.174.181.173.17923: UDP, length 
368
01:50:20.793727  In IP 207.174.181.173.15406 > 43.247.124.125.111: UDP, length 
40
01:50:20.793807 Out IP 43.247.124.125.111 > 207.174.181.173.15406: UDP, length 
368
01:50:20.849286  In IP 207.174.181.173.65209 > 43.247.124.125.111: UDP, length 
40
01:50:20.849360 Out IP 43.247.124.125.111 > 207.174.181.173.65209: UDP, length 
368
01:50:21.073702  In IP 207.174.181.174.22724 > 43.247.124.125.111: UDP, length 
40
01:50:21.073843 Out IP 43.247.124.125.111 > 207.174.181.174.22724: UDP, length 
368
01:50:21.214115  In IP 207.174.181.173.58698 > 43.247.124.125.111: UDP, length 
40
01:50:21.214229 Out IP 43.247.124.125.111 > 207.174.181.173.58698: UDP, length 
368

Seems JunOS is listening on port 111 and retuning some big bytes (i.e. in 40 
bytes, out 368 bytes) or a 9.2X amplification UDP reflection.
This on vMX .. dunno if hardware MX does the same thing, but likely.

I added this into our loopback lo0.0 filter (as we do deny-then-accept-all-else 
-- i should really re-write this as accept-and-deny-all-else logic, would've 
stopped it in it's tracks...).

+  term block-udp-111 {
+  from {
+  protocol udp;
+  destination-port 111;
+  }
+  then {
+  discard;
+  }
+  }

Just a heads up; I'm probably not the first person to see this-- and if you've 
seen it before, apologies for the noise...

- CK.


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

Re: [j-nsp] Stiching L2 to L3 on MX480

[Chris Kawchuk]

Correct.

With the LT- method you'd have the same problem. You'd have to stitch every 
L2CKT to an LT-0/0/0.x then from LT-0/0/0.y (it's partner) to the L3VPN; so 
lots of config there too. Likewise, LT- interfaces are bandwidth-constrained 
(as they use PFE bandwidth to send the packet through the Trio "twice" so to 
speak; it's equivalent to using a hair-pin cable between to physical ports on 
the MX; hence could be congested). MPLS-LDP Mesh groups don't pass throughout 
twice (watch Doug H or ytti correct me here hah)

If you want to keep it simple config on the MX -- you're almost better off 
"book-ending" the L2circuit with another ACX sitting right next to your MX 
(i.e. do all the Martini stuff between ACX-in-the-field to 
ACX-at-the-head-end-POP), and hand off all the L2 circuits to the MX on a 
physical 10G port. Single place to provision the L3VPN interfaces then on the 
MX; use per-unit scheduler to enforce southbound QoS at the MX. All the L2 
stuff stays on the ACX, all the L3 stays on the MX.

Downside is you'll lose MX-termination redundancy now though and have an extra 
box at your head-end; which is one thing the ACX-to-L2-to-MX-VPLS solution 
solves. (the ACX you can terminate the same L2CKT on 2 different MXes PE's 
using backup-neighbour  statement on the ACX at the 
pickup point "in the field"). 

Effectively this is just Hierarchal VPLS I'm proposing. Have POC'ed this before 
and worked well; but yes, 1 VPLS = 1 Tail + 1 IRB into the VRF

- CK.


On 20 Dec 2017, at 9:53 am, Pshem Kowalczyk  wrote:

> Hi,
> 
> If I did it this way, wouldn't I need a separate VPLS for every access 
> circuit on the ACX? I'm trying to limit this to one 'infrastructure' L2 
> setup, with all of the provisioning on MX.
> 
> kind regards
> Pshem

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

Re: [j-nsp] Stiching L2 to L3 on MX480

[Chris Kawchuk]

1. Use VPLS and add a LDP "Mesh-group" to it -- this extends the L2CKT from the 
ACX via standard Martini/L2CKT to the MX.
2. Put an IRB inside the VPLS for the L3 routing into your inet.0 table (or 
whatever VRF of you choice)
3. Adjust the vpls type to "irb-only" so that it doesnt go down if no CE 
interfaces are detected. (may or may not need this though, as the L2CKT may be 
classified as a CE, can't remember)
4. Enforce QoS on the ACX at the hand-off point (policer inbound, shaper 
outbound)
5. If you have QinQ, pop the outer-tag on ingress at the ACX so that it appears 
only as CTAG to the VPLS on the MX.

- CK.


On 20 Dec 2017, at 9:07 am, Pshem Kowalczyk  wrote:

> Hi,
> 
> We have an existing setup consisting of a number of ACX5k and MX480 (single
> MPLS domain). We generally provide L2 services out of the ACXes and L3 out
> of the MXes. Now, a new requirement emerged to provide L3 (with features
> that ACX can't provide) in locations where we can't justify the MX.
> I'd like to know if it's possible to do the following (and if anything
> special is required on the MX)
> 1. Build a L2 PWE3 taking whole port on the ACX and logically terminate it
> on the MX
> 2. The logical port on the MX (I presume 'lt') will be used to terminate
> individual dot1q and QinQ services into L3 VPNs.
> 
> Looking at the documentation it appears to be possible, but I'd like to
> know what sort of limitations this solution might have, particularly when
> it comes to QoS on the MX.
> 
> kind regards
> Pshem
> ___
> 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] Unequal bandwidth on virtual chassis ports?

[Chris Kawchuk]

As VC uses IS-IS as it's underlying protocol (last time I checked), I believe 
there is a metric associated with each VC link. show virtual-chassis 
adjacency/database/etc.. should show those metics.

VC IS-IS will calculate the lowest-metric to the far-end PFE, and use that. I 
also recall that it counts packet-forwarding-engines inside the switch itself, 
and not switches per se as a hop/link count. For example, an EX4200 has 3 x 
PFEs inside the box, and depending on where/how you connect the back-side VC 
cables or front-side revenue ports as VC will affect how it sees the topology.

VC will not load balance across unequal-costs (a-la RSVP-TE or something), and 
doesn't use multiple paths (even if they're ECMP) to the destination either 
last time I played with it; but it's been a while ;)

VCF will do the ECMP-trick, BTW.

- CK.


On 27 Oct 2017, at 8:05 am, Jonathan Call  wrote:

> Typically when I build virtual chassis I set up the recommended "ring" 
> topology and give path an equal amount of bandwidth. Would there be any 
> technical problems if I give one of the virtual chassis links more bandwidth 
> than the others?
> 
> 
> The Virtual Chassis Feature Guide for the QFX Series doesn't suggest there is 
> anything wrong with this, but it doesn't really discuss the scenario either.
> 
> 
> 
> 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

Re: [j-nsp] What version of Junos is best for bgp.

[Chris Kawchuk]

This is what I always use:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=RSS

14.1R7 seems to be the one that's more "current-yet-recommended".
Your RE-1800X4's would benefit from the 64 bit version too...

- CK.


On 16 Sep 2016, at 1:34 pm, Sachin Rai  wrote:

> If you do not want to do any of the above, go with jtac recommended junos.

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

Re: [j-nsp] ACX2200 - bandwidth control at subinterfaces

[Chris Kawchuk]

You mean scheduler maps/shaping on a subinterface?

Correct.

EX doesn't do per-unit schedulers. If they did, nobody would buy an MX for 
HQoS. ;)

You can do hard policers though... which is nasty.

I think you can still shape per-queue (i.e. [edit class-of-service schedulers] 
best-effort shaping-rate XX;); so, using some output firewall filters, you can 
put different VLANs into different queues, and shape each queue. 

However you give up some of the QoS functionality (only 8 HQ queues to play 
with...)


___

sample config I hacked together in 5 minutes on an ex2200c - passes commit.


ge-0/0/0 {
vlan-tagging;
unit 1 {
description "Some cusotmer - use best-effort HW queue - shape to 100m";
vlan-id 1;
family inet {
address 1.1.1.1/24;
}
}
unit 2 {
description "another cusotmer - use assured-forwarding HW queue - shape 
to 100m";
vlan-id 2;
family inet {
address 2.2.2.1/24;
}
}
}


class-of-service {  
interfaces {
ge-0/0/0 {
scheduler-map my-wacky-per-queue-shaper;
}
}
scheduler-maps {
my-wacky-per-queue-shaper {
forwarding-class best-effort scheduler best-effort-scheduler;
forwarding-class assured-forwarding scheduler assured-scheduler;
}
}
schedulers {
best-effort-scheduler {
shaping-rate 100m;
buffer-size percent 50;
priority low;
}
assured-scheduler {
shaping-rate 100m;
buffer-size percent 50;
priority low;
}
}

___
   

You'll need to use an output firewall filter on unit 1 to shove all traffic 
into BE, and on unit 2 to shove all traffic to AF. Remember only 8 HQ queues; 
and you'll likely reserve Queue 7 for network-control anyways.. so 7 effective 
queues (0-6) to play with.

Secondly, the EX has SMALL HW buffers; especially if I start carving them up as 
I did above -- beware.

- CK.



On 25 Aug 2016, at 5:52 am, Alexandre Guimaraes 
 wrote:

> Gents, afternoon,
> 
> 
>   After some research and a talk with my SE about how to control
> bandwidth at subinterfaces using ACX2200 Access Routers. I´h reached a point
> where we can´t control bandwidth using subinterfaces.
> 
>   Had someone of you guys, find a way to control that?
> 
>   Class-of-services only control the interface itself, not the
> subinterface.

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

Re: [j-nsp] EVPN/VXLAN on QFX5100

[Chris Kawchuk]

Ahh yes, that would indeed work... the L3 lookup for the remote VTEP is 
independent; so inet.0 or vrf-inet.0 what-have-you.

- CK.

"L2oVxLANoIPoMPLS"  I gotta remember that one ;)


On 4 Aug 2016, at 12:13 pm, Tim Jackson  wrote:

> You can run VXLAN over an MPLS LSP on QFX5100 just fine.. As long as the L3 
> lookup for the remote VTEP goes across an LSP the VXLAN traffic will too..
> 
> But it's not l2ompls.. it's l2ovxlanoipompls.
> 
> --
> Tim
> 
> 

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

Re: [j-nsp] EVPN/VXLAN on QFX5100

[Chris Kawchuk]

Ahh yes, that would indeed work... the L3 lookup for the remote VTEP is 
independent; so inet.0 or vrf-inet.0 what-have-you.

- CK.

 "L2oVxLANoIPoMPLS"  I gotta remember that one ;)


On 4 Aug 2016, at 12:13 pm, Tim Jackson  wrote:

> You can run VXLAN over an MPLS LSP on QFX5100 just fine.. As long as the L3 
> lookup for the remote VTEP goes across an LSP the VXLAN traffic will too..
> 
> But it's not l2ompls.. it's l2ovxlanoipompls.
> 
> --
> Tim
> 
> 

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

Re: [j-nsp] EVPN/VXLAN on QFX5100

[Chris Kawchuk]

You cannot use MPLS as the "underlay" Transport on QFX51xx. I tried the same -- 
you need to use VxLAN as the "transport LSP" so to speak. (Think of VXLAN 
remote VTEP IP address as being the outer label, and the VNI is the inner 
label.)

There's a config guide floating around out there on the JNPR Website fort the 
QFX manual showing how to setup the VTEPs so that the switches setup an 
"inet.3" table between each other for remote-next-hop resolution (from 
iBGP/MP-BGP sessions), pointing to a remote VTEP IP. 

Good luck! Would be nice if they could do MPLS as the underlay, but <-insert 
Trident2+ Pipeline issues-> here.

- CK.


On 4 Aug 2016, at 7:19 am, Joe Freeman  wrote:

> The QFX's are connected via an MPLS/IP connection with LDP/RSVP/ISIS, and
> MP-IBGP.
> 
> A show evpn instance extensive command shows that the two switches see each
> other, but I am unable to learn mac addresses between them.

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

Re: [j-nsp] EX3400 switches, QSFP+ breakout

[Chris Kawchuk]

Likely to make you buy a QFX5100/5100-48T/5100-96/xxx5048 instead. (or 
son-of-QFX...). Speculation thinks that JNPR wants everyone into the QFX line 
and out of EX; the moving you towards VCF/QF datacentre/fabric-ready/CLOS 
switching vs traditional switching products.

 Likely no technical reason, other than "they didn't wan you to 
do it" perhaps - It all depends on what PLM is allowing on a platform vs 
positioning of the other products in the portfolio. . 

Echoing again, best to speak with your AM/SE team in terms of product 
direction/roadmap.

- CK.


> On 16 Jun 2016, at 12:35 pm, Colton Conor wrote:
> 
> Why?
> 
> 
>> Like the EX4300 the 40GE ports cannot be channelized to 4 x 10G
>> 
>> Nitzan

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

Re: [j-nsp] Independent /32s for Interfaces - anybody doing that?

[Chris Kawchuk]

Just to add to this

On 31 May 2016, at 9:31 pm, Vincent Bernat  wrote:

> Unfortunately, the support vary widely accross vendors. I believe the
> support is pretty good with Cisco. With Juniper, it really depends on
> the equipment. The MX has pretty good support, but has some limitations
> (for example, static BFD + unnumbered doesn't work). 


Doing ip-unnumbered/OSPF on interfaces and also enabling LDP in the interface 
-- every now and then the LDP doesn't survive reboot, and have to "kick" (clear 
ldp neighbors) the LDP sessions for inet.3 to correctly populate on the box 
once OSPF is back up and established. It's once of the reasons I have never 
widely deployed using ip-unnumbered w/OSPF and MPLS in anything other than my 
lab environments. Happened on 13.x through 15.x on MX80 and MX480s with various 
RE's and SCBs/SCBEs. Never got around to opening a PR on this though...

Agreed is great for lab and quick prototyping so I don't have to fiddle around 
with assigning /30s and /31s when Im trying to do something higher-layer 
(L3VPN/VPLS/eVPN/iBGP/etc..)

Juniper produced a J-Learn called "MPLS Plug and Play for Metro Ethernet" 
(google for it) from many years ago (2007) which explicitly showed how to setup 
your devices to automatically create an IGP/MPLS/LDP mesh in a metro (for 
L2CKTs)...although it works for any topology of your choice.  Heavily uses the 
ip-unnubered and the lo0.0 inheritance schemes discussed in this thread; so 
should be widely supported if they were pushing this

- CK.


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

Re: [j-nsp] Monitoring a gre tunnel on an EX4200

[Chris Kawchuk]

Yeah.. not there:

{master:0}[edit protocols oam]
chrisk@SwitchyMcSwitchFace# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> ethernet OAM configuration for Ethernet
{master:0}[edit protocols oam]

chrisk@SwitchyMcSwitchFace> show version 
fpc0:
--
Hostname: ex2200-c
Model: ex2200-c-12t-2g
Junos: 14.1X53-D35.3

> Any ideas how I could monitor the status of a tunnel? There is an
> OSPF adjacency on the tunnel which is in a non-default
> routing-instance. 

Tune your OSPF timers down, look for that in SNMP trap / event script SLAX, 
etc..

> Could you perhaps suggest an SNMP OID to monitor the OSPF adjacency in
> a non-default routing-instance?

Likely. I'll SNMPWalk my EX2220c here and see if I can spot anything. I recall 
seeing something in an OSPF MIB last time when I did this; but never 
implemented it myself. BGP session monitoring is there via the standard MIBs to 
show status (0=active, 5=Established, etc..), so likely something similar (but 
I'm guessing at this point..)

- CK.



On 17 May 2016, at 9:10 pm, Victor Sudakov  wrote:

> I have found no keepalive or oam functionality for gre tunnels on
> EX4200 switches. 

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

Re: [j-nsp] B-RAS services

[Chris Kawchuk]

vMX Supporting HQoS Yet?

That feature will be key for Subscriber management / bandwidth enforcement of 
subscriber plans. I know -Q and -EQ definitely supporting it form day 1 in HW; 
bit haven't had luck with vMX yet. (vMX still lacking feature parity last time 
I checked... especially 'services' and MS-MPC functions)

- Ck.


On 10 May 2016, at 5:55 am, Nitzan Tzelniker  wrote:

> You can take vMX and do subscriber management on it (It is very new so be
> careful )

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

Re: [j-nsp] Sending iBGP prefixes to another iBGP neighbour

[Chris Kawchuk]

let me fix my errors: I mean tot say L3VPN not L2 ;)

___

If you put the Linux session into a VRF on the MX104, then run *L3VPN* between 
the MX104 and MX80, (may have to enable the independent-domain knob in the 
vrf), you can solve it that way too.. 

however the egress interface on the MX80 also needs to be in the VRF.

Topology:

iBGP(Linux) -> (VRF)MX104 -> L3VPN/iBGP/MPLS -> MX80(VRF) -> eBGP

- CK.


On 6 May 2016, at 2:37 am, Mike Williams  wrote:

> Hey all,
> 
> I could very well either be doing this completely wrong, or attempting to do 
> the impossible, but...
> 
> We have BIRD on Linux using BGP to send prefixes to the MX104 over a direct 
> connection, I need to send those prefixes to an MX80 directly connected to 
> the 
> 104.
> 
> At the 104 end of the 104<->80 peering there is just an export policy, that 
> simply matches on "from protocol bgp" and the BGP community assigned the 
> prefixes I want, then accept and next-hop self.

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

Re: [j-nsp] Sending iBGP prefixes to another iBGP neighbour

[Chris Kawchuk]

If you put the Linux session into a VRF on the MX104, then run L2VPN between 
the MX104 and MX80, (may have to enable the independent-domain knob int he 
vrf), you can solve it that way too.. 

however the egress interface on the MX80 also needs to be in the VRF.

I use this a lot for solving eBGP -> iBGP -> iBGP -> iBGP without the use of 
route-reflectors (and yes, this is a corner case I know), where I have the same 
AS on one of the PE-CE pairs; and need to run iBGP to my MX. ... and No, we 
cannot change the last session to eBGP (which would solve this). ;)

HTH.

- CK.


On 6 May 2016, at 2:37 am, Mike Williams  wrote:

> Hey all,
> 
> I could very well either be doing this completely wrong, or attempting to do 
> the impossible, but...
> 
> We have BIRD on Linux using BGP to send prefixes to the MX104 over a direct 
> connection, I need to send those prefixes to an MX80 directly connected to 
> the 
> 104.
> 
> At the 104 end of the 104<->80 peering there is just an export policy, that 
> simply matches on "from protocol bgp" and the BGP community assigned the 
> prefixes I want, then accept and next-hop self.

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

Re: [j-nsp] MIB queue length Juniper

[Chris Kawchuk]

There's a JNPR MIB browser here which I have found rather helpful:

http://contentapps.juniper.net/mib-explorer/navigate.jsp#object=juniperMIB&product=Junos%20OS&release=15.1R2

Can flip between versions of JunOS easily, and gives the raw OID back to you on 
the right.

- CK.


On 27 Apr 2016, at 7:18 am, David Samaniego  wrote:

> Hello, I want to read a queue length of my router thourgth snmpwalk, and I
> need to know what is the correct MIB to use.
> 
> I need any help, because I do not how to implement it.
> 
> Best regards
> Sebastian
> ___
> 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 base model

[Chris Kawchuk]

No.


On 26 Apr 2016, at 9:34 am, Satish Patel  wrote:

> Also do I need to pay to run BGP?

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

Re: [j-nsp] VPLS and IRB

[Chris Kawchuk]

Add connectivity-type irb; to the vpls {} stanza.

i.e. at [edit routing-instances TEST protocols vpls]


"Specifies when a VPLS connection is taken down depending on whether or not the 
interface for the VPLS routing instance is customer-facing or integrated 
routing and bridging (IRB)..."

ce (default)—   Require that for the VPLS connection to be up, the 
customer-facing interface for the VPLS routing instance must also be up. If the 
customer-facing interface fails, the VPLS connection is taken down.

irb —   Allow a VPLS connection to remain up so long as an IRB 
interface is configured for the VPLS routing instance.

permanent   —   Allow a VPLS connection to remain up until specifically 
taken down.


http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/connectivity-type-edit-protocols-vpls.html



On 20 Apr 2016, at 9:14 am, j...@czmok.de wrote:

> TEST {
>instance-type virtual-switch;
>route-distinguisher 1.2.3.5:;
>vrf-target target::;
>protocols {
>vpls {
>site-range 3;
>no-tunnel-services;
>site B {
>site-identifier 1;
>}
>}
>}
>bridge-domains {
>vlan {
>vlan-id ;
>routing-interface irb.;
>}
>}
> }

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

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

[Chris Kawchuk]

On 19 Apr 2016, at 2:26 am, Alexander Arseniev  wrote:

> Hello,
> If You are doing the below JUNOS config on Olive, L2circuit data plane does 
> not work on Olive.
> And it never worked on Olive, to my knowledge.
> HTH
> Thx
> Alex


+1 

L2-features have never worked on Olive from my experience as well.

i.e.
VPLS
L2CKT (LDP/martini)
CCCs (RSVP/Kompella)
etc...




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

Re: [j-nsp] Cisco vs Juniper confused

[Chris Kawchuk]

On 15 Apr 2016, at 9:35 am, Satish Patel  wrote:

> Does Juniper SRX support BGP?

In Spades.

It's pretty much a full JunOS Routing Implementation (Multiprotocol BGP, OSPF, 
etc...); and included in the base price last time I checked.

I use an 'small' SRX210 it for protocol testing vs other Vendor's gear. An 
SRX240 or higher should be able to do gigabits of traffic.

- Ck.


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

Re: [j-nsp] Routeserver next hop issue.

[Chris Kawchuk]

1. Do you have an import policy on the BGP session to the route server? (seeing 
if maybe you're overwriting protocol-next-hop --  or you may have an inherited 
policy at a higher level than the group/neighbour...dunno)

2. As you mentioned, What does 'show route receive-protocol bgp 
' say in terms of the next hop it's sending? You 
said route-server member, but that doesnt make sense if it's a /24 or something 
"flat" peering exchange, it should return the next hop of the actual peer (and 
not the route server's IP).. unless the topology of the exchange is different 
from what I'm expecting.

I think you're likely doing everything right, but if you can send (sanitised) 
configs for:

ergo:

show configuration protocols bgp
show configuration policy-options
show route receive-protocol bgp  extensive

the 'next hop self' export policy should be on iBGP to the rest of your 
network. No need to next-hop self on an eBGP session, since JunOS does this for 
you automatically.

- Ck.



On 11 Apr 2016, at 8:27 am, Jeffrey Nikoletich  wrote:

> First post here. We recently switched from Cisco to juniper and it has been
> an adventure to say the least. We are running in to an issue with BGP
> session with peering exchanges route servers. The session comes online and
> doing a received-protocol it is showing the correct next hop of the other
> route server member. When doing a show route it is showing the next hop as
> the IP of the route server itself. As you can imagine, it is not passing
> traffic correctly.
> 
> 
> 
> We have set the next hop self on the export policy but how do we fix the
> inbound next hop?

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

[Chris Kawchuk]

Used RE-S-2000 w/SCBE and JunOS 14.2 with JAM for MPC3-NG Cards. No issues.

Mostly running 13.3R6 or R8 on most of our core which is dual RE-S-2000's on 
MX480.

- CK.


On 14/01/2016, at 9:11 AM, Tom Storey  wrote:

> On 13 January 2016 at 22:32, Mark Tinka  wrote:
>> A more current RE means you can run more recent Junos releases. I
>> haven't run the RE-S-2000 in a while, so not sure how well it's
>> supported by current Junos releases (someone else who has the older RE's
>> might want to chime in).
> 
> Guess it depends how old an RE you are talking about, and how recent JunOS?
> 
> Have seen RE-S-2000's running 13.3.
> ___
> 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] Suggestions on management of dual-RE devices

[Chris Kawchuk]

Relevant config snippet/stanzas:

## Last commit: 2015-11-24 16:03:02 EST by me
version 13.3R6.5;
groups {
re0 {
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.xx.xx.1/24 {
master-only;
}
address 172.xx.xx.2/24;
}
}
}
}
}
re1 {
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.xx.xx.1/24 {
master-only;
}   
address 172.xx.xx.3/24;
}   
}   
}   
}   
}   
}   
apply-groups [ re0 re1 ];
...
...
...

note the 'master-only" directive. You then SNMP/SSH/etc... to the proverbial 
'.1' address, which always goes to the master RE; whichever one is active.

Hope that helps.!

- Ck.




On 25/11/2015, at 5:07 AM, Mike Williams  wrote:

> Hi all,
> 
> So we just got our first Juniper devices with dual-REs (if you exclude 
> virtual 
> chassis').
> Before I get into actually configuring them, I'm wondering how others handle 
> management, as I'm a touch confused.
> 
> Normally we just SSH/snmp to the loopback address, optionally jumping off 
> from 
> a device on the same OoB network if routing is down (yes, we should configure 
> a backup router).
> 
> Juniper document providing each RE with it's own loopback address.
> If you do that, you'd have to detect if what you're connected to is master or 
> backup, right?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Force reset of routing engine from its peer

[Chris Kawchuk]

request chassis routing-engine power-off other-routing-engine etc..etc..? 
(something along those lines)

I recall I just did this last week on an MX480 (someone put the same fxp0 IPs 
on both REs..) so I shut one RE down from the other RE with some type of 'power 
off' command to avoid ip-to-mac flipping every few seconds while I fixed it. 
Not a "reboot" command, but an actual "hey chasissd -- kill the power to this 
thing" command.

Steinar's command re: kill all power to CB0 should do the same thing, but takes 
down the fabric board as well.

- Ck.


On 19/08/2015, at 6:42 PM, Tom Eichhorn  wrote:

> Hi,
> 
> I was just wondering, is there a way to force reset a routing engine
> from the other in the same chassis?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] jtree0 Memory full on MX480?

[Chris Kawchuk]

> So the SCB itself is only responsible for the available bandwidth per slot 
> but is not and will never be a memory limitation?


Correct on all points.

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

Re: [j-nsp] jtree0 Memory full on MX480?

[Chris Kawchuk]

On 23/07/2015, at 1:30 AM, Jeff Meyers  wrote:

> yes, we did (at least since yesterday) although we are not really requiring 
> more ports or bandwidth right now. If I understand that correctly, I need to 
> upgrade to SCB2 as well?


nope -- no need to go to MPC+SCB2 combo.

original SCBs work fine with MPC1 MPC2.2E, etc.. albeit limited to 120G/slot 
only, which is fine as MPC2 can only do 80G anyways in/out




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

Re: [j-nsp] jtree0 Memory full on MX480?

[Chris Kawchuk]

I know that a ton of fixes on BGP convergence time son MX80 is definitely a 
reason to be 'moving up'... however as you're on RE-2000s on MX480 may not be 
applicable.

I see you're running DPC cards, have you considered shifting those links onto 
an MPC/Trio Card? (newer chip, more RAM, more horsepower, yadda yadda yadda 
=)..) DPC was EOL a while ago, and everything has been Trio (and now Trio-NG on 
the new -NG cards coming out now). As the FIB is pushed to hardware, it may be 
some silly DPC thing you're running into.

For things like Fusion or BNG or any other 
new/advanced/this-is-what-PLM-is-thinking functions, we're already putting in 
14.2 on any new device we turn up, and have already started testing 15.1 for 
the new NG cards we will likely be buying. Rest of our network is now on 12.3R8 
or 13.3 in many cases. (lots of BFD bugs have been squashed, some HQoS issues 
fixed, host-outbound-traffic for BFD keepalives now honour the c-o-s knobs, and 
are finally out of Queue 3 and into the Queue we want (7), etc... preventing 
starvation if you happen to have re-used Queue 3 as "not-so-high" priority, 
etc)... the list goes on.

It's not a case of "if it aint broke, don't fix it" once you get 4-5 years 
behind. You'll benefit from the years of "Oh, we finally fixed LLDP ascii 
decoding" stuff that ends up getting traction; plus JTAC would really really 
like it if you weren't on 11.4 =)

- Ck.


On 22 Jul 2015, at 10:49 am, Jeff Meyers  wrote:

> Hi,
> 
> yes, an upgrade is absolutely possible but since there are no major issues 
> with that release, we didn't do that yet. Are you just assuming a newer 
> software improves that or did Juniper really do something on that side?
> 
> 
> Best,
> Jeff

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

Re: [j-nsp] Proper Break of MPLS RSVP Ring

[Chris Kawchuk]

Post relevant configs and an actual diagram (Visio -> PDF)

Without this, anything we say is pure speculation -- and we end up playing '20 
questions' with you. Getting an MPLS/RSVP/LDP/IGP/BGP/Mesh/TE network setup 
involves multiple steps and config-knobs being turned on and turned on 
correctly. Missing any one of them can result in undesirable behaviour.

1. RSVP priority/preference (?) has no bearing on forming an MPLS forwarding 
path adjacent between two LSRs.

2. There is no "break" in an MPLS network if it happens to be attached in a 
ring. This is not Spanning Tree. You have a fully routed network. Topology can 
be arbitrary.

3. How are you setting "broken RSVP down?" RSVP only goes "up" to a neighbour 
IF it actually has a reason to talk to it's neighbour. If you do not book an 
RSVP LSP across the link (due to ERO or following the IGP to the egress point), 
the two LSR's never exchange RSVP packets, because they have no reason to do 
so. This is known and expected behaviour. This is not LDP, which is 'chatty' 
and tries to reach out and touch it's neighbour and dynamically create FECs and 
transport label tables. RSVP only is invoked on an LSR-LSR link if an actual 
reservation needs to be made on that link.

4. What does your IGP suggest about the shortest path in the topology?

5. do you have family mpls enabled on all the relevant interfaces?

6. do you have all the relevant interfaces you want to run rsvp on, declared in 
protocols rsvp, and protocols mpls?

etc.. ;)

- Ck.




On 22/07/2015, at 5:18 AM, Levi Pederson  
wrote:

> All,
> 
> Double Checked the Layer 2 ring today and it seems solid.
> 
> Once again we have B and C co-located and A and D in remote locations with
> a link between them.
> 
> Currently there is no RSVP between C and D and this is making my ring go
> right instead of left!
> 
> I can Ping from D to C (it's next hop on the ring) if I force it out the
> MPLS interface.  However when I ping the LSP interfaces (loopbacks) it
> takes the long way around).  Short is 10ms and the long goes up to almost
> 26ms (pinging loops , again the long way around).  Current production
> traffic backs this up.
> 
> This leads me to believe there is not a Layer 2 issue but something more
> enigmatic.
> 
> Currently reading up on RSVP priority/preference but that seems like taking
> a 2Ton Electromagnetic Sentient WreckingBall to hammer in a nail.
> 
> Thank you,

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

Re: [j-nsp] L2Circuit Backup does not switch back to Primary

[Chris Kawchuk]

It's working as expected.

L2 Circuits are (by default) non-revertive. Don't want things flipping back and 
forth if interfaces or paths are flapping.

_

If you want it to revert automatically, do this:

set protocols l2circuit neighbor 192.168.99.1 interface ge-0/0/0.0 revert-time 
XXX

where XXX is expressed in seconds.

_




On 30/06/2015, at 6:42 PM, Alireza Soltanian  wrote:

> Hi everybody
> 
> I am using L2Circuit connection between three routers:
> 
> 1)  Juniper M10(R1)
> 
> 2)  Cisco 7200VXR(R2)
> 
> 3)  Cisco 7200VXR(R3)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Setting CoS bits on ingress frames

[Chris Kawchuk]

class-of-service {
interface {
ge-0/0/0 {
unit 0 {
forwarding0class expedited-forwarding;
}
}
}
}

where ge-0/0/0 is defined as an untagged port (i.e. family inet with no 
vlan-id, family ethernet-switching port mode access) etc...

- CK.

On 24 Jun 2015, at 4:34 pm, Victor Sudakov  wrote:

> Yes but there should be a way to say "any packet enering this untagged
> port should be processed as if it has such and such CoS value."

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

Re: [j-nsp] QinQ on MX bridge-ing

[Chris Kawchuk]

Close. 

By declaring a vlan-Id in the BD definition -- the MX does vlan "normalisation" 
as JNPR calls it. (And does all the correct push/pop magic for you)

If you omit the vlan-id statement in the BD definition, then your statement is 
correct. 

Quick verify: show interfaces ge-2/1/5 will show input: push 0x8100.100 and 
output: pop. When the vlan-id is declared In the BD stanza. 

Works well.!

-CK. 

> On 16 Apr 2015, at 7:34 pm, Adam Vitkovsky  wrote:
> 
> Hi Chris,
> 
> > 2/1/5 is the "access port" which pops the outer tag on egress, slaps it on 
> > on
> > ingress; regardless if it's already tagged coming in.
> >
> Wouldn't the frame still remain untagged within the BD please?
> And would only get the tag 100 applied as a top tag when sent out of either 
> ge-2/1/2.100 or ge-2/1/3.100 please?
> 
> 
> adam
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> > Of Chris Kawchuk
> > Sent: 16 April 2015 00:40
> > To: Robert Hass
> > Cc: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] QinQ on MX bridge-ing
> > 
> > Try this
> > 
> > set interfaces ge-2/1/2 flexible-vlan-tagging
> > set interfaces ge-2/1/2 mtu 9192
> > set interfaces ge-2/1/2 encapsulation flexible-ethernet-services
> > set interfaces ge-2/1/2 unit 100 encapsulation vlan-bridge
> > set interfaces ge-2/1/2 unit 100 vlan-id 100
> > 
> > set interfaces ge-2/1/3 flexible-vlan-tagging
> > set interfaces ge-2/1/3 mtu 9192
> > set interfaces ge-2/1/3 encapsulation flexible-ethernet-services
> > set interfaces ge-2/1/3 unit 100 encapsulation vlan-bridge
> > set interfaces ge-2/1/3 unit 100 vlan-id 100
> > 
> > set interfaces ge-2/1/5 mtu 9192
> > set interfaces ge-2/1/5 encapsulation ethernet-bridge
> > set interfaces ge-2/1/5 unit 0 family bridge
> > 
> > set protocols protection-group ethernet-ring erpsring1 data-channel vlan 100
> > //* if you're using ERPS for failover on a ring of EX42's, which you should 
> > -- to
> > avoid using dreaded spanning tree protocols ;)
> > 
> > set bridge-domains QinQ vlan-id 100
> > set bridge-domains QinQ interface ge-2/1/2.100
> > set bridge-domains QinQ interface ge-2/1/3.100
> > set bridge-domains QinQ interface ge-2/1/5.0;
> > 
> > 2/1/2 and 2/1/3 are the "trunk" ports, you only care about the outer tag
> > here. (its double tagged coming in from the EX42, but you dont care at this
> > point)
> > 2/1/5 is the "access port" which pops the outer tag on egress, slaps it on 
> > on
> > ingress; regardless if it's already tagged coming in.
> > 
> > - CK.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > 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

Re: [j-nsp] QinQ on MX bridge-ing

[Chris Kawchuk]

Try this

set interfaces ge-2/1/2 flexible-vlan-tagging
set interfaces ge-2/1/2 mtu 9192
set interfaces ge-2/1/2 encapsulation flexible-ethernet-services
set interfaces ge-2/1/2 unit 100 encapsulation vlan-bridge
set interfaces ge-2/1/2 unit 100 vlan-id 100

set interfaces ge-2/1/3 flexible-vlan-tagging
set interfaces ge-2/1/3 mtu 9192
set interfaces ge-2/1/3 encapsulation flexible-ethernet-services
set interfaces ge-2/1/3 unit 100 encapsulation vlan-bridge
set interfaces ge-2/1/3 unit 100 vlan-id 100

set interfaces ge-2/1/5 mtu 9192
set interfaces ge-2/1/5 encapsulation ethernet-bridge
set interfaces ge-2/1/5 unit 0 family bridge

set protocols protection-group ethernet-ring erpsring1 data-channel vlan 100  
//* if you're using ERPS for failover on a ring of EX42's, which you should -- 
to avoid using dreaded spanning tree protocols ;)

set bridge-domains QinQ vlan-id 100
set bridge-domains QinQ interface ge-2/1/2.100
set bridge-domains QinQ interface ge-2/1/3.100
set bridge-domains QinQ interface ge-2/1/5.0;

2/1/2 and 2/1/3 are the "trunk" ports, you only care about the outer tag here. 
(its double tagged coming in from the EX42, but you dont care at this point)
2/1/5 is the "access port" which pops the outer tag on egress, slaps it on on 
ingress; regardless if it's already tagged coming in.

- CK.









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

Re: [j-nsp] QinQ on MX bridge-ing

[Chris Kawchuk]

Don't you mean 102 and 103 for the other vlans?


On 16/04/2015, at 8:32 AM, Robert Hass  wrote:

> set bridge-domains VLAN101 domain-type bridge
> set bridge-domains VLAN101 vlan-id 101
> set bridge-domains VLAN102 domain-type bridge
> set bridge-domains VLAN102 vlan-id 101
> set bridge-domains VLAN103 domain-type bridge
> set bridge-domains VLAN103 vlan-id 101

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

Re: [j-nsp] Aggregate policer config

[Chris Kawchuk]

Err, I thought he had unlike-speeds for interfaces?

> 
> Customer Interface 1 is a VLAN on a 10G interface
> Customer Interface 2 is a VLAN on a 1G interface


Unless he does active-passive 1+1, but dunno if JunOS supports unlike physical 
interface speeds. plus means direct physical connection, instead of out an 
aggregated/VLAN'ed interface into his Layer-2 transport/switching/fan-out 
network.

I suggested doing a firewall filter (non interface-specific) against the VLANs 
on egress, which calls a single (specific/dedicated) policer. May have to play 
with the knobs on the filter if it's on different PFEs.

- Ck.



On 08/04/2015, at 11:35 PM, Mark Tinka  wrote:

>> Peter,
>> 
>> Would an aggregate interface assist in this? If It can be done in your
>> logical scheme, the aggregate interface would provide a simple way to apply
>> the entire X bandwidth no matter the pipes up.
> 
> Juniper do support aggregate application of a normal policer, where the
> bandwidth is shared between all member links in the LAG. So yes, this is
> a viable option.
> 
> Of course, it means the customer needs to support LACP, but on the
> bright side, you now only need one BGP session to the customer. The
> limitation with this is that if the customer has more than one router,
> it breaks the solution unless they can support MC-LAG.

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

Re: [j-nsp] VPLS question

[Chris Kawchuk]

> Hi chris
> Could you pls send me a concrete config example of your last statement:
> 
> " - You can put a VPLS into an L3VPN by defining a routing-interface irb.xx 
> into the VPLS (VPLS then requies vlan tagging i.e. vlan-id defined in the 
> VPLS)
> then including the same irb.xxx interface in the L3VPN interfaces list. 
> You can put multiple VPLSs in this way (1 irb.xx per VPLS, and multiple 
> irb.xx in the L3VPN)"
> 
> Thanks
> 

something like:

interfaces {
irb {
unit 100 {
family inet {
address 1.1.1.0/24;
}
}
unit 200 {
family inet {
address 2.2.2.0/24;
}
}
}
}
}


routing-instances {
   VPLS1 {
instance-type vpls;
vlan-id 100;
routing-interface irb.100;
interface ge-0/0/0.100;
vrf-target target:65535:1;
protocols {
vpls {
no-tunnel-services;
site X {
 site-identifier 1;
}
}
}

   VPLS2 {
instance-type vpls;
vlan-id 200;
routing-interface irb.200;
interface ge-0/0/0.200;
vrf-target target:65535:2;
protocols {
vpls {
no-tunnel-services;
site Y {
 site-identifier 1;
}
}
}

  L3VPN {
instance-type vrf;
interface irb.100;   // VPLS 1
interface irb.200;   // VPLS 2
vrf-target target:65535:3;
vrf-table-label;
}
}

cc'ed to list to share the knowledge.

- CK.



On 12/03/2015, at 11:29 PM, james list  wrote:

> 
> Il 11/mar/2015 23:09 "Chris Kawchuk"  ha scritto:
> Yes.
> 
> - L2CKTs can be mapped into a VPLS using an LDP Mesh Group [routing-instances 
>  protocols vpls mesh-group vpls-id neighbour ]
> - L2VPNs can be mapped into a VPLS using stitched lt-* interfaces (interfaces 
> lt-1/0/10.1 <> lt-1/0/10.2 peer unit 1 etc.. encapsulation vlan-vpls / 
> vlan-ccc)
> - You can put a VPLS into an L3VPN by defining a routing-interface irb.xx 
> into the VPLS (VPLS then requies vlan tagging i.e. vlan-id defined in the 
> VPLS)
> then including the same irb.xxx interface in the L3VPN interfaces list. 
> You can put multiple VPLSs in this way (1 irb.xx per VPLS, and multiple 
> irb.xx in the L3VPN)
> 
> - CK.
> 
> 
> On 12/03/2015, at 1:43 AM, james list  wrote:
> 
> > Hi folks
> > It there a way, in a vpls configuration with MX, to map multiple L2 and
> > multiple L3 in the same vpls instance ?
> 

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

Re: [j-nsp] VPLS question

[Chris Kawchuk]

Yes.

- L2CKTs can be mapped into a VPLS using an LDP Mesh Group [routing-instances 
 protocols vpls mesh-group vpls-id neighbour ]
- L2VPNs can be mapped into a VPLS using stitched lt-* interfaces (interfaces 
lt-1/0/10.1 <> lt-1/0/10.2 peer unit 1 etc.. encapsulation vlan-vpls / vlan-ccc)
- You can put a VPLS into an L3VPN by defining a routing-interface irb.xx into 
the VPLS (VPLS then requies vlan tagging i.e. vlan-id defined in the VPLS)
then including the same irb.xxx interface in the L3VPN interfaces list. You 
can put multiple VPLSs in this way (1 irb.xx per VPLS, and multiple irb.xx in 
the L3VPN)

- CK.


On 12/03/2015, at 1:43 AM, james list  wrote:

> Hi folks
> It there a way, in a vpls configuration with MX, to map multiple L2 and
> multiple L3 in the same vpls instance ?

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

Re: [j-nsp] VPLS pass tagged/untagged traffic

[Chris Kawchuk]

> Chris,
> 
> Thanks, I just tried it and this works...guess I was making it more difficult 
> that it needed to be.  I haven't tested spanning tree through it or other 
> layer2 control protocols but you are thinking they should pass through just 
> like and l2vpn?
> 
> Thanks again,
> 
> Kevin


Correct. They all pass into the VPLS instance "unmolested" as I like to call 
it. (RSTP, CDP, PVST+ etc..)

FWIW - I use this on SRX as MPLS-capable CPE for our VPLS service. (via 
targeted LDP L2CKT to the BGP VPLS on the "main PE"). This is a standard H-VPLS 
scenario, with a primary and a backup PE declared on the CPE). ( Naturally 
works on the native MX port as well, even without invoking an H-VPLS topology).

For sakes of completeness -- I use LDP<>BGP Internetworking in PE's VPLS to 
"stitch' the CPE's L2CKT into the VPLS instance directly, without using lt-* 
interfaces. Scales well & provides PE redundancy. Easily enough done (check the 
Juniper JMV course on VPLS -- this is covered in detail on the later chapters 
on how to do both LDP and BGP-VPLS in the same instance, and do it reasonably 
effectively via no-tunnel-services).

Anyways - doing the interface that way passes everything I can think of; sans 
LACP, but who the heck runs LACP into a multipoint VPLS anyways? =) (thats more 
of an E-LINE/P-to-P TLS service)

Glad it worked out for you.

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

Re: [j-nsp] VPLS pass tagged/untagged traffic

[Chris Kawchuk]

Err, why not just something like:

interfaces {
 ge-1/1/0 {
 mtu 9192;
 encapsulation ethernet-vpls;
 unit 0;
 }

That will accept untagged, tagged, double tagged, etc... It makes the VPLS "not 
care" whats going on in that port. Doesnt even care about TPIDs. Even takes 
spanning tree and such.

Ensure not to declare any vlan-id in the routing-instance VPLS {} stanza. No 
translations ingress/egress.

- Ck.



On 09/03/2015, at 9:19 AM, Adam Vitkovsky  wrote:

> on the PE1 logical system:
>  interfaces {
>  ge-1/1/0 {
>  native-vlan-id 4096
>  unit 0 {
>  encapsulation vlan-vpls
>  vlan-id-range 1-4096
>  family vpls; (have tried with and without this)
>  }
>  }

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

Re: [j-nsp] Comments display (annote command) via show command !!

[Chris Kawchuk]

I highly suggest always using the normal "show configuration" commands, as 
you'd also miss things like this in your lo0.0 filter:

term block-ntp {
from {
protocol udp;
##  
## Warning: statement ignored: unsupported platform (ex4550-32f)
##
port ntp;
}
then {
discard;
}
}

^^ and my guys wondered why local DNS requests and SNMP polls didn't work for a 
week...

- Ck.


On 19/02/2015, at 12:12 AM, Dovid Bender  wrote:

> Afaik it never shows in display set because comments aren't entered with set.
> 
> Regards,
> 
> Dovid
> 
> -Original Message-
> From: Asad Raza 
> Sender: "juniper-nsp" Date: Wed, 18 Feb 
> 2015 10:23:54 
> To: Harri Makela
> Cc: 
> Subject: Re: [j-nsp] Comments display (annote command) via show command !!
> 
> Hi,
> 
> Show configuration in operational mode (without display set) displays the
> comments.


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

Re: [j-nsp] Protect-re

[Chris Kawchuk]

http://www.team-cymru.org/ReadingRoom/Templates/


On 26/11/2014, at 11:48 AM, Rodrigo 1telecom  wrote:

> Hi folks... We have some firewall rules to protect our router... But i want 
> to know what kind of rules you guys implement to protec re?! And what you 
> sugest to use?! 



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

Re: [j-nsp] LACP/LAG

[Chris Kawchuk]

I sometimes use LACP as well as a "poor man's BFD"; in the case of "the lights 
are on, but nobody's home" syndrome.

aka a situation where the physical link(s) may be up, but the control plane 
functions are dead at the far end. Without LACP control packets, you may 
inadvertently start trying to send traffic down a link where the other end 
isn't actually functional yet. That's a definite case, albeit for a single-link 
LACP. 

If you can turn it on, and both sides support it, then I suggest using it; I 
haven't seen any harm IMHO.

- CK.


On 18/10/2013, at 8:00 AM, Keith  wrote:

> Both sides came up on the MX and it looks ok. Am I going to get bitten in the 
> ass
> at some point for not running LACP?


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

Re: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX

[Chris Kawchuk]

How about a default 0.0.0.0/0 with a bfd-liveliness detection.

We use this for conditionally routing statics every now and then. 

Works well assuming the next-hop supports BFD; and no dynamic routing protocol 
needed.

- CK.


On 16/08/2013, at 7:15 AM, Darren O'Connor  wrote:

> You could run VRRP on R1 and R2 giving R1 the higher priority. Have the 
> static default on the SRX3600 pointing to the VRRP IP
> 
> Darren
> http://www.mellowd.co.uk/ccie
> 
> 
>> From: barakat-ah...@hotmail.com
>> To: juniper-nsp@puck.nether.net
>> Date: Tue, 13 Aug 2013 13:16:49 +0300
>> Subject: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX
>> 
>> Dear All
>> 
>> 
>> 
>> We have high end SRX3600 connected to layer2 switch and then to two gateway
>> routers, and we have a static default route to R1 with default preference
>> (5) and to R2 with preference 10, we need to track the IP of R1 so that in
>> case we couldn't ping R1 the route to prefer R2 i.e. in case the link
>> between R1 and the layer2 switch went down the route to prefer R2.
>> 
>> Noting that we were able to accomplish the above requirements with branch
>> SRX using either two options (set services ip-monitoring) or (set services
>> rpm)
>> 
>> Unfortunately the mentioned commands are not supported on high end SRX
>> 
>> Any ideas.
>> 
>> 
>> 
>> Regards
>> 
>> A.Hasan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] SRX210 + AppTrack. How to analyse?

[Chris Kawchuk]

Netflow.

The SRX's can do RE-Based sampling and generate Netflow v5 packets easily for 
secondary analysis. Same way you'd do it on an M/MX series wight he standard 
ops caveats. ( http://juniper.cluepon.net/index.php/Cflowd_configuration ).

I've done this myself on an SRX210 at one of our offices for just this purpose. 
Works well. Just need any 3rd party Netflow analyzer (caida, intermapper, 
ns2flows, proqsys, -insert tool of your choice- etc..). I was using ProQsys 
myself.

Nice way is you can shoot the data anywhere on the internet (including back to 
your HQ across the internet if you want to do the analysis for him).

- CK.

On 12/08/2013, at 3:11 PM, Skeeve Stevens 
 wrote:

> Hey all,
> 
> I have a customer in a bandwidth sensitive location (expensive and slow),
> and they would like to know what is going through their device, and who is
> doing it.
> 
> 
> So what I am looking for is... How can we look at their device, and see
> what is happening (preferably live) on a protocol and user (IP?) basis.


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

Re: [j-nsp] Firewall filter -EX4500

[Chris Kawchuk]

And you can omit the "source-address"  (i.e. it ignores the source IP now) and 
it matches all source IP traffic.

from {
 destination-prefix-list {
  F5Traffic-IP;
 }
then {
 accept;
}



On 09/07/2013, at 11:22 PM, Andy Litzinger  
wrote:

> I think your source ip range netmask should be /0, not /32.  I.e: 0.0.0.0/0
> 
> 
>> 
>> from {
>> 
>>   source-address {
>> 
>>   0.0.0.0/32;
>> 
>>   }
>> 
>>   destination-prefix-list {
>> 
>>   F5Traffic-IP;
>> 
>>   }
>> 
>> }
>> 
>> then accept;


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

Re: [j-nsp] Vlan question MX

[Chris Kawchuk]

802.1p QoS Signalling through a Metro-E. May be a switch/switches in-between 
the customer CPE and the MX.

No VID, No P bit.


On 09/07/2013, at 8:00 AM, Tom Storey  wrote:

> If you're plugged in to a router interface on the providers side, why is
> there a need to add VLAN tagging on top? Similarly, if you're plugged in to
> a switch, normally the switch port is just an access port, not a trunk.
> 
> Someone help me out here... :-)


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

Re: [j-nsp] LSP mapping

[Chris Kawchuk]

instal-nexthop lsp [ r7-r3 r7-r3-second-path ];


On 10/06/2013, at 11:29 PM, moki  wrote:

> install-nexthop lsp r7-r3;

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

Re: [j-nsp] M120 - Netflow/Jflow Export

[Chris Kawchuk]

RE based Sampling:

http://juniper.cluepon.net/index.php/Cflowd_configuration

- CK.

On 06/06/2013, at 9:01 AM, Jake Jake <2012j...@gmail.com> wrote:

> Hi All,
> 
> Is it possible to export netflow/jflow from a M120 router(Junos 11.1) to an
> external netflow analyser on the network without a Multiservice PIC
> installed?  It would be great with a sample configuration that need to be
> applied on the router.
> 
> 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] EX switches - jumbo frames - vlan interface - interface range - virtual chassis

[Chris Kawchuk]

Need to set the "physical" master routed vlan interface to something large:

interfaces {
vlan {
mtu 9192;  /* whatever the max allowed is */
unit 10 {
family inet {
mtu 9000;
address 10.10.10.1/24;
}
}

That should let you send a 9k IP paacket without fragmentation.

- CK.



On 19/03/2013, at 11:53 PM, pkc_mls  wrote:
> 
> 
> [edit interfaces vlan]
> unit 10 {
>family inet {
>address 10.10.10.1/24;
>}
> }

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

Re: [j-nsp] MTU problems over VPLS

[Chris Kawchuk]

How does one send back an ICMP please-fragment-this Message when you're 
emulating a blue wire?

No router in the middle to send back to the customer. it's an L2 service. 
You're transparent to them IP-wise. No IP interface anywhere inside their 
bridge to source a packet from.

- Ck.


On 2013-02-12, at 5:57 PM, Luca Salvatore  wrote:

> I have a few sites connected via a VPLS core.  The core devices are all MX 10 
> routers connected via 10Gb fibre.
> I'm having problems doing file copies (SCP between two Centos VMs).
> 
> The issue is that the file copy never gets anywhere, on the Centos CLI it 
> sits at 0% then says 'stalled'
> To fix this issue I have just set the MTU on the Centos machines to be 1400 - 
> when this is in place the copy works and I get nice speeds.
> 
> I don't believe I should have to modify the MTU though, shouldn't path MTU 
> discovery take care of this?
> 
> For example - I have done some TCPdumps, I can see the sender is sending 
> traffic with the DF bit set, however I don't see any 'ICMP fragmentation 
> needed' coming back from the MX saying the MTU is too big, I assume this 
> should be the case.
> 
> I haven't modified any of the MTU's on the MX, everything is just the default.
> 
> I also have normal layer 3 running over the fibre between the routers and 
> when I use that I don't see any issues, so it must be something to do with 
> VPLS.
> 
> Any thoughts would be greatly appreciated.
> 
> Thanks
> Luca.
> 
> ___
> 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] MPLS and QoS at penultimate hop ?

[Chris Kawchuk]

> *UNLESS* you use table-label in a l3vpn, then it gets re-classified after the 
> label POP.

Aha, Very true - Good ole vrf-table-label

So, to Alexandre for L3VPN, just do this:

class-of-service {
routing-instances {
all {
classifiers {
exp MY-CLASIFIER;
}
}
}
}

That'll take care of the vrf-table-label corner-case where the packet goes 
in/out the vt.x/lsi.x interface. 

This is in the Juniper Docs in either the COS manual or the MPLS VPN 
Configuration guide; can't remember.. but remember looking this up just last 
week.

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

Re: [j-nsp] MPLS and QoS at penultimate hop ?

[Chris Kawchuk]

It was my understanding that the label was "logically" popped on Egress (in 
terms of how one would envision the packet flow); hence the outer label EXP 
bits were evaluated by the BA classifier on ingress properly. (Whether it's 
popped on ingress, yet evaluated prior-to-pop is a mechanics thing..)

But yes, I have no documentation I can point to; off the top of my head that 
the above is indeed true. I would be interested to know for future information 
sake that the JNPR box is indeed "doing the right thing" so to speak… i.e. 
since the PIC/MPC pops the Layer-2 information as well, it needs to be able to 
read the 802.1P bits, if there is a 1p-VLAN tag BA applied to the interface. 
Hopefully we're also reading the outer EXP label at the same time; as this 
would make sense.

i.e. if you're doing VLAN pop/swapping, you'd need to retain any BA-p-tag 
specific classification there as well, prior to any tag manipulation.

400 quatloos says it's done on ingress before the label is popped.

- Ck.


> 
> Simple question I'm not able to find answer for: what is the order 
> of label pop operation and BA classification on penultimate router ? 
> 
> I have a gut feeling that label is stripped first and then BA 
> classification is done on a "naked" packet, f.e., ipprec-based
> in case of IP packet, without taking (already stripped) EXP bits into 
> account, but I can't find any documentation proving or disproving it... 


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

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

[Chris Kawchuk]

We use '6' for "customer network control". Customers giving us a 6 or a 7, we 
place into this queue.

i.e. We never allow and end-user to place any of his/her traffic into queue 7 
(which is 'our' NC queue - and has higher priority than '6' in our 
implementation)

We police/mark/identify on ingress; and use a second 802.1q p-bit or MPLS EXP 
bits to ensure we don't manipulate the customer's packet (thus the '6' markings 
are transparent to the end user).

Clean. Simple. Consistent.


On 12/01/2013, at 9:08 AM, Eduardo Barrios  wrote:

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


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

Re: [j-nsp] netflow to Jflow

[Chris Kawchuk]

You have NTP enabled, and it's properly synced?

- CK.

On 2012-12-04, at 4:28 AM, Ali Sumsam  wrote:

> The Experts Who The Experts Call
> Juniper - Cisco – Brocade - IBM


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

Re: [j-nsp] export OSPF routes as type 1

[Chris Kawchuk]

> I'm trying to export some OSPF routes as type 1 external instead of the 
> default type 2 external.
> I can't seem to find where it is done - I thought it would be done in the 
> policy map but I don't see an option.


policy-options {
policy-statement my-ospf-export-policy {
term static-and-direct-as-type-1 {
from protocol [ static direct ];
then {
external {
type 1;
}
accept;
}
}
}
}

- CK.



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

Re: [j-nsp] VPLS Multihoming

[Chris Kawchuk]

Correct (Assuming each PE only has 1 Link to the CE Network…)

Chris
 - Chairman of the "STP is evil and should be avoided if possible" Committee. =)


On 2012-11-28, at 1:24 PM, Luca Salvatore  wrote:

> Right, this is what I thought.  Thanks for the info.
> So this type of configuration means that spanning-tree is not needed between 
> CE and PE then?


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

Re: [j-nsp] VPLS Multihoming

[Chris Kawchuk]

On 2012-11-28, at 9:36 AM, Luca Salvatore  wrote:

> So - my understanding is that VPLS multihoming is used to prevent layer 2 
> loops.  How is this accomplished?
> Is it because the backup PE device does not forward any traffic (except for 
> LDP stuff) and hence no loop is formed since backup PE is in a sort of 
> 'blocking' state?

The backup PE signals (to the rest of the network) that it isnt the 
"designated" PE for that particular site-identifier endpoint (due to the 
priority setting) via BGP. All the other PEs in the network simply don't 
forward traffic to it, nor does that 'backup' PE forward any CE traffic into 
the network. Ergo, no L2 loop.

"show vpls connections" should reflect this state of affairs.

- CK.



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

Re: [j-nsp] VLAN-CCC: Protocol Connection

[Chris Kawchuk]

You cannot tie 2 different connections/LSPs to the same interface, as CCC's are 
purely point to point Layer-2.

You are attempting to do point-to-multipoint Layer-2 ethernet, hence VPLS is 
the solution here.

- CK.

On 2012-11-25, at 10:28 AM, Saba Sumsam  wrote:

> Hi,
> I came across this post on Juniper NSP regarding VLAN-CCC:
> 
> http://puck.nether.net/lists/juniper-nsp/1609.html
> 
> I am stuck with the exact same issue. Was wondering if there is a way to
> achieve this?


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

Re: [j-nsp] CCC on EX, link state propagation

[Chris Kawchuk]

BTW, I also saw in the 12.2 Release Notes that LDP-based L2CKTs are now 
supported on the EX4500/4550.

You can maybe use an l2circut/L2CKT instead of a CCC; using martini style 
status-tlvs to signal end-to-end availability.
...Haven't tried this in the Lab yet. Might be worth a shot to drop the 
interface ccc-style.

- CK.


On 2012-10-11, at 11:03 PM, Benny Amorsen  wrote:

> Benny Amorsen  writes:
> 
>> Can the EX series do that? I'm thinking of the EX4550 in particular, but
>> information about other EX-switches is welcome as well.
> 
> I hate to reply to myself, but according to
> http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#mpls-features-by-platform-table
> the EX4550 cannot do CCC at all. That makes it all rather moot :) The EX4500 
> can, in 12.2.
> 
> It looks like I will be doing q-in-q-tunnelling instead of CCC.
> 
> 
> /Benny
> ___
> 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] Config help for basic MPLS setup

[Chris Kawchuk]

Really? Wow. !

That must be new that the EX4200 supports LDP. 

Which version of JunOS did they add LDP support into the 32/42 EX-series?

Just tried checking the JNPR website and the data sheets. All I can find 
officially is RSVP/CCC support. Let me know where you spotted that. That opens 
up an entire avenue for Metro-E Deployments versus using MX or ACX series.

- CK.


On 2012-09-26, at 6:54 PM, Abdullah Baheer  wrote:

> Actually Chris, in my experience, i think you must have LDP to run LSP/CCC on 
> ex-4200, cough.. cough...


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

Re: [j-nsp] Config help for basic MPLS setup

[Chris Kawchuk]

I've always had troubles using an EX4200 as a "P" router.

The only way Ive gotten it to "kinda" work is to build an LSP with the endpoint 
having protocols { mpls { explicit-null; }}, so any EX4200 in the middle 
doesn't try to 'pop' the outer label if it happens to be the penultimate… 
although my memory is sketchy on this… (I *think* I got it working across an 
EX4200 as a "P" this way.. Your Mileage May Vary) 

The only MPLS thing Ive ever seen in use is to make CCC's. i.e. think of using 
an EX4200 device as an olds-style "ATM Edge" Device, where it turns ethernet 
into a PVC/RFC1483..cough.cough.. I meant an LSP/CCC. Thats about the only 
application I have found. LDP is a no-go as well, so L2CKT/Martini isn't 
possible either…

- CK.

On 2012-09-25, at 5:51 PM, Phil Mayers  wrote:

> On 09/25/2012 03:16 AM, Tim Jackson wrote:
>> I'm pretty sure this is the case. EX4200 will not forward anything with > 1
>> label.
> 
> Just... wow. What is MPLS even *for* on those boxes?

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

Re: [j-nsp] SRX NIC Teaming

[Chris Kawchuk]

However, if the "teaming" you want to achieve is purely for redundancy, 

..This can be enforced on the Server-side (in some type of active/passive 
control on the server's OS), and hence you can just make the SRX's use normal 
access ports.

Weve done this for our VMWare clusters; as well as for individual servers which 
support this. The server controls which ethernet cable it forwards/listens to. 
Nothing much to do on the switch/srx/ex side of the equation.

- Ck.


On 2012-08-30, at 4:18 AM, Misha Gzirishvili wrote:

> Sorry, I misunderstood your question first time.
> 
> Aggregating ports from different SRXes in cluster, do not works.
> Regards,
> Misha
> ___
> 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] Errors on Juniper M7i

[Chris Kawchuk]

Got LSPs and RSVP/LDP paths in inet.3?

- CK.

On 2012-08-27, at 11:00 PM, Frank Norman wrote:

> Friends,
> 
> i am getting following messages on my M7i Router which are causing problem
> with the MPLS VPN customers.   Can someone explain me how to diagnose and
> resolve the issue???
> 
> Junos Version is 8.5
> 
> Aug 27 17:45:47 2012  R3-Atlanta /kernel: RT_PFE: NH IPC op 29 (CHANGE
> INDIRECT NEXTHOP) failed, err 5 (Invalid)
> Aug 27 17:45:47 2012  R3-Atlanta /kernel: RT_PFE: NH IPC op 7 (ADD UNILIST
> NEXTHOP) failed, err 5 (Invalid)
> Aug 27 17:45:47 2012  R3-Atlanta /kernel: RT_PFE: NH IPC op 29 (CHANGE
> INDIRECT NEXTHOP) failed, err 5 (Invalid)
> Aug 27 17:45:54 2012  R3-Atlanta cfeb NH: Failed to find nh (1327) for
> deletion
> Aug 27 17:45:54 2012  R3-Atlanta cfeb NH: Failed to find nh (262566) for
> deletion
> Aug 27 17:45:54 2012  R3-Atlanta cfeb NH: Failed to find nh (1314) for
> deletion
> Aug 27 17:45:48 2012  R3-Atlanta cfeb NH: Indirect nh (262579) with unknown
> target nh (262321)
> Aug 27 17:45:49 2012  R3-Atlanta cfeb NH: Unilist nh (262323) with unknown
> nh in list (1315)
> Aug 27 17:45:49 2012  R3-Atlanta cfeb NH: Indirect nh (262567) with unknown
> target nh (262323)
> Aug 27 17:45:49 2012  R3-Atlanta cfeb NH: Unilist nh (262325) with unknown
> nh in list (1313)
> Aug 27 15:51:15 2012  R3-Atlanta cfeb NH: Unilist nh (262430) with unknown
> nh in list (1641)
> Aug 27 15:51:15 2012  R3-Atlanta cfeb NH: Non-existant NH (1641:Unicast, 2)
> in generic change path
> Aug 27 15:51:15 2012  R3-Atlanta cfeb NH: Non-existant NH (1764:Unicast, 2)
> in generic change path
> Aug 27 15:51:15 2012  R3-Atlanta cfeb NH: Indirect nh (262466) with unknown
> target nh (262430)
> Aug 27 15:52:11 2012  R3-Atlanta /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP)
> failed, err 5 (Invalid)
> Aug 27 15:52:11 2012  R3-Atlanta /kernel: RT_PFE: NH details: idx 1766 type
> 2 ifl 125
> Aug 27 15:52:11 2012  R3-Atlanta /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP)
> failed, err 5 (Invalid)
> Aug 27 15:52:28 2012  R3-Atlanta /kernel: RT_PFE: NH IPC op 28 (ADD
> INDIRECT NEXTHOP) failed, err 5 (Invalid)
> Aug 27 15:52:28 2012  R3-Atlanta cfeb L2RW: Fails to install L2 program
> Aug 27 15:52:28 2012  R3-Atlanta cfeb NH(nh_ucast_add): NULL l2rw_pgm_cptr
> Aug 27 15:52:28 2012  R3-Atlanta cfeb NH: Unilist nh (262426) with unknown
> nh in
> 
> 
> -Frank
> ___
> 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] SRX & MPLS

[Chris Kawchuk]

Shouldn't affect it in the classical BGP active./backup sense; only 1 'vrf' is 
active in a multi-homing BGP setup.

However, since the SRX/J doesn't do that, both will end up being active -  
You'll need a way to suppress one of them from getting any traffic. Perhaps 
think about using an EX4200 underneath using an RTG to each SRX at layer 2 to 
prevent the loop.

Should have zero effect on vrrp/layer-3 stuff.

- CK.


On 23/08/2012, at 7:47 PM, Johan Borch  wrote:

> Your'e right of course :)
>  
> My question was more how the VPLS multihoming will affect this setup.
>  
> Regards
> Johan
> 
> On Thu, Aug 23, 2012 at 11:21 AM, Chris Kawchuk  wrote:
> Err VPLS Implies Layer 2 only.
> 
> Where is the VRP runninng in-between? Are you doing "vlan-id" inside the VPLS 
> instance for normalization, then binding an irb.x into it? I dont think that 
> works in SRX/J either. (l3 within VPLS).
> 
> - CK.
> 
> On 2012-08-23, at 6:39 PM, Johan Borch wrote:
> 
> > "VPLS multihoming, which allows connecting a CE device to multiple PE
> > routers to provide redundant connectivity, is not supported on J Series or
> > SRX Series devices"
> >
> > I'm going to have two SRX's on each site and using vrrp between them, will
> > I hit this exception then?
> 
> 


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

Re: [j-nsp] SRX & MPLS

[Chris Kawchuk]

Err VPLS Implies Layer 2 only. 

Where is the VRP runninng in-between? Are you doing "vlan-id" inside the VPLS 
instance for normalization, then binding an irb.x into it? I dont think that 
works in SRX/J either. (l3 within VPLS).

- CK.

On 2012-08-23, at 6:39 PM, Johan Borch wrote:

> "VPLS multihoming, which allows connecting a CE device to multiple PE
> routers to provide redundant connectivity, is not supported on J Series or
> SRX Series devices"
> 
> I'm going to have two SRX's on each site and using vrrp between them, will
> I hit this exception then?


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

Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP "BPDU-less" situations?

[Chris Kawchuk]

Hi Clarke,

We pass through BPDUs through VPLS the MX'es- but yes, miscreant users / 
switches will always be a problem.

We do the following to every customer-facing VPLS instance, but only #3 would 
help you here:

1. Mac Limiting per VPLS Interface (100) (i.e per 'site')
2. Mac Limiting per VPLS (500)
3. Limit Broadcast/Unknown Unicast/Multicast Traffic (5 Mbit) into the VPLS

You can put on an input firewall filter which calls a 5 Mbit policer at 
[routing instances  forwarding-options family vpls <>] to start 
limiting this type of traffic into the 'bridge domain' at any time.

- CK.


On 18/08/2012, at 1:08 AM, Clarke Morledge  wrote:

> We have had the unfortunate experience of having users plug in small 
> mini-switches into our network that have the capability of filtering out 
> (by-default) BPDUs while allowing other traffic through.  The nightmare 
> situation is when a user plugs in such a switch accidentally into two of our 
> EX switches.  Traffic will loop through the miscreant switch between the two 
> EXs and without BPDUs it just looks like MAC addresses keep moving between 
> the real source and the two EXs.
> 
> In an MX environment running VPLS, this problem can happen easily as there 
> are no BPDUs even to protect against loops in VPLS, particularly when your 
> VPLS domain ties into a Spanning Tree domain downstream where your potential 
> miscreant switch may appear.
> 
> I am curious to know if anyone has come up with strategies to kill these 
> loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting 
> may help, but it doesn't kill loops completely.  I am looking for ways to 
> detect lots of MAC address moves (without polling for them) and blocking 
> those interfaces involved when those MAC moves exceed a certain threshold via 
> some trigger mechanism.
> 
> Assume Junos 10.4R10 or more recent.
> 
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
> ___
> 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] SSH access and not working firewall policy

[Chris Kawchuk]

One possibility - They're coming from inside your own network =)

Whats the source IPs on the attempts, and what device is this (EX? MX? J? 
QFabric?)

- CK.

On 2012-08-13, at 5:07 AM, Robert Hass wrote:

> Hi
> 
> I have Juniper running 10.4R7 with RE filter applied to lo.0 but I
> still see bruteforce attacks to my SSH in log messages.
> 
> .


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

Re: [j-nsp] VLAN into a VPLS instance

[Chris Kawchuk]

Use an LT to crones-connect the bridge-domain with the vlan access interfaces 
(which you do a push-vlan-tag on ingress), and stitch the LT into the VPLS 
instance.

I was going to say "sure, put the access ports into a VPLS and do a vlan-push 
on ingress; and a pop on egress" but yes, that raises an issue as it would pop 
ANY packet returning from the MPLS-universe trying to leave the VPLS (and not 
just the one with the specific vlan tag); so you'd end up with "leakage" from 
the cloud.

- CK.

On 10/08/2012, at 7:50 PM, William Jackson  wrote:

> Hello
> 
> I want to setup an MX with multiple access ports in VLAN, I then want to 
> bridge that vlan into a VPLS instance.
> 
> So all L2, no interface vlan.XX stuff, is this possible?
> 
> 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] Broadband Model suggestion?

[Chris Kawchuk]

Your Vendor's Sales Rep and Systems Engineer should be more than happy to help 
in this regard. =)

- CK.

On 2012-07-12, at 5:01 PM, Frank Norman wrote:

> Dear friends,
> 
> I need suggestion for broadband network based on xDSL & fiber based last
> miles (GPON/Metro technologies), Subscriber base upto 40-50 thousand
> customer,
> 
> Requirement for subscribers will be;
> - Authentication & authorization
> - Dynamic Rate-limiting policing (with Multi service support)
> - Session state monitoring
> - Session Accounting for Billing (prepaid/postpaid)
> 
> and other policies in standard broadband networks.
> 
> 
> Now can someone tell me
> 
> 1) what are the standard models (PPPoE or DHCP ? ) that are being used in
> such kind of broadband networks?? and which is more flexible??
> 
> 2) How is bandwidth management for subscribers is handled?? through the
> same BRAS or by installation of separate devices like packeteer,
> packetlogic etc
> 
> 2) Which devices/vendors can handle these kind of requirements??  (We
> already have AAA radius expertise, so i am only concerned with network
> equipment side)
> 
> 
> 
> Good Day!
> 
> Frank
> ___
> 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] snmp { filter-interfaces {}}; wildcard usage

[Chris Kawchuk]

Apologies, as my REGEX-fu is weak today.

I'm attempting to filter off certain interface from showing up via an SNMP 
walk... i.e. interfaces that are internally generated which really serve no 
purpose outside the JunOS box itself: (lsi.*, lo0.16384, etc)

I want to match any ge-x/x/x interface that has .32767 (which is the RE-to-PIC 
communications interface that is created on many PICs/MPCs/DPCs - which only 
serves to confuse my Ops guys as well as clutter up any MRTG-style graphs.)

This works (as an example) to suppress:

snmp
 {
 filter-interfaces {
interfaces {
lsi.*;
cbp*;
demux*;
pimd*;
pime*;
pip*;
tap*;
lo0.16384;
}
all-internal-interfaces;
}


But this does not (i.e. I cant find a good example of how to match 'any 
interface' as long as it's unit 32767):

snmp
 {
 filter-interfaces {
interfaces {
*.32767;
*32767;
ge*.32767
ge*32767;
}
all-internal-interfaces;
}

Pointers/Suggestions/Example Stanza Appreciated. I will send you a Blueberry 
Pie.

- CK.

P.S. Dear JNPR - any reason we aren't including xxx.32767, lo0.16384, etc.. as 
part of the default "all-internal-interfaces" directive? Seems like a natural 
to me.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cable modem/dsl/ftth bandwidth limiting

[Chris Kawchuk]

Downstream is Shaped, Definitely. 

The BRAS/CMTS/etc sets up Individual Hardware Queues for each traffic class per 
subscriber. (Hence why those boxes have 16,000-64,000 HW queues per blade, as 
each sub may use 2-8 queues depending on what you sell =)..)

Generally 4 prioritized queues (NC, VoIP, Video, Best-Effort), where upper 
queue can generally starve the lower queue, and Tail-drop the BE queue when the 
buffer gets full.

>  For upstream the local customer device would limit.

Bingo. Usually limited by the actual physical upstream bandwidth 
given/negotiated/trained to the CPE device (xDSL upstream link, CMTS-back 
channel, GPON upstream timeslice/frequency etc.). Again, if multi-service, the 
CPE needs to be aware of the traffic classes as well. In Germany, the Telco 
provides the CPE and use different VLAN Tags to prioritize the traffic in each 
direction (Internet on 100, Voice on 200, Video on 300, etc.). Bit of a pain if 
you want to supply your own 'home gateway' in that neck of the woods, as their 
device does it all for you. (incl outbound NAT, etc..)

Hope that all makes sense!

- CK.

On 2012-06-20, at 6:58 AM, Chris Evans wrote:

> Still,  can someone answer if it's shaping or policing?

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

Re: [j-nsp] cable modem/dsl/ftth bandwidth limiting

[Chris Kawchuk]

Layer-2 Cable is done at a BRAS (running in DHCP mode). Layer-3 Cable Plants 
shape at the CMTS.

Layer-2 Optical/GPON/FTTH can be done at a BRAS (if DHCP or PPP), or can be 
done at the head end GPON device; assuming the GPON is reasonably 'smart', and 
understands each subscriber and their associated consumer profiles.

Think VoIP. Need to shape from the network-side before it hits the last-mile, 
so that any SIP/IAD traffic (for a CPE device with a built-in IAD) never gets 
dropped as well. Toss IPTV into the mix, and yes, QoS/Shaping must happen prior 
to the last-mile. (unless you like pixelated TV when your bittorrent client is 
also going full blast =)..)

Remember that Authentication also needs to happen (who's allowed on the 
network, either by PPP l/p or DHCP Mac); as well as traffic counters, so that 
those who do metered--billing (i.e. Australia) can get per-subscriber 
utilization. So, whichever device is holding the "next hop" gateway IP for the 
subscriber is also the device that is doing the downstream shaping; so that the 
utilization counters match what the subscriber has actually used.

- CK.


On 2012-06-20, at 6:46 AM, Chris Evans wrote:

> cable and ftth

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

Re: [j-nsp] cable modem/dsl/ftth bandwidth limiting

[Chris Kawchuk]

Not costly at all; when you think about scaling it to 20,000/30,000 subscribers 
per box.

BRAS's (xDSL, PPPoE, PPPoA) have massive numbers of hardware queues, and 
shape/queue per individual subscriber. These boxes are designed to do this.

Examples: Juniper E-series, Cisco ASR-Series, Juniper MX-series w/the "Q" 
cards, Redback SmartEdge 400/800, etc...

You still need "something in the central network" anyways to aggregate all 
these individual connections from every scubscriber. It's a natural to perform 
this function there; and not at the CPE. Usually it's the link between the 
DSLAM/CMTS/GPON to the Customer that's congested anyways - As Jerry mentioned, 
why transport it just to drop it? May as well rate-limit it upstream before it 
hits the narrow-bandwidth portion of the link to the customer.

- CK.

On 2012-06-20, at 3:19 AM, Chris Evans wrote:

>  performing bandwidth limits on a central network device
> would be too costly to do.


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

Re: [j-nsp] Netflow equivalent for MX5 11.4

[Chris Kawchuk]

JunOS Routing for all intents and purposes is stateless.

It doesn't cache information concerning the IP lookup (CEF-Style), hence 
there's no concept of a 'flow' in JunOS; so nothing per se to 'show'. (each 
packet is processed 'atomically', meaning JunOS doesn't remember that this next 
packet belongs to the same src/dst/port as a previous packet it's already 
processed and forwarded). Each packet is basically unique according to how 
JunOS does things. (With no need to cache, as it does it all wire-speed, plus 
caching/remembering only slows things down when you're in ASIC-land, not speed 
them up). 

You can enable Netflow reporting (cough..cough.. J-Flow I mean =).. If want 
real/actual Netflow records to be created. JuNOS on MX supports inline netflow 
(sampling and creating flow records for flow export), but needs to be enabled 
and exported.

- CK.



On 2012-06-08, at 10:10 AM, Shannon Rigby wrote:

> Hi we have just moved over to MX5's running 11.4 for our BR's we regularly 
> used Cisco command "show ip cache flow" to monitor traffic flows.
> 
> Has anyone had any experience setting up an equivalent in Junos 11.4?
> 
> Thanks in advance
> 
> 
> ___
> 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] CoS - DSCP Markings

[Chris Kawchuk]

On the off chance, are you trying to verify your dscp markings by doing a 
port-mirror on the same device? (i.e. mirror the output of ae1 to another 
output port, and doing a wireshark on it?)

I discovered the hard way that a rewrite happens *after* the port mirror; so 
your mirrored port is showing the packet in the hardware before it's been 
properly re-written. (at least, I discovered this for an EXP rewrite - caused 
me a week of pain in trying to figure out why stuff didnt appear to be working 
on egress...)

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

Re: [j-nsp] CoS - DSCP Markings

[Chris Kawchuk]

> You should be classifying on ingress. 
> Classification is only for 'internal' treatment. Then you do rewrite on 
> egress interface

Actually, You can apply multifield classifiers either at ingress or egress. 
Either way works fine; unless the traffic itself is sourced from the RE (bug in 
MX).

The config actually looks correct a first glance (filling in the missing pieces 
in my mind, of the stanzas that I assume that are there, like a scheduler-map 
against interface ae1 so you're not using the default 2-queues..), and assuming 
this is transiting traffic.

Try doing a:

then {
   loss-priority low;
   forwarding-class FWDCLASS;
   count matched-a-packet;
   accept;
   }

then "show firewall" to see if the counter increases (and hence you're actually 
matching the correct source IP).

what does 'show interfaces ae1 extensive show' for forwarding class 5? (in 
terms of byte counts). i.e. clear the counters first, then run some traffic 
through it, and ensure the outgoing traffic gets queued up in fwding class 5.

Feel free to contact me offline as well.

- CK.


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

Re: [j-nsp] Bridge Domain/IRB on MX80

[Chris Kawchuk]

> Maybe logical tunnel into a bridge? Eg
> https://puck.nether.net/pipermail/juniper-nsp/2011-August/020891.html

^

Yup. I'm using this method right now to backhaul a VLAN off of an CPE 
generating a Martini L2CKT endpoint, stitched into an MX480 bridge-group.

Works well.

Caveat: You lose CoS stuff when things pass through an lt-*. I believe CoS 
classification/remarking on an lt-* is being addressed in a future JunOS 
release. (Although it may work now, haven't checked the latest Release Notes..)

- CK.


>> -Original Message-
>> I am receiving VLAN550 on MX80 (PE) via an LSP
>> I would like to create an L3 Interface on the MX for this
>> VLAN.
> 


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

Re: [j-nsp] JUNOS downloads

[Chris Kawchuk]

Using a unix shell, to download software directly to a router, which itself 
uses a unix shell..? Sorry - That's too clever (and hence; not allowed). =)

- CK.


On 2012-05-22, at 9:29 AM, Richard A Steenbergen wrote:

>   the "proceed" button at the bottom of the 
> EULA acceptance is non-functional in lynx or elinks if you're trying to 
> download your JUNOS images via a unix shell.

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

Re: [j-nsp] Interface to be used for Trunking & MPLS

[Chris Kawchuk]

On 2012-05-18, at 9:29 AM, Saba Sumsam wrote:

flexible-vlan-tagging;
encapsulation vlan-ccc;
unit 0 {
   encapsulation vlan-ccc;
   vlan-id-range 700-800;
   family ccc;
}
unit 400 {
   family bridge {
   interface-mode trunk;
   vlan-id-list 400;
}

Cant do that. Youve told the MX that this port is for VLAN-CCC's only.

You want:

#

ge-1/1/1 {
  flexible-vlan-tagging;
  encapsulation flexible-ethernet-services;< allows different per-unit 
encapsulations
  unit 0 {
 encapsulation vlan-ccc;
 vlan-id-range 700-800;
 family ccc; 
  }
  unit 400 {
 family bridge {
 interface-mode trunk;
 vlan-id-list 400;
  }
}

#

or: (if youre on Trio with an Older JunOS release):

ge-1/1/1 {
 flexible-vlan-tagging;
 encapsulation flexible-ethernet-services;
 unit 0 {
encapsulation vlan-ccc;
vlan-id-range 700-800;
family ccc;
 }
 unit 400 {
encapsulation vlan-bridge
vlan-id 400;
 }
}

bridge-domains v400 {
interface ge-1/1/1.400
}

#

- CK.


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