Discussion:
[j-nsp] LDP VPLS - Multi-homing
Aaron Gould
2017-10-02 12:52:35 UTC
Permalink
Please let me know where I'm not understand this correctly.



I have what I understand to be a LDP VPLS configured network, additionally
with a functional multi-homing configuration. It's all working. shutting
down the operational/designated forwarder pe-ce interface causes a good
failover to the other multi-homed pe-ce side.



The juniper.net link below seems to state that a PW will not be fired-off to
prevent looping. I don't see this to be true. I see a full mesh of active
(UP) pw's. The only thing that I observe as the loop preventing mechanism
is the non-designated-forwarding interface from PE-CE is brought down.



Also, in the link below it mentions the following. "For interoperation
scenarios in which a PE router must support both types of NLRI (FEC 128 and
FEC 129), this example also includes the signaling statement."



.I'm pretty sure it's speaking of the command "set logical-systems r2
protocols bgp group my-ibgp neighbor 1.1.255.4 family l2vpn signaling"



For what I'm seeing in my lab, I don't see this to be accurate either. I
see that I do not get multi-homing advertisements *received* if I don't have
that "signaling" command. I do see that the local site MH info is there
prior to the signaling command, in the (vpls name).l2vpn.0 (only one local
entry) but nothing rcv'd in the bgp.l2vpn.0 table.



I'll be glad to send any output/configs if you want to see them..this is all
done within several lsys's



https://www.juniper.net/documentation/en_US/junos/topics/topic-map/vpls-bgp-
multihoming.html



my verification commands.



run show route table vpls-4762.l2vpn.0 | grep MH

run show route table bgp.l2vpn.0 | grep MH

run show vpls connections extensive | find Multi-home

run show vpls connections br

run show interfaces terse lt-1/1/0.1104





***@lab-mx104:r2# deactivate protocols bgp group my-ibgp neighbor 1.1.255.4
family l2vpn signaling



***@lab-mx104:r2# commit



***@lab-mx104:r2# run show route table bgp.l2vpn.0 | grep MH



***@lab-mx104:r2# run show route table vpls-4762.l2vpn.0 | grep MH



1.1.255.2:1000:1:0/96 MH



***@lab-mx104:r2# activate protocols bgp group my-ibgp neighbor 1.1.255.4
family l2vpn signaling



***@lab-mx104:r2# commit



***@lab-mx104:r2# run show route table bgp.l2vpn.0 | grep MH



1.1.255.3:1000:1:0/96 MH

1.1.255.6:1000:2:0/96 MH

1.1.255.8:1000:2:0/96 MH



***@lab-mx104:r2# run show route table vpls-4762.l2vpn.0 | grep MH



1.1.255.2:1000:1:0/96 MH

1.1.255.3:1000:1:0/96 MH

1.1.255.6:1000:2:0/96 MH

1.1.255.8:1000:2:0/96 MH



[edit]

***@lab-mx104:r2# show protocols bgp | display set

set logical-systems r2 protocols bgp group my-ibgp type internal

set logical-systems r2 protocols bgp group my-ibgp local-address 1.1.255.2

set logical-systems r2 protocols bgp group my-ibgp neighbor 1.1.255.4 family
inet-vpn unicast

set logical-systems r2 protocols bgp group my-ibgp neighbor 1.1.255.4 family
l2vpn auto-discovery-only

set logical-systems r2 protocols bgp group my-ibgp neighbor 1.1.255.4 family
l2vpn signaling

set logical-systems r2 protocols bgp group my-ibgp neighbor 1.1.255.7 family
inet-vpn unicast

set logical-systems r2 protocols bgp group my-ibgp neighbor 1.1.255.7 family
l2vpn auto-discovery-only

set logical-systems r2 protocols bgp group my-ibgp neighbor 1.1.255.7 family
l2vpn signaling



[edit]

***@lab-mx104:r2# show routing-instances vpls-4762 |display set

set logical-systems r2 routing-instances vpls-4762 instance-type vpls

set logical-systems r2 routing-instances vpls-4762 interface lt-0/1/0.1002

set logical-systems r2 routing-instances vpls-4762 route-distinguisher
1.1.255.2:1000

set logical-systems r2 routing-instances vpls-4762 l2vpn-id
l2vpn-id:64512:1000

set logical-systems r2 routing-instances vpls-4762 vrf-target
target:64512:1000

set logical-systems r2 routing-instances vpls-4762 protocols vpls
no-tunnel-services

set logical-systems r2 routing-instances vpls-4762 protocols vpls
multi-homing site site1 identifier 1

set logical-systems r2 routing-instances vpls-4762 protocols vpls
multi-homing site site1 interface lt-0/1/0.1002





