Re: [j-nsp] BPDUs over EVPN?

[Alexander Marhold]

Vpls not Voldemort 

Von meinem iPhone gesendet

> Am 18.10.2019 um 11:20 schrieb Alexander Marhold :
> 
> Normally in layer 2 like Voldemort and evpn you need a separate 
> layer-2-Control instance to activate layer 2 control protocols like SPT
> IMHO the mentioned behavior is a bug 
> 
> Regards Alexander 
> 
> Von meinem iPhone gesendet
> 
>> Am 18.10.2019 um 11:09 schrieb Rob Foehl :
>> 
>> On Fri, 18 Oct 2019, Gert Doering wrote:
>>>>> On Thu, Oct 17, 2019 at 05:37:16PM -0400, Rob Foehl wrote:
>>>>> Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?
>>> 
>>> The way understand "how things are meant to be plugged together", you
>>> should not see forwarded BPDUs - "containing layer2 madness to one
>>> attachment site" is the whole point, isn't it?
>>> 
>>> I could see very special cases where it would be necessary, but that
>>> would need to be a non-default-enabled switch.
>> 
>> Right, I'd only expect this to work in very specific "make it entirely 
>> transparent" cases...  It looks like both Cisco and Huawei document options 
>> related to BPDU tunneling, and neither enable any of it by default.  Not 
>> coming up with much else for comparison.
>> 
>> Juniper is now telling me that this is occuring by design, but can't point 
>> to any documentation or standards which support that, nor explain why it 
>> suddenly changed post-upgrade.  I'm... not convinced.
>> 
>> -Rob
>> 
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] BPDUs over EVPN?

[Alexander Marhold]

Normally in layer 2 like Voldemort and evpn you need a separate layer-2-Control 
instance to activate layer 2 control protocols like SPT
IMHO the mentioned behavior is a bug 

Regards Alexander 

Von meinem iPhone gesendet

> Am 18.10.2019 um 11:09 schrieb Rob Foehl :
> 
> On Fri, 18 Oct 2019, Gert Doering wrote:
>>> On Thu, Oct 17, 2019 at 05:37:16PM -0400, Rob Foehl wrote:
>>> Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?
>> 
>> The way understand "how things are meant to be plugged together", you
>> should not see forwarded BPDUs - "containing layer2 madness to one
>> attachment site" is the whole point, isn't it?
>> 
>> I could see very special cases where it would be necessary, but that
>> would need to be a non-default-enabled switch.
> 
> Right, I'd only expect this to work in very specific "make it entirely 
> transparent" cases...  It looks like both Cisco and Huawei document options 
> related to BPDU tunneling, and neither enable any of it by default.  Not 
> coming up with much else for comparison.
> 
> Juniper is now telling me that this is occuring by design, but can't point to 
> any documentation or standards which support that, nor explain why it 
> suddenly changed post-upgrade.  I'm... not convinced.
> 
> -Rob
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] good study guide/material for jncis - SP/P

[Alexander Marhold]

Regarding JNCIS-SP that material has not considerably changed, so studying
using that material is Ok to pass the tests
Regarding MPLS only basic MPLS and no MPLS/VPN be it L3 or L2 is part of the
specialist exam

Deeper material regarding SP if you need to go deeper you find in the sybex
book about the mx ( 2nd edition)

With best regards

Alexander Marhold
Ex-Juniper instructor, 4*JNCIP, 3*JNCDS

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
mcbob 58
Gesendet: Dienstag, 14. Mai 2019 08:02
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] good study guide/material for jncis - SP/P

Hi Guys,

I've been looking for good study material for a while, but I can't find
much.

There are PDFs but they are all from 2013 and cannot find a recent one.

Why is it so difficult to find study material for juniper

Can anyone help with this and I would really appreciate it.

br

mc bob

___
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] good study guide/material for jncis - SP/P

[Alexander Marhold]

Also the book "MPLS in the SDN era" is a good material for newer
developments in and around MPLS ( incl. EVPN, convergence enhancements,
LFA,...)
Regards

Alexander

-Ursprüngliche Nachricht-
Von: Alexander Marhold [mailto:alexander.marh...@gmx.at] 
Gesendet: Dienstag, 14. Mai 2019 08:27
An: 'mcbob 58'; 'juniper-nsp@puck.nether.net'
Betreff: AW: [j-nsp] good study guide/material for jncis - SP/P

Regarding JNCIS-SP that material has not considerably changed, so studying
using that material is Ok to pass the tests
Regarding MPLS only basic MPLS and no MPLS/VPN be it L3 or L2 is part of the
specialist exam

Deeper material regarding SP if you need to go deeper you find in the sybex
book about the mx ( 2nd edition)

With best regards

Alexander Marhold
Ex-Juniper instructor, 4*JNCIP, 3*JNCDS

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
mcbob 58
Gesendet: Dienstag, 14. Mai 2019 08:02
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] good study guide/material for jncis - SP/P

Hi Guys,

I've been looking for good study material for a while, but I can't find
much.

There are PDFs but they are all from 2013 and cannot find a recent one.

Why is it so difficult to find study material for juniper

Can anyone help with this and I would really appreciate it.

br

mc bob

___
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] Finding drops

[Alexander Marhold]

As per the requestor original message, I read that the packets are not
counted on INGRESS
There is a diff between received packets and the receive counter

Regards
alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Saku Ytti
Gesendet: Mittwoch, 23. Januar 2019 14:59
An: Jason Lixfeld
Cc: Juniper List
Betreff: Re: [j-nsp] Finding drops

On Tue, 22 Jan 2019 at 20:17, Jason Lixfeld  wrote:


> Transmitting exactly 100 million 64 byte UDP packets.  SPORT:  49184
DPORT: 7.

Ok so ingress interface shows 100M packets coming in, but egress
interface shows only 76M packets going out?

And nothing in  'show int egress extensive'?

What about
start shell pfe network fpc0
show jnh 0 exception terse
show jnh ifd  stream



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

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

Re: [j-nsp] L3VPN/RR/PE on Same router

[Alexander Marhold]

Yes, the PE should do next-hop-self, the RR should not do it
Route reflector can also be EBGP-Border Router, 
General use of next-hop self can result in inefficient forwarding

 use next-hop self only for EBGP learned routes

policy-statement bgp-export {
term ebgp {
from route-type external;
then {
next-hop self;
accept;
}
}
term ibgp {
from route-type internal;
then accept;
}
}

regards

alexander


-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von 
tim tiriche
Gesendet: Donnerstag, 16. August 2018 16:40
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] L3VPN/RR/PE on Same router

Hello,

I have a MPLS PE (L3VPN) router that is acting as full mesh iBGP within the
US.  The other routers in the US are not RR and regular iBGP.  This router
also acts as RR for Europe and takes in full BGP table.  Is there some
caveats to watch out for?
___
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] EX4200 virtual chassis problem, master going into linecard mode

