from:"Chris Burton"

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

2017-12-02 Thread Chris Burton

For better or worse I do remember those days, though I was referring to 
recent hardware switches/bridges (should have clarified that).  To my 
knowledge that only applies to things like the STP protocols, but I 
could be wrong, again would need to read through the specifications 
again to be sure as that is not a use case I have needed thus far.


Scaling the vMX for testing/lab/PoC deployments can be challenging, but 
I have been able to get large topologies off of a single older model 
dual Xeon E5-2670 server using logical systems, total of seven vMX 
instances and 84 routers using the aforementioned logical systems, at 
that point I run into thermal limits because of the VFP CPU usage (even 
in lite-mode, which only appears to be related to the number of 
interfaces rather than the packet processing, which seems to be the same 
in lite and performance modes hence the CPU usage).  Some months back I 
tried to see how large of a topology I could build with five servers I 
had access to, I was able to get to seven vMX instances per server with 
12 logical systems per vMX instance which gave me a 420 router topology 
using the trial license, so you can scale a lab/PoC setup quite nicely.  
Only downside to using logical systems is they do not support everything 
that a non-LS would support, the biggest missing feature in my case 
being EVPN.


Another item I have been testing is the vQFX which has much less CPU 
demand since the interfaces are bound to the VCP instead of the VFP, but 
I have run into many other issues with that and have not tested it as 
thoroughly, it is also just a alpha/beta release from Juniper at the moment.


-C


On 12/02/2017 03:40 AM, adamv0...@netconsultings.com wrote:

Hey,