-Aaron Gould

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Aaron Gould
2017-10-09 11:49:59 UTC
Permalink
Ah. I think I might be on to something. I see that when I do a BGP VPLS
(fec 128, rfc 4761) style config, then I do NOT see the pw's active between
the non-designated-forwarding multi-homed pe's... and, this seems to be
automatic. (no mhoming config needed in my lab) It seems in that link there
is some typos with explaining BGP VPLS and LDP VPLS. Seems that it explains
on BGP Signals PW's under the section of the document pertaining to LDP
VPLS, so it confuses the reader. It seems that someone should correct that
document.

I did not have to configure any multihoming commands in order to cause this
to occur. In the link it mentions that there are some multi-homing commands
for fec 128 bgp vpls... but I didn't use that command and I still get loop
prevention behavior. ( I see pw's not up and also, the non-df pe-ce link is
brought down) ...with that in mind, any idea why would I need that command
for fec 128 bgp vpls ?

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/vpls-bgp-
multihoming.html
"For FEC 128-routing-instances instance-name protocols vpls site site-name
multi-homing"


[edit]
***@lab-mx104:r2# run show vpls connections instance vpls-4761 brief | find
Instance:

Instance: vpls-4761
Edge protection: Not-Primary
Local site: site10 (10)
connection-site Type St Time last up # Up trans
10 rmt RN
11 rmt Up Oct 9 11:12:41 2017 1

[edit]
***@lab-mx104:r2# show routing-instances vpls-4761 | display set
set logical-systems r2 routing-instances vpls-4761 instance-type vpls
set logical-systems r2 routing-instances vpls-4761 interface lt-0/1/0.1052
set logical-systems r2 routing-instances vpls-4761 route-distinguisher
1.1.255.2:1001
set logical-systems r2 routing-instances vpls-4761 vrf-target
target:64512:1001
set logical-systems r2 routing-instances vpls-4761 protocols vpls site-range
100
set logical-systems r2 routing-instances vpls-4761 protocols vpls site
site10 site-identifier 10



[edit]
***@lab-mx104:r2# run show interfaces terse lt-0/1/0.1052
Interface Admin Link Proto Local Remote
lt-0/1/0.1052 up up vpls



[edit]
***@lab-mx104:r3# run show interfaces terse lt-0/1/0.1054
Interface Admin Link Proto Local Remote
lt-0/1/0.1054 up down vpls

[edit]
***@lab-mx104:r3# show routing-instances vpls-4761 | display set
set logical-systems r3 routing-instances vpls-4761 instance-type vpls
set logical-systems r3 routing-instances vpls-4761 interface lt-0/1/0.1054
set logical-systems r3 routing-instances vpls-4761 route-distinguisher
1.1.255.3:1001
set logical-systems r3 routing-instances vpls-4761 vrf-target
target:64512:1001
set logical-systems r3 routing-instances vpls-4761 protocols vpls site-range
100
set logical-systems r3 routing-instances vpls-4761 protocols vpls site
site10 site-identifier 10

[edit]
***@lab-mx104:r3# run show vpls connections instance vpls-4761 brief | find
Instance:

Instance: vpls-4761
Edge protection: Not-Primary
Local site: site10 (10)
connection-site Type St Time last up # Up trans
10 rmt LN
11 rmt LN

- Aaron


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
James Bensley
2017-10-09 12:39:22 UTC
Permalink
Post by Aaron Gould
Ah. I think I might be on to something. I see that when I do a BGP VPLS
(fec 128, rfc 4761) style config, then I do NOT see the pw's active between
the non-designated-forwarding multi-homed pe's... and, this seems to be
automatic. (no mhoming config needed in my lab) It seems in that link there
is some typos with explaining BGP VPLS and LDP VPLS. Seems that it explains
on BGP Signals PW's under the section of the document pertaining to LDP
VPLS, so it confuses the reader. It seems that someone should correct that
document.
I tried reading through the links and it wasn't making sense to me,
now that you say that, it does make more sense. At first I thought you
were confusing LDP signalled VPLS with BGP signalled VPLS but yeah I
see now that the Juniper documentation is in fact incorrect :)

I was trying to work out the mechanism for signalling the
non-designated-forwarding PE-CE link to go operationally "down" (I'm
used to VPLS on Cisco kit). This isn’t in RFC4761 so is this a Juniper
custom extension?

Cheers,
James.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailma
Aaron Gould
2017-10-09 17:52:53 UTC
Permalink
Thanks James, What exactly are you trying to figure out ? you mentioned.... " I was trying to work out the mechanism for signalling the non-designated-forwarding PE-CE link to go operationally "down"...


-Aaron


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
James Bensley
2017-10-09 18:31:17 UTC
Permalink
On 9 Oct 2017 18:52, "Aaron Gould" <***@gvtc.com> wrote:

Thanks James, What exactly are you trying to figure out ? you
mentioned.... " I was trying to work out the mechanism for signalling the
non-designated-forwarding PE-CE link to go operationally "down"...