[Alexander Marhold]

Therefore if you want to put one node out of a 2 node VC you need to put the
Master down not the backup
Sounds strange but this is according to the rules stated below

Regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Alexander Marhold
Gesendet: Donnerstag, 26. Juli 2018 09:52
An: 'Tobias Heister'; 'Victor Sudakov'; 'Pavel Lunin'
Cc: 'juniper-nsp'
Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into
linecard mode

Hi 

According to the documentation there should be the following behavior with
split-detection enabled:
In case of a complete split:
If the Master-RE sees MORE THAN HALF of the devices it survives otherwise it
disables that part of the cluster
If the Backup-RE sees HALF of the devices the backup Re will survive and
play the master

--> so then in a 2node VC one node is Master one node is backup
If they split the master will go down but the backup should survive as it is
still half of the original cluster

So this means you should make the part you want to survive to be the
backup-RE and not the master-RE

--- or did I miss something ?!

Regards

Alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Tobias Heister
Gesendet: Donnerstag, 26. Juli 2018 09:26
An: Victor Sudakov; Pavel Lunin
Cc: juniper-nsp
Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into
linecard mode

Hi,

On 26.07.2018 09:06, Victor Sudakov wrote:
>>> I don't like to explain what others say but I think yes. It's been known
>>> behavior since always: in a two-member VC always disable
split-detection.
>>> You can google for other threads on this in this list.
>>>
>>> It's always been kind of poorly documented. Last time I checked the
docs,
>>> instead of just writing clearly that it must be disabled in two-members
>>> mode, they "don't recommend" it with some kind of hand-waving
explanation
>>> that if you estimate that the backup RE failure probability is higher
that
>>> a split-brain condition blah-blah-blah... Just disable split-detection,
>>> that's it :)
>>
>> Tomorrow we are planning a lab with and without split-detection. I
>> hope this solves the issue for us, and if it does, I'm sure to make a
>> note in my engineering journal.
> 
> Yes, no-split-detection did help.

I would like to add to that. My point of view is that you do not always
disable split-detection in a two member VC.
You can do so if you know what that implies.

The reasoning for the remaining node going into LC mode is that only the
portions of the VC having the majority of nodes stays up and operational. In
a two member VC if for whatever reason one of the nodes looses connection to
the other, we cannot have a majority so both sides go down. Even if it is
the only node remaining.

But imagine an error scenario where the second node does not crash, but for
whatever reason both sides stay up, but the connection between them gets
lost. With split-detection configured, both sides will go down and you have
a controlled service outage. When no split-detection is configured both
sides remain up and you might have interesting effects happening in your
network with two switches with the same configuration and same "identity"
being up and forwarding. I have seen that happening in DC scenarios doing
stp to other devices and it is not pretty!

So always check the implications of what the command are doing. If in your
case an active/active split scenario (for worst case) works out better than
a completely offline VC, that is perfectly fine. I have seen lots of
scenarios where it would not be the expected or wanted behavior. But in my
world a VC is no real redundancy method it is just stacking-NG for
additional ports under one MGMT so i would have two VCs if i relay need
redundancy in most setups. But that is just me ;)

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

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

Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode

[Alexander Marhold]

Hi 

According to the documentation there should be the following behavior with
split-detection enabled:
In case of a complete split:
If the Master-RE sees MORE THAN HALF of the devices it survives otherwise it
disables that part of the cluster
If the Backup-RE sees HALF of the devices the backup Re will survive and
play the master

--> so then in a 2node VC one node is Master one node is backup
If they split the master will go down but the backup should survive as it is
still half of the original cluster

So this means you should make the part you want to survive to be the
backup-RE and not the master-RE

--- or did I miss something ?!

Regards

Alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Tobias Heister
Gesendet: Donnerstag, 26. Juli 2018 09:26
An: Victor Sudakov; Pavel Lunin
Cc: juniper-nsp
Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into
linecard mode

Hi,

On 26.07.2018 09:06, Victor Sudakov wrote:
>>> I don't like to explain what others say but I think yes. It's been known
>>> behavior since always: in a two-member VC always disable
split-detection.
>>> You can google for other threads on this in this list.
>>>
>>> It's always been kind of poorly documented. Last time I checked the
docs,
>>> instead of just writing clearly that it must be disabled in two-members
>>> mode, they "don't recommend" it with some kind of hand-waving
explanation
>>> that if you estimate that the backup RE failure probability is higher
that
>>> a split-brain condition blah-blah-blah... Just disable split-detection,
>>> that's it :)
>>
>> Tomorrow we are planning a lab with and without split-detection. I
>> hope this solves the issue for us, and if it does, I'm sure to make a
>> note in my engineering journal.
> 
> Yes, no-split-detection did help.

I would like to add to that. My point of view is that you do not always
disable split-detection in a two member VC.
You can do so if you know what that implies.

The reasoning for the remaining node going into LC mode is that only the
portions of the VC having the majority of nodes stays up and operational. In
a two member VC if for whatever reason one of the nodes looses connection to
the other, we cannot have a majority so both sides go down. Even if it is
the only node remaining.

But imagine an error scenario where the second node does not crash, but for
whatever reason both sides stay up, but the connection between them gets
lost. With split-detection configured, both sides will go down and you have
a controlled service outage. When no split-detection is configured both
sides remain up and you might have interesting effects happening in your
network with two switches with the same configuration and same "identity"
being up and forwarding. I have seen that happening in DC scenarios doing
stp to other devices and it is not pretty!

So always check the implications of what the command are doing. If in your
case an active/active split scenario (for worst case) works out better than
a completely offline VC, that is perfectly fine. I have seen lots of
scenarios where it would not be the expected or wanted behavior. But in my
world a VC is no real redundancy method it is just stacking-NG for
additional ports under one MGMT so i would have two VCs if i relay need
redundancy in most setups. But that is just me ;)

-- 
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] router reflector clients and non-clients

[Alexander Marhold]

>Instead you should not even connect RR1 and RR2 together 
>And treat RR infrastructure built from RR1s I their respective clusters as
a
>separate infrastructure to RR2s.
>This is the proper way

NO,NO,NO
This was the proper way in 1995, but not actual as...
(Unfortunately most BGP books have been written at that time and are still
sold...)

Never do this as it can lead to missing routing updates if a client A is
connected to RR-1 only and Client B connected to RR-2 only ( because of link
outages) then A does not get the routes from B and vice versa

Therefore make each RR with a unique cluster-id ( recommended identical
to router-id ) and then you can either make a normal ibgp connection between
both RRs or each one is the client of the other one

There are nice explanations on the Internet backing me up ( Ivan Peplnjak,
 http://packetpushers.net/bgp-rr-design-part-1/ 
http://orhanergun.net/2015/02/bgp-route-reflector-clusters/
)