local link and not forwarded by the soft bridge by default (I do not know of
any hardware bridges that allow you to disabled this restriction, if you know
of any I would be interested.


My understanding is that Carrier-Ethernet grade switches/routers should allow 
you to peer/drop/tunnel/forward L2 protocols.
If you're in be business long enough you may remember migrations from 
leased-lines to frame-relay and then from FR to MPLS and then from L3VPNs to 
L2VPNs to complete the circle.
These L2 services especially the point-to-point ones, that's where customers 
pretty much expect the same properties as they used to have in leased-lines or 
FR services, basically just a pipe where MTU is not an issue and can transport 
anything from L2 up so they can run their own MPLS/DC networks over these pipes.
 

Out of curiosity what is your use case that you need to use LACP to
communicate with VMs?


Large scale ISP network simulations (for proof of concept testing of various 
designs/migrations/etc).
This allows me to verify my designs, how the technology works on selected code 
versions -if there are any bugs, interworking between vendors.
And there are the provisioning and network monitoring systems, new SDN 
approaches that can be tested in this virtual environment, you name it.
Since it's all virtual one can simulate complete networks rather than scaled 
down slices used in physical labs, so I can see the effects of topology-based 
route-reflection in terms of routes distribution, the effects of node or link 
failures on traffic-engineering and possible congestion as a result across the 
whole backbone all in 1:1 scale, but the important point is to make the 
simulated control-plane as close to reality as possible hence the need for LACP.
  
Speaking of scale, the fact that the VFP is always at 100% CPU is not helping -reminds me of the good old Dynamips -but at least there you could fix it with an idle value.

Having hundreds of these VNFs running is not very green.
  


adam





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

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

2017-12-01 Thread Chris Burton

Glad the conversation helped.  The note about the scripts was a general 
FYI in case there are others looking to use the scripts as there have 
been many conversations about the use of LLDP and LACP with the vMX in 
the past, both on this thread as well as other chats, forums, etc... 
just included for completeness.


LACP and LLDP (and the like) are link local only protocols (would need 
to dig through the specifications to find the exact rules), they should 
not be forwarded by the bridge, otherwise you could break the protocols 
themselves, in the case of LLDP it may be a simple as creating 
troubleshooting nightmare in terms of bad information, but in the case 
of LACP it could cause real harm, that is why they are only transmitted 
on the local link and not forwarded by the soft bridge by default (I do 
not know of any hardware bridges that allow you to disabled this 
restriction, if you know of any I would be interested.  Disabling this 
behavior on soft switch breaks that rule, that being said in the 
virtualized network world there are many things that have changed, so my 
statement was more of a general warning to not implement unless you 
understand and are willing to accept the possible consequences.


I have been running both OVS and Linux Bridge (with modified Kernel) in 
various labs, both large and small for quite some time without any 
issues, so my guess is it would be fine with the above caveats and ample 
precautions, though in production I use physical NICs and SR-IOV based 
NICs so I have not attempted to implement this bypass in production and 
do not know all of the consequences for production deployment.


Out of curiosity what is your use case that you need to use LACP to 
communicate with VMs?


Cheers,

-C


On 11/12/2017 05:36 AM, adamv0...@netconsultings.com wrote:

Chris Burton
Sent: Saturday, November 11, 2017 11:50 PM

This has been discussed a few times on this list and other forums. That being
said, if you are looking to do this with Linux bridge you will need to modify
the net/br_private.h header library to remove the mask restriction placed on
using group_fwd_mask setting in /sys/class/net and recompile the kernel to
allow it forward LACP BPDU's.


My question regarding the Linux bridge was out of curiosity and to my surprise 
spawned a very fruitful discussion which I learned a lot from.
So thank you everyone.
I'm actually using OVS and the "sudo ovs-vsctl set bridge br-1 
other-config:forward-bpdu=true" did the trick.


If you are looking to use Openvswitch you can do as Sergio mentioned and
set the OVS bridge to allow forwarding of LACP BPDU's after you manually
add each interface, but if you want to use the default vmx.sh script to bind
the interfaces with OVS you will need to modify the config/vmx-
junosdev.conf file and add in "use_ovs_transport: True" as a key, and
depending on what version of OS you are running (I presume Ubuntu 16.04)
you may also need to modify the sub-script that vmx.sh --bind-dev calls to
prevent it from checking for the "openvswitch-datapath-source" package. I
have only tested OVS 2.6 (Ubuntu cloud repo) with version 16.1 of VMX, but
unless the sub-scripts are different for earlier or later versions it should 
work
(but it is unlikely to be supported since I do not see mention of using OVS in
any of the official Juniper documents, and they likely will not support this
even if OVS is supported as it breaks standards, same goes for LB mod's).


I'm not using any juniper scripts at all, I need complete control about all 
aspects of the setup and there are VMs of different vendors so I'm using custom 
scripts and procedures to create XMLs, define and start VMs and to interconnect 
them in OVS.



It should be understood though that you are breaking standards
compatibility and could create massive problems on the network, so running
this type of configuration outside of a lab environment should fall under the
do not do it category. If you are going to do this production you should use
physical NICs and SR-IOV with VF’s which eliminates the issue as was
mentioned by James.


As I mentioned earlier, I don't need to talk LACP to PF just LACP between VFs.
Can you elaborate on the "breaking standards compatibility" please?
In my setup I just need hundreds of simple p2p links (basically emulating 
fibres) between VMs so I need the OVS (or other bridge) not to intervene.


adam






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

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

2017-11-11 Thread Chris Burton

This has been discussed a few times on this list and other forums. That 
being said, if you are looking to do this with Linux bridge you will 
need to modify the net/br_private.h header library to remove the mask 
restriction placed on using group_fwd_mask setting in /sys/class/net and 
recompile the kernel to allow it forward LACP BPDU's.


If you are looking to use Openvswitch you can do as Sergio mentioned and 
set the OVS bridge to allow forwarding of LACP BPDU's after you manually 
add each interface, but if you want to use the default vmx.sh script to 
bind the interfaces with OVS you will need to modify the 
config/vmx-junosdev.conf file and add in "use_ovs_transport: True" as a 
key, and depending on what version of OS you are running (I presume 
Ubuntu 16.04) you may also need to modify the sub-script that vmx.sh 
--bind-dev calls to prevent it from checking for the 
"openvswitch-datapath-source" package. I have only tested OVS 2.6 
(Ubuntu cloud repo) with version 16.1 of VMX, but unless the sub-scripts 
are different for earlier or later versions it should work (but it is 
unlikely to be supported since I do not see mention of using OVS in any 
of the official Juniper documents, and they likely will not support this 
even if OVS is supported as it breaks standards, same goes for LB mod's).


It should be understood though that you are breaking standards 
compatibility and could create massive problems on the network, so 
running this type of configuration outside of a lab environment should 
fall under the do not do it category. If you are going to do this 
production you should use physical NICs and SR-IOV with VF’s which 
eliminates the issue as was mentioned by James.


-C


On 11/09/2017 07:30 PM, Sergio D. wrote:

You can use the following on ovs:

ovs-vsctl set bridge  other-config:forward-bpdu=true

according to the ovs-vsctl docs[0] this includes 01:80:c2:00:00:0x which is
LACP.

[0] http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.html



1. Re: [c-nsp] LACP between router VMs (James Bensley)


--

Message: 1
Date: Wed, 8 Nov 2017 18:21:07 +
From: James Bensley 
To: adamv0...@netconsultings.com
Cc: "cisco-...@puck.nether.net" ,
 juniper-nsp 
Subject: Re: [j-nsp] [c-nsp] LACP between router VMs
Message-ID:

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

2017-08-24 Thread Chris Burton

I am not sure why it is not working for you (assuming you have 
bi-directional LSPs in place and no other routing or filter issues), but 
I do recall a previous exchange with you on this list about you possibly 
using the VMX, I have seen randomly at times in the past that when using 
the VMX (not sure if you are using this now or a phy router) with 
logical systems and the logical tunnel interfaces that icmp tunneling 
would not work or would stop working until I shutdown the CP/DP 
(basically a full shutdown and startup), which is why I moved to using 
the built-in interfaces with Linux Bridge as the underlying connection 
as I have not yet seen that same behavior with those interfaces.


-C


On 08/24/2017 08:50 AM, Aaron Gould wrote:


Thanks Shamen,

set logical-systems r2 protocols mpls icmp-tunneling

set logical-systems r3 protocols mpls icmp-tunneling

set logical-systems r4 protocols mpls icmp-tunneling

set logical-systems r5 protocols mpls icmp-tunneling

set logical-systems r6 protocols mpls icmp-tunneling

set logical-systems r7 protocols mpls icmp-tunneling

set logical-systems r8 protocols mpls icmp-tunneling

r1 and r9 are ce’s.

-Aaron



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

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

2017-08-23 Thread Chris Burton

Given that LSP's are by there very nature unidirectional you will need a 
return LSP unless you plan export your VRF routes into your underlying 
network.  The path that that return LSP takes should not make a 
difference unless you are testing specific return path(s), so it should 
not interfere with your learning of RSVP, actually that operation is no 
different than much of standard L3 routing in the wilds of the Internet, 
you are not guaranteed the same path back as the path taken out beyond 
the first hop or few in most cases.



-C

On 08/23/2017 12:10 PM, Aaron Gould wrote:

Thanks, opps, I forgot to tell y'all I tried "set protocols mpls
icmp-tunneling" already and it didn't work.

Also, I need to mention that the vrf between the (2) CE's is built on top of
a unidirectional rsvp lsp I'm testing rsvp te to learn about it and I
only built the lsp in one direction to influence traffic one-way... So
Chris's comments about "sure you have LSP's in both directions"  makes me
wonder if I do the return rsvp LSP for the underlying rsvp te would that fix
it ? (furthermore, must the return rsvp te lsp follow the exact same path
for traceroutes to work ?! this would seem really limiting)

I mean, I have LDP running in the core also, this might be obvious since the
vrf is functional, and I'm pretty sure I would need the mpls control plane
to work bidirectionally to have the vrf function as it is.

Let me know what y'all think.

Ce---peppppppece

---rsvp te from pe to pe >   this direction only... I
allow the igp to decide the return path in the opposite direction


-Aaron











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

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

2017-08-22 Thread Chris Burton

The command you are looking for "set protocols mpls icmp-tunneling", 
also need to make sure you have LSP's in both directions.


-C


On 08/22/2017 06:39 PM, Aaron Gould wrote:

I know that this is a known thing with mpls networks, and there are a few
tricks with no decrement ttl or no propagate ttl to cause P cloud to be
completely invisible. but is there a way to do the opposite?...that is, is
there a way to cause the P routers to be seen on traceroute ?  I understand
that ttl expired in transit messages need to be able to be sent back to the
CE that sent the low-ttl packets to begin with and since p router probably
won't have the vrf-specific routes of that ce, then, well.. I guess I'm
wondering if there's some trick command that allows the p router to send
back the ttl-expired-in-transit messages simply via the same mpls label
values via the lsp that they arrived on. or whoever it would work. ?

  


- trace initiated be CE r1

  


r1@lab-mx104:r1> traceroute 1.1.10.2 wait 1

traceroute to 1.1.10.2 (1.1.10.2), 30 hops max, 40 byte packets

1  1.1.0.2 (1.1.0.2)  0.539 ms  0.646 ms  0.472 ms   < PE

  2  * * *
< P

3  * * *
< P

4  * * *
< P

5  * * *
< P

6  * * *
< P

7  1.1.10.1 (1.1.10.1)  0.611 ms  0.565 ms  0.534 ms   < PE

8  1.1.10.2 (1.1.10.2)  0.569 ms  0.616 ms  0.700 ms   < CE

  


- Aaron Gould

  


___
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] Any sort of EVPN Success with: vMX 16.x and QFX5100

2017-07-31 Thread Chris Burton

I cannot speak to 17.1, but I can tell you I have run several EVPN MPLS 
configurations under VMX (16.1), to my knowledge EVPN VXLAN is not 
supported as previously mentioned, but I have not checked in some time.


Cheers,

-C


On 07/31/2017 05:02 AM, Alain Hebert wrote:

Place a sniffer between the vMX and the QFX, you'll see:

the ARP go from vMX to QFX and get an answer;

the ARP go from QFX to the vMX and you wont get an answer, 
99.% of the time;


( It worked once for me and only for a while, but at this 
point I pretty much feel like I'm getting trolled by J.  That whole 
QFX+L2TP+VCF really didn't help )


PS: We pretty much gave up on that whole  none of the 
whitepaper from J work in a lab setting since they forgot to list the 
hardware and the Junos version they used.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 07/27/17 05:47, Anand Beedi wrote:

Hello,

I am facing similar problem with EVPN over MPLS. I am using 
17.1R1.8 Junos build. The control plane, mac table looks fine. I see 
ARP resolved on one-end but other is not happening


Issues with both instance-type as EVPN or Virtual-switch with 
EVPN.  No IRB configured.


Any help

Output of Ping and tcpdump on both sides

** 


   Ping f=>  21.1.1.1
** 



root@cuttack> ping 21.1.1.1 interface ge-2/0/4.2345
PING 21.1.1.1 (21.1.1.1): 56 data bytes
++
root@cuttack:~ # tcpdump -i ge-2/0/4.2345 -s 1500
Listening on ge-2/0/4.2345, capture size 1500 bytes

09:58:38.787719 Out arp who-has 21.1.1.1 tell 21.1.1.2
09:58:39.588860 Out arp who-has 21.1.1.1 tell 21.1.1.2
09:58:40.388273 Out arp who-has 21.1.1.1 tell 21.1.1.2
09:58:41.188860 Out arp who-has 21.1.1.1 tell 21.1.1.2

root@kochin% tcpdump -i ge-0/0/6.2345 -s 1500
Listening on ge-0/0/6.2345, capture size 1500 bytes

arp who-has 21.1.1.1 tell 21.1.1.2
arp reply 21.1.1.1 is-at 80:71:1f:16:38:06
arp who-has 21.1.1.1 tell 21.1.1.2
arp reply 21.1.1.1 is-at 80:71:1f:16:38:06
arp who-has 21.1.1.1 tell 21.1.1.2
arp reply 21.1.1.1 is-at 80:71:1f:16:38:06
arp who-has 21.1.1.1 tell 21.1.1.2

** 


  Ping => 21.1.1.2
** 



root@kochin> ping 21.1.1.2
PING 21.1.1.2 (21.1.1.2): 56 data bytes

root@kochin% tcpdump -i ge-0/0/6.2345 -s 1500

IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 4, length 64
IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 5, length 64
IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 6, length 64
IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 7, length 64

root@cuttack:~ # tcpdump -i ge-2/0/4.2345 -s 1500

Listening on ge-2/0/4.2345, capture size 1500 bytes

^C
0 packets received by filter
0 packets dropped by kernel




Cheers,
Anand


Anand Beedi
o   +91 80 612 10427
m  +91 97396 77746
abe...@juniper.net
www.juniper.net


-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On 
Behalf Of Alexander Marhold

Sent: Friday, October 7, 2016 20:46
To: aheb...@pubnix.net; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Any sort of EVPN Success with: vMX 16.x and QFX5100

Hi
As far as I know the paper deals with EVPN over VXLAN And As far as I 
know the vMX 16.1 does NOT support EVPN over VXLAN ( at least that I 
was told by some Juniper SEs and by the PLM manager for EVPN)


Regards

Alexander
INDC

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im 
Auftrag von Alain Hebert

Gesendet: Freitag, 7. Oktober 2016 16:24
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] Any sort of EVPN Success with: vMX 16.x and QFX5100

 Hi,

 We've been working on a lab re-creating a Juniper whitepaper on 
the subject of EVPN, but we cannot figure out where we messed up =D


 Everything show up correctly in the core, spines/leafs, but L2 
broadcast's are not propagated/managed as expected by the Core.


 aka: cannot ping between test devices on access ports for 
the Tenant since ARP broadcast are not answered.


 Anyone got any success?  Or do we have the wrong white paper?

 Thank for your

Re: [j-nsp] cheapest juniper router capable of lsys

2017-06-28 Thread Chris Burton

I will take a look.  I have tested on a number of different versions, 
but nothing as new as 4.11, only been tracking the shipped kernel with 
Ubuntu 14.04 and 16.04, in the 3.1 and 4.4 versions respectively, but 
pulling from upstream and compiling from source instead of Ubuntu src 
packages.


-C


On 06/28/2017 12:09 AM, Vincent Bernat wrote:

  ❦ 27 juin 2017 23:26 -0700, Chris Burton <chris.bur...@speakeasy.net> :


Interesting, in the kernel versions I tested I was not able to get it
to work by just passing in the runtime changes to
/sys/class/net//bridge/group_fwd_mask, I actually had to make
changes to virtual bridge header file and recompile the kernel as
there are/were safeguards in place to prevent someone from just making
the runtime changes, which makes sense because this is a potentially
dangerous change.  Recompiling is not a big deal, but would be
interested to know which kernel versions you were able to get that to
work with just runtime changes as that would save some time.

The different cases are handled here:
  
http://elixir.free-electrons.com/linux/v4.11.5/source/net/bridge/br_input.c#L275

fwd_mask_required is not tunable by the user. Unless you are using
VLAN-aware bridges _and_ QinQ, its value is 0. group_fwd_mask is the
live value you put in sysfs, so it should work. There is a safeguard
mechanism to deny acceptance of 01-80-C2-00-00-[00,0B,0C,0D,0F] when
setting the group_fwd_mask value.

I didn't test recently, but I have used this mechanism in the past for
LLDP. Which kernel are you using?


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

Re: [j-nsp] cheapest juniper router capable of lsys

2017-06-28 Thread Chris Burton

Interesting, in the kernel versions I tested I was not able to get it to 
work by just passing in the runtime changes to 
/sys/class/net//bridge/group_fwd_mask, I actually had to make 
changes to virtual bridge header file and recompile the kernel as there 
are/were safeguards in place to prevent someone from just making the 
runtime changes, which makes sense because this is a potentially 
dangerous change.  Recompiling is not a big deal, but would be 
interested to know which kernel versions you were able to get that to 
work with just runtime changes as that would save some time.


Cheers,

-C


On 06/27/2017 11:05 PM, Vincent Bernat wrote:

  ❦ 27 juin 2017 22:40 -0700, Chris Burton <chris.bur...@speakeasy.net> :


Also, if you use KVM and linux bridge you can bypass the issues with
the bridges not forwarding LLDP and LACP traffic, but you have to
willing to dive into modifying certain parts of the virtual bridge
network drivers and compile your own custom kernel, as by standards
bridges are not supposed to forward the traffic related to LCAP and
LLDP.  I have also heard that this can be bypassed by using Open
vSwitch, but I have not tested that.  The only items I have not yet
been able to get working are related to Ethernet OAM, but so far
everything else I have tested has worked either directly or with some
modification.

On Linux, you can tell the bridge to let LLDP and LACP traffic without
recompiling. This is done by altering the value of
/sys/class/net/brXX/bridge/group_fwd_mask. To let LLDP pass, you need to
put 0x4000 in it. For LACP, this is 0x4. So 0x4004 should let both of
them pass the bridge.


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

Re: [j-nsp] cheapest juniper router capable of lsys

2017-06-27 Thread Chris Burton

I can't speak to Vmware (workstation or vSphere) or Virtualbox, but with 
a few of the vMX licenses and a cheap server off of eBay running Ubuntu 
14.04 or 16.04 and KVM you can run several instances of vMX on a single 
machine.   On a dual Xeon E5-2670 equipped  with 128GB of memory I am 
able to boot and run a total of 7 vMX instances and build a rather 
massive working topologies. Based on the available memory left and CPU 
cycles left I could probably boot several additional instances, but 
because of the aforementioned CPU usage of the data-plane (even with 
lite-mode enabled) I start running into cooling issues on the CPU (temps 
creep into the critical range).


That being said, unless you want to test items that do not work in 
logical systems (for instances EVPN) you can happily run a single 
instance of vMX using multiple logical systems (I have tested up to 12, 
but I think you can go to 15 logical-systems, possibly more), using 
either lt- interfaces or can modify the configuration and run a lot more 
of the built-in interfaces, depending upon version you can get up to 96 
interfaces, though I have only successfully booted up with 48 interfaces 
(things start getting dicey passed 48 interfaces, and it can take 10-15m 
to boot the entire system assuming it does not crash, both control and 
data plane).


Also, if you use KVM and linux bridge you can bypass the issues with the 
bridges not forwarding LLDP and LACP traffic, but you have to willing to 
dive into modifying certain parts of the virtual bridge network drivers 
and compile your own custom kernel, as by standards bridges are not 
supposed to forward the traffic related to LCAP and LLDP.  I have also 
heard that this can be bypassed by using Open vSwitch, but I have not 
tested that.  The only items I have not yet been able to get working are 
related to Ethernet OAM, but so far everything else I have tested has 
worked either directly or with some modification.


Cheers,

-C


On 06/27/2017 02:41 PM, Aaron Gould wrote:

I know, but I'm pretty sure that 15.1F3.11 that I run in my virtual box was a 
vMX download from juniper.net

-Aaron

-Original Message-
From: Valentini Lucio [mailto:lucio.valent...@bvg-systemhaus.it]
Sent: Tuesday, June 27, 2017 3:51 PM
To: Aaron Gould ; 'Vincent Bernat' 
Cc: juniper-nsp@puck.nether.net
Subject: AW: [j-nsp] cheapest juniper router capable of lsys

Olive ist he free version of Junos, tolerated but not supported by Juniper as 
far as I know. It´s made for research and educational purposes, not production.

Hope this helps,

Cheers

LV



-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von 
Aaron Gould
Gesendet: Dienstag, 27. Juni 2017 22:02
An: 'Vincent Bernat'
Cc: juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] cheapest juniper router capable of lsys

Mine says...

I thought this was vMX.  Is it?

root@r8-j> show version
Hostname: r8-jF3.11 built 2015-10-27 19:44:47 UTC
Model: olive
Junos: 15.1F3.11
JUNOS Base OS boot [15.1F3.11]
JUNOS Base OS Software Suite [15.1F3.11]

- Aaron

-Original Message-
From: Vincent Bernat [mailto:ber...@luffy.cx]
Sent: Tuesday, June 27, 2017 1:42 PM
To: Aaron Gould 
Cc: 'Youssef Bengelloun-Zahr' ; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] cheapest juniper router capable of lsys

  ❦ 27 juin 2017 13:33 -0500, "Aaron Gould"  :


I think on my vMX when I type "show version" it says "olive"  :|

For me, it looks like that:

juniper@vMX> show version
Hostname: vMX
Model: vmx
Junos: 16.1R1.7
JUNOS OS Kernel 64-bit  [20160624.329953_builder_stable_10]
JUNOS OS libs [20160624.329953_builder_stable_10]
JUNOS OS runtime [20160624.329953_builder_stable_10]
[...]

Maybe you have an early version (something before 14.1)?
--
The Public is merely a multiplied "me."
-- Mark Twain

___
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] vSRX Policy-based VPNs - unsupported platform