-Aaron


I was wondering how it works.

The RFC doesn't cater for multiple active forwarding paths to a CE/site,
some form of STP is recommended. I wonder how Juniper have implemented this
designated forwarding link signalling to remove the layer 2 loop; an
additional attribute in BGP?

Cheers,
James.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Aaron Gould
2017-10-10 00:45:50 UTC
Permalink
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

-Aaron


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Youssef Bengelloun-Zahr
2017-10-10 06:04:31 UTC
Permalink
Hello Aaron,

If I may, I would advice you to drop LSYS for two reasons :

1/ on a practical level, it's more constraints and limitations than it sounds on the paper. After 5 years of running it into production, we have phased it out two weeks ago.

2/ it is dying and replacement feature (logical DOM) is planned for 2018 according to my SE. So, no more developments planned.

My 2 cents.
Post by Aaron Gould
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
-Aaron
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puc
Aaron Gould
2017-10-10 12:13:26 UTC
Permalink
Thanks Youssef, yes sir, you may advise me anytime :)

I currently use lsys in lab for testing and is a nice way of having lots of separate routers in one MX104

We (my coworkers and I) have thought that when we rollout a new ring of MX960's, that maybe it would be good to try to put the PE functions of an MX960 into a lsys. What are the limitations with that?

What is logical DOM ? Is this another way of saying "Junos Node Slicing" or is logical DOM something altogether different than slicing ?

-Aaron


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Youssef Bengelloun-Zahr
2017-10-10 12:44:37 UTC
Permalink
This post might be inappropriate. Click to display it.
James Bensley
2017-10-10 07:19:39 UTC
Permalink
Post by Aaron Gould
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Alexander Marhold
2017-10-10 09:04:13 UTC
Permalink
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-***@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
Post by Aaron Gould
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Aaron Gould
2017-10-10 12:04:47 UTC
Permalink
Thanks Alexander. I was just now updating GNS3 for just that. I have used
GNS3 in the past for IOS, XRv, vMX, and olive. Do I need GNS3 or can I do
it only with VMware, etc as you've stated.

-Aaron



_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Aaron Gould
2017-10-10 12:02:33 UTC
Permalink
Thanks James.

As a side note, seems incredible that bgp is actually used for advertising
mac address for a bridging function. Who would have ever known 20 years ago
that we would be here.

- Aaron



_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Aaron Gould
2017-10-11 17:23:16 UTC
Permalink
(I really should change this subject heading to "BGP VPLS - Multi-homing"
since that's the more specific vpls version we are discussing at this
point... FEC 128 / RFC 4761)

hey look what I just found ..
https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/vp
ns-configuring-vpls-multihoming.html
"When two PE routers use the same site ID, VPLS assumes multihoming behavior
by default." .so I guess that's why I'm seeing good multi-homing behavior
without configuring that command ".site multi-homing"

But interestingly, they mention a few things with that multi-homing command.
they say it tracks bgp neighborship, but I don't know what they mean by
this. "such as to prevent isolation of the PE router from the core or split
brain." Not sure how that *prevents* isolation. If you lose bgp, aren't
you isolated ?!

Also, I'm wondering what the scenario is that they mention in this statement
. "There are scenarios, however that require preventing of BGP peer
tracking, such as in a two-PE-router topology. In such cases, multihoming
should not be explicitly configured as it can break node redundancy." How
would config'ing "protocol vpls site test multi-homing" break node
redundancy ?

- Aaron Gould


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chuck Anderson
2017-10-11 17:37:32 UTC
Permalink
Post by Aaron Gould
(I really should change this subject heading to "BGP VPLS - Multi-homing"
since that's the more specific vpls version we are discussing at this
point... FEC 128 / RFC 4761)
hey look what I just found ..
https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/vp
ns-configuring-vpls-multihoming.html
"When two PE routers use the same site ID, VPLS assumes multihoming behavior
by default." .so I guess that's why I'm seeing good multi-homing behavior
without configuring that command ".site multi-homing"
But interestingly, they mention a few things with that multi-homing command.
they say it tracks bgp neighborship, but I don't know what they mean by
this. "such as to prevent isolation of the PE router from the core or split
brain." Not sure how that *prevents* isolation. If you lose bgp, aren't
you isolated ?!
Also, I'm wondering what the scenario is that they mention in this statement
. "There are scenarios, however that require preventing of BGP peer
tracking, such as in a two-PE-router topology. In such cases, multihoming
should not be explicitly configured as it can break node redundancy." How
would config'ing "protocol vpls site test multi-homing" break node
redundancy ?
Well gee, I think you found my problem I reported here:

https://lists.gt.net/nsp/juniper/60351

I'm going to try removing the multi-homing statement to see if it fixes my issue.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Loading...