Regards
alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
adamv0...@netconsultings.com
Gesendet: Mittwoch, 30. Mai 2018 09:31
An: 'Victor Sudakov'; 'Alan Gravett'; juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] router reflector clients and non-clients

> Of Victor Sudakov
> Sent: Wednesday, May 30, 2018 8:07 AM
> 
> Alan Gravett wrote:
> > A RR can also be a client with hierarchical RR's...
> 
> A hierarchy is irrelevant for this discussion. We are talking about how a
RR
> should differentiate between
> 
> 1. Its clients
> 
> 2. Non-clients
> 
> 3. Non-clients which are also RRs in the same cluster (from which you
should
> reject updates based on the cluster-id attribute).
> 
I know what you're talking about,
Even if you configure the other RR as a non-client in its dedicated
peer-group router will know what to do and will drop updates based on common
cluster-ID -eve cluster-ID is configured under peer-group it's a global BGP
attribute, but let me ask you this instead.
Why would you even connect RR1 and RR2 if they are in the same cluster 
-why to bother exchanging routes between the RRs just to be dropped by the
receiving party.

Instead you should not even connect RR1 and RR2 together 
And treat RR infrastructure built from RR1s I their respective clusters as a
separate infrastructure to RR2s.
This is the proper way

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
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] router reflector clients and non-clients

[Alexander Marhold]

>3. Non-clients which are also RRs in the same cluster (from which you
should reject updates based on the cluster-id attribute).

NO, NO, NO this is the old way of doing redundant RRs
Never do this as it can lead to missing routing updates if a client A is
connected to RR-1 only and Client B connected to RR-2 only ( because of link
outages)
Therefore make each RR with a unique cluster-id ( recommended identical
to router-id ) and then you can either make a normal ibgp connection between
both RRs or each one is the client of the other one

Regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Victor Sudakov
Gesendet: Mittwoch, 30. Mai 2018 09:07
An: Alan Gravett; juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] router reflector clients and non-clients

Alan Gravett wrote:
> A RR can also be a client with hierarchical RR's... 

A hierarchy is irrelevant for this discussion. We are talking about
how a RR should differentiate between 

1. Its clients

2. Non-clients

3. Non-clients which are also RRs in the same cluster (from which you
should reject updates based on the cluster-id attribute).


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
AS43859
___
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] router reflector clients and non-clients

[Alexander Marhold]

To further evaluate on that topic:

The rule for a IBGP community is:
IBGP learned routes are not allowed to forward to other IBGP neighbors

The IBGP rules for an RR are:
IBGP learned routes from a nonclient are allowed to be forwarded to all
clients only
IBGP learned routes from a client are allowed to be forwarded to all IBGP
neighbors ( clients and nonclients)

--- so in most case it does not really matter if C or D is client or not
 if you assume a nonclient then for those you need full IBGP-mesh to
other nonclients and all RRs
if in reality it is a client then you simply forward routes to some
neighbors twice ( one direct one via RR)

Regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Alexander Marhold
Gesendet: Mittwoch, 30. Mai 2018 08:17
An: 'Victor Sudakov'; juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] router reflector clients and non-clients

If you set the cluster-id for a group all configured neighbors are
RR-clients
So in your example all 4 neighbors including D and E are clients.

However the RR concept is quite flexible, a RR itself can be a client of
another RR ( hierarchically or at peer level)
Which means  A can be the RR of D and the same time D can be the RR of A

Regards
Alexander Marhold

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Victor Sudakov
Gesendet: Mittwoch, 30. Mai 2018 07:59
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] router reflector clients and non-clients

Dear Colleagues,

I'm reading
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route
-reflectors.html
and it is completely mind-boggling. 

The example configuration of the Router Reflector (RR) places all neighbors
(both clients and non-clients) into one group "internal-peers." How is this
supposed to work? How do I tell the RR that routers B and C are clients, and
routers E and D are non-clients?

In Cisco, you set the "router-reflector-client" statement for each
peer (or peer-group) who is a RR-client, explicitly. I don't see
anything of the kind in the example from the Juniper site.

Please help?

Quoting from the document:

user@A# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4; # client, router B
neighbor 192.168.40.4; # client, router C
neighbor 192.168.0.1; # non-client, router D
neighbor 192.168.5.5; # non-client, router E
}
}

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
AS43859
___
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] router reflector clients and non-clients

[Alexander Marhold]

If you set the cluster-id for a group all configured neighbors are
RR-clients
So in your example all 4 neighbors including D and E are clients.

However the RR concept is quite flexible, a RR itself can be a client of
another RR ( hierarchically or at peer level)
Which means  A can be the RR of D and the same time D can be the RR of A

Regards
Alexander Marhold

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Victor Sudakov
Gesendet: Mittwoch, 30. Mai 2018 07:59
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] router reflector clients and non-clients

Dear Colleagues,

I'm reading
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route
-reflectors.html
and it is completely mind-boggling. 

The example configuration of the Router Reflector (RR) places all neighbors
(both clients and non-clients) into one group "internal-peers." How is this
supposed to work? How do I tell the RR that routers B and C are clients, and
routers E and D are non-clients?

In Cisco, you set the "router-reflector-client" statement for each
peer (or peer-group) who is a RR-client, explicitly. I don't see
anything of the kind in the example from the Juniper site.

Please help?

Quoting from the document:

user@A# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4; # client, router B
neighbor 192.168.40.4; # client, router C
neighbor 192.168.0.1; # non-client, router D
neighbor 192.168.5.5; # non-client, router E
}
}

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
AS43859
___
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] Experience with MX10003

[Alexander Marhold]

Hi 
Regarding same chipset as mx960:

RE yes x86
PFE a clear no NO  it uses a "BRAND NEW" 3rd generation TRIO chipset with 400G 
throughput  also built into the MX204

Grabbed info from a BDM document in PPT describing both new platforms
Regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von 
Alain Hebert
Gesendet: Donnerstag, 25. Januar 2018 17:47
An: Juniper List
Betreff: [j-nsp] Experience with MX10003

 Hi,

 After the bad experience with the QFX5100, now our rep is pushing for 
MX10003 instead of MX960.

 While its half the routing (10T versus 4T), at 1/2 the price, and a barely 
3U in space, for the same chipset (coming from the sales guy).

 Anything ring thru?  Or we're going to be just another bunch of crash test 
dummies for Juniper to test this new platform?

 Thanks for your time.

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

___
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] Multicast through a switch

[Alexander Marhold]

Turning off IGMP-snooping means that every MC will be sent out on all
interfaces within the same vlan. ( like broadcast)

Turning OFF is needed when you have a pure Layer2 Multicast environment und
you cannot turn on any multicast Querier. or irb-interface with PIM enabled,
or ( every vendor has different solutions for pure L2-multicast to
overcome that problem)