2016-07-15 Thread Chris Burton

Pretty sure policy-based VPN was unsupported for a short period during 
the transition from older code and hardware to the newer, but should be 
back in 15.1X49-D50, though I do not know the version of the current 
trial software available for download.


-C

On 07/15/2016 12:28 AM, Jed Laundry wrote:

Hi Folks,

I'm looking at converting our aged hardware SRX's onto vSRX, but I
seem to have hit a big scary warning when staging config for
policy-based VPNs, see below:

security {
 policies {
 from-zone zone-lab to-zone zone-internet {
 policy policy-test-ipsec {
 match {
 source-address addr-lab-testbox;
 destination-address addr-remote-testbox;
 application any;
 }
 then {
 permit {
 ##
 ## Warning: configuration block ignored:
unsupported platform (vsrx)
 ##
 tunnel {
 ipsec-vpn vpn-remote;
 }
 }
 }


This is vSRX 15.1X49-D40.6 on VMware. It's just the trial version, I
haven't bought a licence yet.

I haven't yet been able to test if this does or doesn't work (next
week), but the warning doesn't look good.

Is anyone else using vSRX with policy-based VPNs?

Is there something fundamental that I've missed, or a configuration
tweak necessary to convert 12.1 config to 15.1?

Thanks,
Jed.
___
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] LACP on mixed virtual chassis QFX5100/EX4300

2015-11-04 Thread Chris Burton

As far as I know there is no way to set the link speed (only the link-mode
for duplex) on the underlying interfaces in a AE bundle (and they are always
labeled xe-), at least on the code I am running on the QFX5100-48T.  You ca
specify the link-speed for a AE interface which I presume sets the speed of
the underlying bundled interfaces, but I have not tested this out as I have
no EX switches.

set ae9 aggregated-ether-options link-speed ?
Possible completions:
  100g Links are 100G
  100m Links are 100M
  10g  Links are 10G
  1g   Links are 1G
  40g  Links are 40G
  50g  Links are 50G
  80g  Links are 80G
  8g   Links are 8G
  oc192Links are OC-192

Chris

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Tobias Heister
Sent: Wednesday, November 04, 2015 10:28 AM
To: ThienDuc Nguyen; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

Hi,

Am 03.11.2015 um 23:23 schrieb ThienDuc Nguyen:
> I was trying to create a LACP bundle between two ports : one on a 
> EX4300, the other on a QFX5100.
> Both link have their speed negotiated at 1GE (but the interface name 
> on the QFX is xe-, I can't force it to ge-, and their are no way to 
> force the speed on the QFX).
> if I set the lacp speed to 1ge, the configuration can't commit because 
> it sees the QFX interface as a 10G interface...
>
>
> Is their a special knob to activate it, or I need to create LACP on 
> the same device family ?  (the version is  14.1X53-D30.3)

 From what you wrote i would suspect that you use a QFX5100 copper version?
If they behave anything like the EX45XX Copper Versions the interfaces will
always be xe- regardless of them being only used with 1GE neighbors. Would
be funny if the interface name would change when lower speeds are
negotiated.

Probably the config parser checks the physical interfaces and finds out that
it is a 10G interface on QFX and 1G Interface on EX and will not commit as
mixed speed AEs are only supported in later MX code.

I do not know a way around that and do not have copper QFX at hand to check.
Probably you will have hit one of these corner case situations that nobody
thought about and nobody ever encountered and nobody ever asked about (at
least if you ask jtac :))

--
Kind Regards
Tobias Heister
___
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] LACP on mixed virtual chassis QFX5100/EX4300

2015-11-04 Thread Chris Burton

Have you tried just setting the EX side and leaving the link-speed statement 
off of the QFX side, since the QFX interfaces are hardcoded to auto negotiate 
only that might work?

 

Chris

 

From: ThienDuc Nguyen [mailto:thienduc.ngu...@zayo.com] 
Sent: Wednesday, November 04, 2015 14:19 PM
To: Chris Burton
Cc: Tobias Heister; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300

 

 

On Wed, Nov 4, 2015 at 11:03 PM, Chris Burton <chris.bur...@speakeasy.net> 
wrote:

As far as I know there is no way to set the link speed (only the link-mode
for duplex) on the underlying interfaces in a AE bundle (and they are always
labeled xe-), at least on the code I am running on the QFX5100-48T.  You ca
specify the link-speed for a AE interface which I presume sets the speed of
the underlying bundled interfaces, but I have not tested this out as I have
no EX switches.

set ae9 aggregated-ether-options link-speed ?

   

If you set the speed to 1G for example, the commit script failed because of the 
xe- interface seen as a 10G interface.

And yes, the speed is blocked as auto (in the show interface extensive | match 
speed)

 

 

Thien Duc

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

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

Re: [j-nsp] Any sort of EVPN Success with: vMX 16.x and QFX5100

Re: [j-nsp] cheapest juniper router capable of lsys

Re: [j-nsp] cheapest juniper router capable of lsys

Re: [j-nsp] cheapest juniper router capable of lsys

Re: [j-nsp] vSRX Policy-based VPNs - unsupported platform

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

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

13 matches

Site Navigation

Mail list logo

Footer information