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
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.. A
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
On Aug 3, 2016 6:52 PM, "Chris Kawchuk" wrote:
> You cannot use MPLS as the "underlay"
This would explain the bandwidth value:
https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR471628
Cheers
On Thu., 4 Aug. 2016, 01:29 Jonathan Call, wrote:
> This is an old switch running 11.4R2. The class-of-service shows nothing
> of significance:
>
> Physical interface: ge-0/0/
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 JNP
Joe
Qfx5100 does not supoort vpls at least in last 14.1 release
Only L2circuit point to point !!!
I will double check but it is almost sure ...
The correct equipment would be ACX5048 for it
EVPN with VXLAN is supoorted but this is a datacenter features that will not
transport protocols bpdu .
Hello,
On 03/08/2016 22:09, Dean B wrote:
Thanks. I think the part I'm missing is associating the IP traffic to an
LSP and how to prevent it from just going back to IGP routing when the LSP
fails.
There are several ways to do that.
1) use forwarding-table policy to associate BGP routes with a
Interesting...but that wouldn't that break locally connected interfaces
that are just IP?
On Wed, Aug 3, 2016 at 4:20 PM, Saku Ytti wrote:
> On 4 August 2016 at 00:18, Saku Ytti wrote:
> > So question is 'how do I ensure, next-hop is only valid when it's via
> > LSP tunnel', I'm sure there is g
On 4 August 2016 at 00:18, Saku Ytti wrote:
> So question is 'how do I ensure, next-hop is only valid when it's via
> LSP tunnel', I'm sure there is good canonical answer to it, but I
> don't know it.
Aah, I think I know. You can define your resolve ribs in JunOS, just
drop inet.0 from there, the
Does anyone have working sample config they can share?
Our SE recommended trying to use EVPN on our 5100's in place of VPLS since
it's not supported on the 5100's. I'm having trouble getting it to work
between two QFX's in my lab.
The QFX's are connected via an MPLS/IP connection with LDP/RSVP/IS
On 4 August 2016 at 00:09, Dean B wrote:
> Thanks. I think the part I'm missing is associating the IP traffic to an
> LSP and how to prevent it from just going back to IGP routing when the LSP
> fails. From everything I can see it will just drop back to IGP routes if
> the LSP disappears.
Good
Thanks. I think the part I'm missing is associating the IP traffic to an
LSP and how to prevent it from just going back to IGP routing when the LSP
fails. From everything I can see it will just drop back to IGP routes if
the LSP disappears.
On Wed, Aug 3, 2016 at 4:03 PM, Saku Ytti wrote:
> Wi
Without reading or doing the work (yay for drive-by-support). Be sure
you forbid the paths from going into secondary paths, just allow them
to fail.
Also look into affinities/colors, you can colour code links, and then
tell LSP which colors it is allowed to traverse. Make all your links
blue, bu
Ok, I have attempted to lab this up...config here
http://pastebin.com/53Ebsd7X
I must still be missing something...BGP appears to still use the IGP and go
across the high-cost link when I disable the low-cost link between B-C:
(on B)
2.2.2.0/24 *[BGP/170] 00:12:13, localpref 100, from 10.
On 3 August 2016 at 19:36, Dean B wrote:
Hey,
> Hey Saku thanks for clarifying...it makes sense now. So for your option "c"
> I would just set the ISIS metric to have a higher cost on the expensive A-C
> link so that it would not normally be used right? I have sample lab logical
> system confi
Hey Saku thanks for clarifying...it makes sense now. So for your option
"c" I would just set the ISIS metric to have a higher cost on the expensive
A-C link so that it would not normally be used right? I have sample lab
logical system config here: http://pastebin.com/uzHtzWrw
I'm assuming I need
On 3 August 2016 at 18:49, Dean B wrote:
Hey,
> Ok, that is going to show how inexperienced I am in MPLS/RSVP/etc. but what
> is the SPT you are referring to and what JunOS config elements does it
Shortest Path Tree (result of SPF algorithm). Essentially I'm talking
how you'll configure your IG
Ok, that is going to show how inexperienced I am in MPLS/RSVP/etc. but what
is the SPT you are referring to and what JunOS config elements does it
correspond to? Having trouble translating the terms into example config
:-) I would probably just start with c (discard 100% of other traffic)
then pe
Hi Josh,
There's no 15.1R6 yet, but 15.1R4 (or 15.1F6 for Features on steroids release
train).
There no new Freebsd on PPC platform (so no SMP, no new partitioning scheme and
so on).
Since 15.1 on PPC is not "Junos OS with upgraded FreeBSD", I suppose there's
just no change about memory alloca
On 3 August 2016 at 18:10, Dean B wrote:
Hey,
> Thanks for everyone's suggestions. RSVP-TE looks like it would be the
> cleanest solution. I'm still a little lost on how that would be
> implemented. Saku in what you are suggesting would the following be
> correct:
>
> ISIS with traffic engine
This is an old switch running 11.4R2. The class-of-service shows nothing of
significance:
Physical interface: ge-0/0/27, Index: 157
Queues supported: 8, Queues in use: 4
Scheduler map: , Index: 2
Congestion-notification: Disabled
Logical interface: ge-0/0/27.0, Index: 123
Object
Hi,
I have a MX104 running 13.3R6.5 that is hitting PR1080566. I'm looking to
either upgrade to 14.2R6 or 15.1R6. I know that a new FreeBSD kernel is
introduced in 15.1, but based on the PPC architecture of the RE-MX-104, I
don't believe I will be able to take advantage of the new kernel so I wo
Thanks for everyone's suggestions. RSVP-TE looks like it would be the
cleanest solution. I'm still a little lost on how that would be
implemented. Saku in what you are suggesting would the following be
correct:
ISIS with traffic engineering enabled on all the ring links
RSVP enabled on all the
On 3 August 2016 at 09:23, Jonathan Call wrote:
> Neither the port nor the switch has any policer/rate limiting policy defined.
> The port is assigned to one VLAN and that VLAN has nothing defined except a
> vlan-id. So where does this "Bandwidth: 100mbps" value for the logical
> interface come
On 2 August 2016 at 23:38, Mark Tinka wrote:
>> I'm not opposed to using RSVP if necessary. All links are MPLS
>> capable...just trying to find a way to not let BGP use the A-C link
>> for IP transit traffic and only use it for protection of the MPLS
>> traffic. A-C is a smaller capacity link th
25 matches
Mail list logo