The reason for that is that IGMP is a softstate protocol and the
IGMP-querier will check via asking if there  are still interested listeners
on that LAN, if no answer the multicast stream will be turned off, by the
Querier, or if there is no querier it will be turned off by the switch doing
IGMP-snooping after timeout ( typically 180 sec)

And the behavior is the same for all enterprise switches when they support
IGMP-snooping ( not only EX3300)

With best regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Gert Doering
Gesendet: Dienstag, 9. Januar 2018 09:19
An: juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] Multicast through a switch

Hi

On Mon, Jan 08, 2018 at 03:51:22PM -0600, Chris Adams wrote:
> Now we're trying to pass the feed through a VLAN to a new connection 
> through a switch (a VLAN on a trunk from our router to a VLAN on 
> another trunk to the transport carrier), but we're not sure how to get 
> the switch to pass the traffic.  I guess there's something we need to 
> configure static on the switch, but I don't know what.

"just passing through multicast" (as in "same VLAN") should not need any
special configuration.

OTOH, at least EX3300 like to eat multicast unless you turn off IGMP
snooping ("delete protocols igmp-snooping") - which, annoyingly, is
on-by-default.

Without any "smarts" in the switch, multicast is just like broadcast.

gert

--
now what should I write here...

Gert Doering - Munich, Germany
g...@greenie.muc.de

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

Re: [j-nsp] Understanding limitations of various MX104 bundles

[Alexander Marhold]

Hi ! 
IMHO Edward is right with his assumption:

Those are the available licenses for the MX104

Upgrade license to activate 2x10GE P2&3
MX104
S-MX104-ADD-2X10GE

Upgrade license to activate 2X10GE P0&1
MX104
S-MX104-UPG-2X10GE

Upgrade license to activate 4X10GE fixed ports on MX104
MX104
S-MX104-UPG-4X10GE

License to support per VLAN queuing on MX104
MX104
S-MX104-Q

Chassis-based software license for inline J-Flow monitoring on MX5, MX10, M40, 
MX80, and MX104 Series routers
MX5, MX10, M40, MX80, and MX104
S-JFLOW-CH-MX5-104

With best regards
alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von 
Edward Dore
Gesendet: Freitag, 5. Januar 2018 10:21
An: Josh Baird; Juniper List
Betreff: Re: [j-nsp] Understanding limitations of various MX104 bundles

I believe that the MX104-MX5 bundle is supposed to be locked to only allowing 
you to make use of a single MIC slot, like the MX5 version of the MX80. As to 
whether or not that is actually enforced…

Edward Dore
Freethought Internet

On 04/01/2018, 18:34, "juniper-nsp on behalf of Josh Baird" 
 wrote:

Hi all,

Given the MX104-MX5-AC bundle which comes with 1 20x 1GE MIC pre-installed
(and none of the onboard 10Gbps interfaces enabled), is this box actually
limited to 20Gbps overall throughput?

Can I install another MIC (say the MIC-3D-2XGE-XFP) in an additional slot
to gain 2 10Gbps interfaces without purchasing any additional licensing?
If I do this, is overall throughput of the chassis still locked to 20Gbps
(due to the original bundle)?

I can't find anything (ie "show system license") that states there is an
overall capacity restriction, but I'm hearing mixed things from various
sources.

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] LDP VPLS - Multi-homing

[Alexander Marhold]

Regarding EVPN testing
Why not taking some vMXes in an VMware or KVM environment, or even vQFX10k
All those are able to do EVPN L2 and L3 and with active/active multihoming

I do it since more than a year using different vMX versions

Regards

Alexander Marhold


-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
James Bensley
Gesendet: Dienstag, 10. Oktober 2017 09:20
An: juniper-nsp
Betreff: Re: [j-nsp] LDP VPLS - Multi-homing

On 10 October 2017 at 01:45, Aaron Gould <aar...@gvtc.com> wrote:
> Ah, I see what you are asking.  I don't know, perhaps someone on list 
> knows the particulars.
>
> About the multiple active fwd'ing paths for mhome'd pe-ce... I think 
> someone told me that is a benefit that evpn brings to the table... but 
> I heard it has something to do with per-vlan load sharing across those 
> active/active mhomed sites.
>
> Don't know yet, since I'm just diving into evpn, and am already 
> discouraged that I read that evpn isn't supported in lsys, ... lsys is 
> the basis for all my lab testing.  Oh well, perhaps I'll pull a 
> another acx5048 from the warehouse and give it a whirl

If you want to practice with EVPN in a non-Juniper environment I think it
works on the Cumulus Linux free/demo VM and probably some others like Cisco
xrv9k I believe, maybe the latest vMX supports it too?

Yeah EVPN has control-plane level MAC learning; from a high level imagine it
like a typical layer 3 VPN with IP prefixes being sent in BGP UPDATES just
that MACs are sent instead.

Cheers,
James.
___
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] Many contributing routes

[Alexander Marhold]

Yes, you are right  the primary contributing route is the mathematically
lowest 32-bit number of routes in that case
"Show route x.x.x.x extensive" shows the primary contributing route at the
end of the displayed output.

Regards

alexander

-Ursprüngliche Nachricht-
Von: Aaron Gould [mailto:aar...@gvtc.com] 
Gesendet: Samstag, 12. August 2017 02:03
An: alexander.marh...@gmx.at; 'Vincent Bernat'; juniper-nsp@puck.nether.net
Betreff: RE: [j-nsp] Many contributing routes

I have a note during a jncis-sp study I did...

"generated routes receive the next hop of the primary contributing route.
primary contributing route is the route with lowest preference of all the
contributing routes falling within the aggregate range of prefixes.  if
there are multiple contributing routes with same preference, tie breaker is
LOWEST prefix number... NOT lowest prefix length."

Forgive me as I don't have much real-world experience with this topic, but
is this note above accurate ?

I'm wondering if he is getting lots of what appear to be ebgp learned
prefixes I'm thinking they would all be Preference 170, with all that being
tied at 170, would the tiebreaker go to the lowest prefix number ?  like
1.0.0.0 or 3.0.0.0 or something low like that ?

- Aaron Gould





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

Re: [j-nsp] Many contributing routes

[Alexander Marhold]

Hi !

No problem as the generated route gets its info and next-hop address from
exactly one contributing route, that is okay

If you would use an aggregated route with 100k of routes instead then you
would have the problem of aggregation of all AS numbers which lead to an
overflow
Regards

Alexander Marhold
Consultant and Trainer

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Vincent Bernat
Gesendet: Mittwoch, 9. August 2017 09:06
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] Many contributing routes

Hey!

I am generating a default route to distribute with a policy statement like
that:

#v+
policy-statement v4-DEFAULT-ROUTE-GENERATE {
term v4-TRANSIT-ASX {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
term v4-TRANSIT-ASY {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
then reject;
}
#v-

This works just fine but there are a lot of contributing routes (about
400k) to the generated route. Is it harmless or will I run into trouble for
that?

Thanks!
--
A classic is something that everyone wants to have read and nobody wants to
read.
-- Mark Twain, "The Disappearance of Literature"
___
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] layer 2 sp services

[Alexander Marhold]

>Can't ECMP L2 ?

> I thought I read otherwise... ?

O yes you are right,
 EVPN can do L2 ECMP , the method is called "Aliasing" and by adding the ESI
to the mac type 2 announcement, other nodes can send also to second PE on an
all-active multihomed segment using same BGP-EVPN label but other next hop.

Only layer 3 all active loadbalancing does not work now, it was implemented
but silently removed by Juniper due to problem

All above  is regarding EVPN over MPLS, EVPN over VXLAN is a little bit
different, VP-LAG ( L3-all active) was mentioned in a slide by d.hanks but I
do not know if already implemented, L2 all-active should work ( have not
tested it on QFX now)

Regards

Alexander Marhold


-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Aaron Gould
Gesendet: Donnerstag, 3. August 2017 20:36
An: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] layer 2 sp services

Thanks Adam

Can't ECMP L2 ?

I thought I read otherwise... ?

https://www.nanog.org/sites/default/files/monday_general_hankins_vpn_2.pdf
slide 8 of 34 ...last bullet "Enables traffic load balancing for multihomed
CEs with ECMP MAC routes"

-Aaron

-Original Message-
From: adamv0...@netconsultings.com [mailto:adamv0...@netconsultings.com]
Sent: Sunday, July 30, 2017 4:07 AM
To: 'Aaron Gould' <aar...@gvtc.com>; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] layer 2 sp services

> Of Aaron Gould
> Sent: Friday, July 28, 2017 1:09 PM
> 
> 
> 
> My gosh, the layer 2 service provider topic is pretty extensive.  I'm
trying to
> learn about all of these.
> 
Yeah there was a 2nd renaissance of L2 services demand around 5 years ago
due to all the cloud and DCI hype which resulted in a lot of new standards
especially around EVPN, all the rest are now considered legacy. 

Oh, btw the VXLAN doesn't belong with the bunch, That one belongs to the
Ethernet in Ethernet/IP overlay for DC fabric together with TRILL,
Fabric-Path and PBB, happy reading :)

And after all these studies comparing various redundancy options of BGP CP
for EVPN and PBB-EVPN and VXLAN GW, etc..., you'll find out that you simply
can't ECMP L2 as you would a L3 traffic, cause you simply can't associate
single MAC address with two ports, how stupid is that right?
But definitely worth the adventure. 

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


> 
> 
> I think I have rfc's and terminology correct. but maybe not. correct 
> me
where
> needed.
> 
> 
> 
> - BGP L2VPN VPWS RFC 6624 BGP AD BGP SIG PP draft-kompella
> 
> - BGP L2VPN VPWS RFC 6074 BGP AD LDP SIG PP FEC 129
> 
> - BGP L2VPN VPLS RFC 4761 BGP AD BGP SIG MP
> 
> - BGP L2VPN VPLS RFC 4762 BGP AD LDP SIG MP
> 
> - MartiniRFC 4447  no AD LDP SIG PP
> 
> - EVPN  - don't know much here yet
> 
> - VXLAN - don't know much here yet
> 
> 
> 
> I'm pretty sure I use Martini/rfc4447 (l2circuits) and BGP/LDP vpls 
> rfc
4762
> extensively in my network (routing-instance . instance-type vpls 
> rd/rt, etc).but some of these other ones I don't think I'd ever really 
> use. like
this
> one that I'm currently learning about. rfc6624/kompella. nope, I don't
think I
> would use this one.  Do y'all use kompella ?
> 
> 
> 
> About kompella/rfc6624, I want to make sure I understand the NLRI 
> thing as far as knowing how to compute the incoming label and outgoing 
> label for a certain p-to-p pw to a remote site.
> 
> 
> 
> I this correct ? >   label base local + remote-site-id -
> label-offset-local = label value
> 
> 
> 
> Maybe it's like this.
> 
> 86+15-15=86 (in label)
> 
> 82+23-23=82 (out label)
> 
> 
> 
> I need to know how did the Local Label Base get calculated ?  where 
> did
> 82 and 86 come from ?
> 
> 
> 
> Also, does the Offset always equal the remote site id ?
> 
> 
> 
> .lab output.
> 
>

> 
> 
> Instance: vpn-a
> 
> Edge protection: Not-Primary
> 
>   Local site: CE-A (23)
> 
> Number of local interfaces: 1
> 
> Number of local interfaces up: 1
> 
> lt-0/1/0.11 15
> 
> Label-baseOffset Size  Range Preference
> 
> 8615 2  1 100
> 
>   status-vector:  0
> 
> connection-site   Type  St Time last up  # Up
trans
> 
> 15rmt   Up Jul 27 23:53:36 2017
1
> 
>   Remote PE: 1.1.255.1, Negotiated control-word: Yes (Null)
> 
>   Incoming label: 86, Outgoing label: 82
> 
>   Local

Re: [j-nsp] vMX

[Alexander Marhold]

Hi Yes !

By changing parameters in the boot/loader.conf you can change certain
behavior

vm_chassis_i2cid="21" for MX960, "33" for MX480, and "48" for MX240
 vm_ore_present=“0” for a single RE; vm_ore_present=“1” for dual REs
vm_instance=“0” for the the RE, the first FPC slot; vm_instance=“1” for
second FPC
slot, and so on (not applicable to RE)
Let’s say, you want to run 1 RE and 1 FPC on slot 0 (you can run 2 REs and
up to 12 FPCs if
you emulate an MX960)

However the real imitation is somewhere else  namely that VMware only allow
up to 10 interfaces on one VM

I think that currently this is not officially supported but as far as I know
Juniper plans to allow up to 2 REs and up to ?(3 and more) separate PFE
instances

With best regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Stefan Stoyanov
Gesendet: Donnerstag, 17. November 2016 15:12
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] vMX

Hello everyone,

Is there someone who is familiar with vMX?
I have installed vMX under VMWARE and I wanted to know if it's possible to
add more than one FPC.
I could find any documentation about that.

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] Very basic question about MPLS and RSVP's place in the design

[Alexander Marhold]

Hi
There is also some good Juniper information available on the Juniper site

This Week: deploying MPLS
DAY ONE: MPLS FOR ENTERPRISE ENGINEERS

Or as book

MPLS in the SDN era

The first 2 are quite good for starters learning the mechanisms

With best regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von 
Scott Granados
Gesendet: Donnerstag, 27. Oktober 2016 00:43
An: sth...@nethelp.no
Cc: juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] Very basic question about MPLS and RSVP's place in the 
design

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

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

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

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

[j-nsp] Next-Hop Verification for static route WITHOUT BFD

[Alexander Marhold]

Hi !

 

In the old Junoe E router we could use RTR to verify a next-hop for a static
route when the neighbor is not able or willing to do BFD

 

host1(config)#ip route 10.1.1.5 255.255.255.0 10.1.1.5 fastEthernet 1/0
verify rtr 5 last-resort

 

I do not find any good example of doing this on a MX.

 

I need such a solution to change the BGP next-hop on an interface when the
interface is always up, but the necessary next-hop on this multipoint
interface is not reachable

 

The successor of RTR namely ip-monitoring is not able to this in a simple
way.

Maybe any special policy or event-policy or an event-script can help here?

Or a unknown way to redistribute the static route to OSPF only when the
next-hop is reachable vis ip monitoring ?

 

So if you have a practical way to do this please tell.

To clarify it is not a matter of milliseconds, it is a matter of seconds 

 

What I want to achieve is that when the next-hop of this static route is not
reachable, the static route is not readvertised into OSPF anymore and a
second MX then looses the primary BGP next-hop and can then divert the BGP
traffic to secondary Peer and next-hop.

 

Many thanks in advance for your ideas and solutions

 

Alexander Marhold

___
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

[Alexander Marhold]

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 time.

--

PS: I wish Juniper would adopt the standard to list the devices and
their firmware to those whitepapers.  Took 1/2 a day to figure out we needed
16.x for the vMX part of the equation. Oh and some peer review =D

White paper in question:

   
https://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000606-en.pdf

-
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

___
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 vmx not able to find op and event script files

[Alexander Marhold]

Post it in the vMX forum, http://forums.juniper.net/t5/vMX/bd-p/vMX

This forum is monitored by some juniper-engineers ( e.g szhong) and they can 
look into such things to see if it is a bug or not.
They are quite responsive and try to help :)


Regards

alexander

-Ursprüngliche Nachricht-
Von: Martin T [mailto:m4rtn...@gmail.com] 
Gesendet: Freitag, 20. Mai 2016 08:20
An: alexander.marh...@gmx.at
Cc: serge vautour; juniper-nsp
Betreff: Re: [j-nsp] Juniper vmx not able to find op and event script files

Hi,

unfortunately this doesn't work either:

root@vMX-A> file list detail /var/db/scripts/op/abc.slax
-rw-r--r--  1 root  wheel286 May 20 06:08 /var/db/scripts/op/abc.slax
total files: 1

root@vMX-A> show configuration system scripts op file abc.slax {
command cba;
}

root@vMX-A> op cba
error: invalid filename: /var/db/scripts/op/abc.slax

root@vMX-A>


Any other ideas?


thanks,
Martin

On Fri, May 20, 2016 at 9:06 AM, Alexander Marhold <alexander.marh...@gmx.at> 
wrote:
> Hi !
>
> Maybe it is not a good idea to name a file equal to a possible command.
>
> Ever tried renaming the file to abc ?
> Second possibility is that in the config you define something like:
>
>  set system scripts op file policy-test.slax command tpol
>
> and then call it with op tpol ...
>
>
> regards
>
> alexander
>
> -Ursprüngliche Nachricht-
> Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im 
> Auftrag von Martin T
> Gesendet: Donnerstag, 19. Mai 2016 23:38
> An: serge vautour
> Cc: juniper-nsp
> Betreff: Re: [j-nsp] Juniper vmx not able to find op and event script 
> files
>
> Hi,
>
> thanks for reply! Actually I tried that already, but SLAX script file 
> was still not found:
>
> root@vMX-A> op ?
> Possible completions:
>   

Re: [j-nsp] Optimizing the FIB on MX

[Alexander Marhold]

Hi

 

You wrote:

>One thing I haven't seen mentioned is that routers need indirect-nexthop 
>feature enabled

 

IMHO exactly this is also called PIC   (prefix independent convergence) so to 
be exact to get a prefix amount independent convergence you need a pointer to a 
nexthop-pointer-structure which then points to the next-hop.

In case of a change of the nexthop you only need to change the pointer in the 
next-hop-pointer-structure independent how many prefixes are using that 
next-hop.

 

Regards

 

alexander

 

 

Von: Dragan Jovicic [mailto:dragan...@gmail.com] 
Gesendet: Freitag, 19. Februar 2016 11:45
An: Adam Vitkovsky
Cc: alexander.marh...@gmx.at; sth...@nethelp.no; Chuck Anderson; Vincent 
Bernat; juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] Optimizing the FIB on MX

 

Advertise-external or more general Additional Path capability (would prefer 
this if new install) could be used to distribute selected few routes if FIB 
space is of concern.

One thing I haven't seen mentioned is that routers need indirect-nexthop 
feature enabled, which should be by default enabled on recent Junos versions on 
all-MPC chassis. Otherwise, change of core interface will take at least a 
couple of dozen seconds to update FIB. DPC cards do not support this, and on 
older version you'd need to enable this feature by hand, if i remember 
correctly.

Also, if this protection is used in l3vpn, you would optimally need 
composite-nexthop feature which decouples link between indirect-nexhop and 
outer label (which is changed once core link fails).

 

Regards

 

On Fri, Feb 19, 2016 at 11:02 AM, Adam Vitkovsky <adam.vitkov...@gamma.co.uk> 
wrote:

> Alexander Marhold [mailto:alexander.marh...@gmx.at]
> Sent: Thursday, February 18, 2016 6:50 PM
>
> Hi folks
>
> To make the discussion clearer and comming back to the Juniper MX 104
> implementation
>
> Here is a picture of 2 PEs on P  and 2 peers (ISP1 and IX1) let´s assume we
> want to prefer routes from IX1 over ISP1
> MX1 is EBGP (lpref 100) to  ISP1 and IBGP to MX2 and MX3
> MX2 is EBGP (lpref 110) to IX1 and IBGP to MX1 and MX3
>
>   ISP1   IX1
> | locpref ^ locpref
> |   100  |   110
>MX1->-MX2
> |   |
> |   |
> +--MX3--->--+
>
>
> In my opinion if you need also  the MX3 then  for this MX3 you need "PIC-
> CORE" to quickly switch between both paths
>
Yes that's right, "protect core" under routing-options of the Internet VRF.

However then I can ask what if MX2 fails or is severed from the core completely,
though with that I'd be opening a whole different and very interesting realm of 
convergence options.
First you'd need to tune your IGP so it propagates the unreachability of MX2's 
loopback towards MX3 as fast as possible.
Then I could argue that MX3 is in a different AS and it knows about MX2's 
loopback via BGP-LU -so you'd need to tune BGP-LU infrastructure(can't shave of 
much delay).
Then I could argue I want sub 50ms convergence in the above case and well then, 
then you'd have to rely on P routers to perform the local repair and swing from 
MX2 to MX1 If MX2 goes down.
And that brings me to Segment Routing and protecting a node segment upon the 
failure of its advertising node


> On MX1 you need "best-external" to advertise the external routes whereas
> the best is the internal route pointing to MX2
>
> On MX1 and MX2 you need "PIC-EDGE" to quickly switch when IX1 goes
> down
>
Well technically you need PIC-EDGE only on MX2 so it can do the local repair 
for traffic destined to IX1 and re-label it so that it gets to MX1.

> Do we all agree on that picture and the named mechanisms ( put in "") ?
>
>
> So now what versions of Junos is needed and what additional "unnecessary"
> methods like MPLS or LDP is now needed ?
>
Well I'm afraid you'd need to run MPLS L3VPNs for all this.


adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 <tel:%2B44%20%280%29%20808%20178%209652>  or 
email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with r

Re: [j-nsp] Optimizing the FIB on MX

[Alexander Marhold]

Hi folks

To make the discussion clearer and comming back to the Juniper MX 104 
implementation

Here is a picture of 2 PEs on P  and 2 peers (ISP1 and IX1)
let´s assume we want to prefer routes from IX1 over ISP1
MX1 is EBGP (lpref 100) to  ISP1 and IBGP to MX2 and MX3
MX2 is EBGP (lpref 110) to IX1 and IBGP to MX1 and MX3

  ISP1   IX1
| locpref ^ locpref 
|   100  |   110
   MX1->-MX2
|   |
|   |
+--MX3--->--+


In my opinion if you need also  the MX3 then  for this MX3 you need "PIC-CORE" 
to quickly switch between both paths

On MX1 you need "best-external" to advertise the external routes whereas the 
best is the internal route pointing to MX2

On MX1 and MX2 you need "PIC-EDGE" to quickly switch when IX1 goes down

Do we all agree on that picture and the named mechanisms ( put in "") ?


So now what versions of Junos is needed and what additional "unnecessary" 
methods like MPLS or LDP is now needed ?

regards

alexander

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

Re: [j-nsp] Optimizing the FIB on MX

[Alexander Marhold]

Hi Chuck !

Followed with interest the problem and especially your solution and I have
looked into the docu BUT:

DOCU says:
" Before you begin:

Configure the device interfaces.
Configure OSPF or any other IGP protocol.
Configure MPLS and LDP. <-- REALLY

Configure BGP.
"

Why do you need to enable MPLS and LDP for PIC ?

IMHO this is a documentation error , or do I miss something ?

Regarding you suggestion of using it in a routing instance with version
<15.1 I am not sure if that works as documentation says that it only works
for vpnv4-BGP routes

DOCU says
"Before you begin:

Configure LDP.
Configure an IGP, either OSPF or IS-IS.
Configure a Layer 3 VPN.
Configure multiprotocol BGP for either an IPv4 VPN or an IPv6 VPN.
< nthis seems to be a restriction regarding your proposed
solution
"

Any more info on that available ?

Regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Chuck Anderson
Gesendet: Mittwoch, 17. Februar 2016 21:19
An: juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] Optimizing the FIB on MX

On Wed, Feb 17, 2016 at 08:51:23PM +0100, Vincent Bernat wrote:
> Being a bit unsatisfied with a pair of MX104 turning themselves as a 
> blackhole during BGP convergence, I am trying to reduce the size of 
> the FIB.
> 
> I am in a simple situation: one upstream on each router, an iBGP 
> session between the two routers. I am also receiving a default route 
> along the full feed.

Can you use Junos 15.1?  Try this:

http://www.juniper.net/techpubs/en_US/junos15.1/topics/concept/use-case-for-
bgp-pic-for-inet-inet6-lu.html
___
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] Which BOGON filter strategy you would recommend IPv4 and IPv6

[Alexander Marhold]

Hi !

 

My customer is a bigger company with customers around the world, which
recently connected directly to 4 upstream providers and 1 IX via MX router
and BGP

 

Now by searching the internet and googling  I do not know which method to
use to have up-to date BOGON filtering for IPv4 AND IPV6  (yes IPv6 is
necessary)

 

I found things like spamhaus, team-cymru.org .

 

It seems that IPv6 is still less treated than IPv4

 

What do you recommend, and which way to get the lists and how often is an
update needed

Or is it better to try a dynamic solution via bgp-peering ?

 

With best regards

 

alexander

 

 

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

[j-nsp] VRRP VIP route not accepted as contributing route to AGGREGATE

[Alexander Marhold]

Hi Experts !

We want to have an aggregate only announced when the VRRP vip route is active 
on the local BGP speaker

Show route proto local shows the route

1##.123.456.100/32 *[Local/0] 02:15:41
  Local via ge-0/0/6.0

As the local router is the vrrp master

ge-0/0/6.0up 26   master   Active  A  0.677 lcl
1##.123.456.1
vip
1##.123.456.100

the aggregate config is:
route 1##.123.456.0/24 {
policy MATCH-VIP-vrrp-226;
tag 24;

the policy is 

policy-statement MATCH-VIP-vrrp-226 {
term 1 {
from {
protocol local;
route-filter 1##.123.456.100/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}

But the result is negative

lab@mx-2> show route protocol aggregate hidden

inet.0: 32 destinations, 43 routes (30 active, 0 holddown, 1 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

1##.123.456.0/24[Aggregate] 00:19:46, tag 24
  Reject


When removing the policy I do not see the VIP route as contributing route:

1##.123.456.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 1##.123.456.0/24 -> {}
Aggregated into 1##.123.456.0/22
Page 0 idx 1, (group TELIA type External) Type 1 val 0x9556434 (adv_entry)
   Advertised metrics:
 Nexthop: Self
 Communities:
Path 1##.123.226.0 Vector len 4.  Val: 1
*Aggregate Preference: 130
Next hop type: Reject
Address: 0x9292a44
Next-hop reference count: 14
State: 

Age: 22:49
Validation State: unverified
Tag: 24
Task: Aggregate
Announcement bits (4): 0-KRT 4-Aggregate 5-BGP_RT_Background 
6-Resolve tree 2
AS path: I (LocalAgg)
Flags:  Depth: 0Active
AS path list:
AS path: I Refcount: 1
Contributing Routes (1):
1##.123.456.0/25 proto Direct


So is this a bug ?
or why it is not possible to use a VRRP VIP route as contributing route when it 
is shown as protocol local  route in the routing table

Or are local  routes not contributing even though they are active? 

The local route state is : State: 


Or is there another way to do this ?

The HW is a MX SW is 13.3, but the test was done on a vMX with 14.1

Thanks for help 

Alexander

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

Re: [j-nsp] Mixed vcf question

[Alexander Marhold]

Hi James !

You wrote :
"For example for the layer3 (max routes supported, etc) why not the one of the 
QFX5100 acting as routing engine (and spine)?"

It would not help you at all if the routing engine can hold for example 300k 
routes and then only 100k can be downloaded to the forwarding engine.
Which one ? the first 100k ? so this obviously will not work, therefore the LCD 
( least common denominator ) 
It is the forwarding engine or PFE which is in a mixed VCF the limiting factor.

Regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von 
james list
Gesendet: Samstag, 23. Januar 2016 07:25
An: William Johansson
Cc: Juniper List
Betreff: Re: [j-nsp] Mixed vcf question

Hi William
For example for the layer3 (max routes supported, etc) why not the one of the 
QFX5100 acting as routing engine (and spine)?

Is there something stated on the juniper.net site?

Cheers
James
Il 23/Gen/2016 00:32, "William Johansson"  ha 
scritto:

> Hello
>
> The scalability levels and features in a mixed mode vcf (for all 
> switches that are part of the vcf) will be lowered to the levels of 
> the lowest switch model. This means that the numbers of ae's, mac 
> address table size, routing tables size, cos features etc for the 
> whole vcf will (in your case) be same as the ex4300.
>
> Br William
>
>
> Skickat från min iPad
> > 21 jan. 2016 kl. 16:22 skrev james list :
> >
> > Hello experts,
> >
> > a question regarding a mixed VCF environment with QFX5100 as spine 
> > and
> > QFX5100/EX4300 as leaf.
> >
> >
> >
> > My customer question is: what are the Layer2/Layer3 maximum 
> > performance expected to be reached in a mixed environment ?
> >
> >
> >
> > The one reached by QFX5100 or the one reached by EX4300 or something
> else ?
> >
> >
> >
> > I imagine that if traffic enter on QFX and exit on QFX the 
> > performance
> are
> > the one from QFX, if enter on QFX and exit on EX the performance are 
> > the one from EX.
> >
> >
> >
> > For performance I mean max throughput, max switching capacity, 
> > maximum supported routes, etc..
> >
> >
> >
> > Am I correct ?
> >
> > Any reference url or experience ?
> >
> >
> >
> > Thank you in advance
> >
> >
> >
> > Cheers
> >
> > James
> > ___
> > 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] vMX for ESXi

[Alexander Marhold]

Hi

There is a separate forum for vMX 

http://forums.juniper.net/t5/vMX/bd-p/vMX

so I would suggest to put questions and answers regarding the vMX product
here.

Regarding the mentioned problems on ESXi ( or VMware) there seems to be some
discrepancies and I brought the vMX to run on VMware WS only after some try
and error,  I will put info into the vMX forum today

The docu is more or less useless, e.g there is a vmdk named
metadata_usb.vmdk which is not mentioned in the setup procedure

With best regards

Alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Mark Tees
Gesendet: Mittwoch, 6. Januar 2016 02:34
An: Dale Shaw
Cc: juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] vMX for ESXi

Hi Dale/Robert,

One thing I noticed missing in the Vmware document/procedure appeared to be
the process for using SR-IOV with Vmware.

Do we just follow the Vmware docs on this and the vPFE will pickup the
virtual functions or is this not supported yet?

Cheers,

Mark



On 6 January 2016 at 12:09, Dale Shaw  wrote:
> Hi again,
>
> On Tuesday, 5 January 2016, Robert Hass  wrote:
>
> But still TGZ package doesn't have files which I'm looking and above 
> guide
>> referring them - *.vmdk files :(
>
>
> Please check again -- the ESXi packages have now been posted.
>
> Cheers,
> Dale
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp



--
Regards,

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

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

Re: [j-nsp] vMX for ESXi

[Alexander Marhold]

Hi !

Maybe you missed the VMX getting started guide

http://www.juniper.net/techpubs/en_US/vmx15.1f4/information-products/pathway
-pages/getting-started/vmx-gsg-vmware.html

he describes in detail how to setup vMX on ESXi

regards

alexander


-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Robert Hass
Gesendet: Dienstag, 5. Januar 2016 08:51
An: Dale Shaw
Cc: juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] vMX for ESXi

On Mon, Jan 4, 2016 at 11:29 PM, Dale Shaw 
wrote:

> ESXi support was introduced in vMX release 15.1F4.
>
>
> http://www.juniper.net/techpubs/en_US/vmx15.1f4/information-products/t
> opic-collections/release-notes/jd0e52.html#jd0e52
>
>
Hi
Thanks for update, great to hear that. But I downloaded 15.1F4 vMX from
juniper.net and very disappointed as:
1) There is no OVA images in .tgz. Just *.img, *.tgz which are useless for
VMware. I can convert them to VMDK but come on I want official OVA for
supported product, not dirty solutions
2) installation doc called 'VMX_Release_Notes_Installation_Guide_Beta.pdf'
(see keyword: Beta :) ) doesn't mentioned anything related to VMware ESXi
just KVM & Ubuntu shit.

Above is regarding vmx-15.1F4.15.tgz (size=1561459359)

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

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

Re: [j-nsp] NETCONF in Junos

[Alexander Marhold]

Hi !

Yes, if you want to see how the request command looks like
Then do a 
" show version brief | display xml rpc"

Using XSLT or SLAX the language create and uses exatly that XML information.

Regards

Alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Martin T
Gesendet: Montag, 21. Dezember 2015 02:26
An: juniper-nsp
Betreff: [j-nsp] NETCONF in Junos

Hi,

if I execute for example "show version brief | display xml" command, then
the router returns:

http://xml.juniper.net/junos/12.3R6/junos;>

r1
m10i
m10i

junos
JUNOS Base OS boot [12.3R6.6]


/* additional data removed for brevity  */



{master}



Is it a reply to NETCONF  operation? Does this mean that each for
example "show" command in Junos is a communication (over TCP/IP) between the
NETCONF manager(sends the ) and agent(sends the
) in the same router?


thanks,
Martin
___
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] Could JUNOS OP Script support generate firewall filter term and added before original one?

[Alexander Marhold]

Hi !

Here an example on doing such thing with BGP policies.
I know it is a little bit different but it shows a way to do such inserting
using slax 

https://www.juniper.net/documentation/en_US/junos12.3/topics/example/junos-s
cript-automation-commit-script-prepending-global-policy.html

regards

Alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Chen Jiang
Gesendet: Donnerstag, 17. Dezember 2015 08:36
An: Juniper List
Betreff: [j-nsp] Could JUNOS OP Script support generate firewall filter term
and added before original one?

Hi! Experts

I have a requirement from end user that want to automate firewall filter
configuration procedure, that means they want to use OP script to generate a
customized firewall filter term and added it before the last "deny all"
term.

I have searched official documents but couldn't find helpful information, it
seems there is no method could manage firewall filter term sequence in SLAX
language.

Could you pls shed some light on this if you have experience on this,
Thanks!

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