[j-nsp] VPLS Multihoming and CCC-Down interface flag
Hello,
I recently faced to a strange problem, which i can't understand. Suppose
this network diagram:
MPLS Cloud --- PE (MX80) CE (EX4200) PE (MX80) MPLS Cloud.
As You can see, EX4200 has two uplinks to two MX80, which are part of
MPLS network infrastructure. VPLS Multihoming is configured:
PE1 (gavar)
misak@mx-gavar> show configuration routing-instances Miom_ISP-Inet |
display inheritance | except ##
instance-type vpls;
vlan-id 342;
interface ge-1/1/9.342;
routing-interface irb.342;
route-distinguisher 10.255.255.33:342;
vrf-target target:65500:342;
protocols {
vpls {
site-range 100;
no-tunnel-services;
site martuni {
site-identifier 32;
multi-homing;
site-preference primary;
interface ge-1/1/9.342;
}
site gavar {
site-identifier 33;
}
mac-flush;
connectivity-type irb;
}
}
PE2 (getap)
instance-type vpls;
vlan-id 342;
interface ge-1/1/9.342;
route-distinguisher 10.255.255.10:342;
vrf-target target:65500:342;
protocols {
vpls {
site-range 100;
no-tunnel-services;
site martuni {
site-identifier 32;
multi-homing;
site-preference backup;
interface ge-1/1/9.342;
}
site getap {
site-identifier 10;
}
mac-flush;
}
}
CE site is called martuni, and EX4200 on that site is configured with
vlan-id all on both uplinks.
Now the problem - when one uplinks on EX4200 go down, or for example one
router (getap) goes down, I shouldn't have any problem with this routing
instance, but in this case interface ge-1/1/9.342 goes to CCC-Down state
and stops passing traffic.
There are lot of other VPLS configured on router and that links, and i
noticed that only VPLS-es that exist only on these two PEs show this
behavior. If You have VPLS configured on other PE router throughout MPLS
cloud, links stays up and work as expected.
I tried lot of knobs and options, but no luck. Can anyone explain this
behavior? Any help highly appreciated.
--
Best regards,
Misak Khachatryan,
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion
Hi, Note the junos 7.5 release introduction of multi-homing<http://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/multi-homing-edit-protocols-vpls.html>stanza (under "routing-instances instance-name protocols vpls site site-name") specified in FEC 128 doc. Believe me that with 7.5 release only BGP signaling/autodiscovery was supported - I remember that at this time there was VPLS standard battle<http://www.lightreading.com/document.asp?doc_id=589392> Krasi On 10 September 2013 17:18, Darren O'Connor wrote: > I understand that part, but it doesn't answer the original question. > > Thanks > Darren > http://www.mellowd.co.uk/ccie > > > > > From: per.gran...@gcc.com.cy > > To: darre...@outlook.com; kr...@smartcom.bg > > CC: juniper-nsp@puck.nether.net > > Subject: RE: [j-nsp] VPLS Multihoming on Junos - FEC confusion > > Date: Tue, 10 Sep 2013 13:20:17 + > > > > Perhaps this is useful: > > > > > https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html > > > > There are two places in the configuration where you can configure VPLS > multihoming. One is for FEC 128, and the other is for FEC 129: > > > > For FEC 128-routing-instances instance-name protocols vpls site > site-name multi-homing > > For FEC 129-routing-instances instance-name protocols vpls multi-homing > > > > > > -Original Message- > > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On > Behalf Of Darren O'Connor > > Sent: Tuesday, September 10, 2013 3:53 PM > > To: Krasimir Avramski > > Cc: juniper-nsp@puck.nether.net > > Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion > > > > That's my thought too. However even the 12.3 VPLS configuration guide > states FEC128 multihoming. But again showing with BGP > > > > Thanks > > Darren > > http://www.mellowd.co.uk/ccie > > > > > > > > Date: Mon, 9 Sep 2013 23:30:08 +0300 > > Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion > > From: kr...@smartcom.bg > > To: darre...@outlook.com > > CC: juniper-nsp@puck.nether.net > > > > Hello, > > IMHO there is mess with docs/terms. FEC 128 multihoming as described has > nothing to do with ldp. It's bgp signaling and autodiscovery. > > Krasi > > > > > > On 8 September 2013 22:37, Darren O'Connor wrote: > > > > > > > > > > > > > > > > Hi list. > > > > > > > > I'm going over the VPLS multihoming options on Juniper's web site. I'm > not concerned with LAG and MC-LAG for the moment. > > > > > > > > As far as I'm aware, FEC128 is when you are using manual discovery of > pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery. > > > > > > > > Juniper techpub for FEC129 multihoming I don't have a problem with as it > shows how to multihome with BGP: > https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html > > > > > > > > > > The FEC128 multihome techpub says that you cannot enable LDP signalling, > you have to use BGP signalling: > http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html > > > > > > > > > > > > > > I know that you can use LDP for manual discovery and LDP will then > signal VC labels. You can also use BGP for auto-discovery and LDP for VC > label signalling. You can also use BGP for both. > > > > > > > > What I don't get is how you could use FEC128 with BGP signalling. Junos > doesn't give you the option to only signal through BGP but manual discovery > through LDP. > > > > > > > > So my question is, when exactly would the FEC128 config be used over the > FEC129 config? If you are using BGP for signalling are you not using BGP > for discovery at the same time? > > > > > > > > Or maybe I'm just misunderstanding something. > > > > > > > > > > > > Thanks > > > > Darren > > > > http://www.mellowd.co.uk/ccie > > > > > > > > > > > > > > > > ___ > > > > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion
I understand that part, but it doesn't answer the original question. Thanks Darren http://www.mellowd.co.uk/ccie > From: per.gran...@gcc.com.cy > To: darre...@outlook.com; kr...@smartcom.bg > CC: juniper-nsp@puck.nether.net > Subject: RE: [j-nsp] VPLS Multihoming on Junos - FEC confusion > Date: Tue, 10 Sep 2013 13:20:17 + > > Perhaps this is useful: > > https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html > > There are two places in the configuration where you can configure VPLS > multihoming. One is for FEC 128, and the other is for FEC 129: > > For FEC 128-routing-instances instance-name protocols vpls site site-name > multi-homing > For FEC 129-routing-instances instance-name protocols vpls multi-homing > > > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Darren O'Connor > Sent: Tuesday, September 10, 2013 3:53 PM > To: Krasimir Avramski > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion > > That's my thought too. However even the 12.3 VPLS configuration guide states > FEC128 multihoming. But again showing with BGP > > Thanks > Darren > http://www.mellowd.co.uk/ccie > > > > Date: Mon, 9 Sep 2013 23:30:08 +0300 > Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion > From: kr...@smartcom.bg > To: darre...@outlook.com > CC: juniper-nsp@puck.nether.net > > Hello, > IMHO there is mess with docs/terms. FEC 128 multihoming as described has > nothing to do with ldp. It's bgp signaling and autodiscovery. > Krasi > > > On 8 September 2013 22:37, Darren O'Connor wrote: > > > > > > > > Hi list. > > > > I'm going over the VPLS multihoming options on Juniper's web site. I'm not > concerned with LAG and MC-LAG for the moment. > > > > As far as I'm aware, FEC128 is when you are using manual discovery of > pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery. > > > > Juniper techpub for FEC129 multihoming I don't have a problem with as it > shows how to multihome with BGP: > https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html > > > > > The FEC128 multihome techpub says that you cannot enable LDP signalling, you > have to use BGP signalling: > http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html > > > > > > > I know that you can use LDP for manual discovery and LDP will then signal VC > labels. You can also use BGP for auto-discovery and LDP for VC label > signalling. You can also use BGP for both. > > > > What I don't get is how you could use FEC128 with BGP signalling. Junos > doesn't give you the option to only signal through BGP but manual discovery > through LDP. > > > > So my question is, when exactly would the FEC128 config be used over the > FEC129 config? If you are using BGP for signalling are you not using BGP for > discovery at the same time? > > > > Or maybe I'm just misunderstanding something. > > > > > > Thanks > > Darren > > http://www.mellowd.co.uk/ccie > > > > > > > > ___ > > 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] VPLS Multihoming on Junos - FEC confusion
Perhaps this is useful: https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html There are two places in the configuration where you can configure VPLS multihoming. One is for FEC 128, and the other is for FEC 129: For FEC 128-routing-instances instance-name protocols vpls site site-name multi-homing For FEC 129-routing-instances instance-name protocols vpls multi-homing -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Darren O'Connor Sent: Tuesday, September 10, 2013 3:53 PM To: Krasimir Avramski Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion That's my thought too. However even the 12.3 VPLS configuration guide states FEC128 multihoming. But again showing with BGP Thanks Darren http://www.mellowd.co.uk/ccie Date: Mon, 9 Sep 2013 23:30:08 +0300 Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion From: kr...@smartcom.bg To: darre...@outlook.com CC: juniper-nsp@puck.nether.net Hello, IMHO there is mess with docs/terms. FEC 128 multihoming as described has nothing to do with ldp. It's bgp signaling and autodiscovery. Krasi On 8 September 2013 22:37, Darren O'Connor wrote: Hi list. I'm going over the VPLS multihoming options on Juniper's web site. I'm not concerned with LAG and MC-LAG for the moment. As far as I'm aware, FEC128 is when you are using manual discovery of pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery. Juniper techpub for FEC129 multihoming I don't have a problem with as it shows how to multihome with BGP: https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html The FEC128 multihome techpub says that you cannot enable LDP signalling, you have to use BGP signalling: http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html I know that you can use LDP for manual discovery and LDP will then signal VC labels. You can also use BGP for auto-discovery and LDP for VC label signalling. You can also use BGP for both. What I don't get is how you could use FEC128 with BGP signalling. Junos doesn't give you the option to only signal through BGP but manual discovery through LDP. So my question is, when exactly would the FEC128 config be used over the FEC129 config? If you are using BGP for signalling are you not using BGP for discovery at the same time? Or maybe I'm just misunderstanding something. Thanks Darren http://www.mellowd.co.uk/ccie ___ 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] VPLS Multihoming on Junos - FEC confusion
That's my thought too. However even the 12.3 VPLS configuration guide states FEC128 multihoming. But again showing with BGP Thanks Darren http://www.mellowd.co.uk/ccie Date: Mon, 9 Sep 2013 23:30:08 +0300 Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion From: kr...@smartcom.bg To: darre...@outlook.com CC: juniper-nsp@puck.nether.net Hello, IMHO there is mess with docs/terms. FEC 128 multihoming as described has nothing to do with ldp. It's bgp signaling and autodiscovery. Krasi On 8 September 2013 22:37, Darren O'Connor wrote: Hi list. I'm going over the VPLS multihoming options on Juniper's web site. I'm not concerned with LAG and MC-LAG for the moment. As far as I'm aware, FEC128 is when you are using manual discovery of pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery. Juniper techpub for FEC129 multihoming I don't have a problem with as it shows how to multihome with BGP: https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html The FEC128 multihome techpub says that you cannot enable LDP signalling, you have to use BGP signalling: http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html I know that you can use LDP for manual discovery and LDP will then signal VC labels. You can also use BGP for auto-discovery and LDP for VC label signalling. You can also use BGP for both. What I don't get is how you could use FEC128 with BGP signalling. Junos doesn't give you the option to only signal through BGP but manual discovery through LDP. So my question is, when exactly would the FEC128 config be used over the FEC129 config? If you are using BGP for signalling are you not using BGP for discovery at the same time? Or maybe I'm just misunderstanding something. Thanks Darren http://www.mellowd.co.uk/ccie ___ 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] VPLS Multihoming on Junos - FEC confusion
Hello, IMHO there is mess with docs/terms. FEC 128 multihoming as described has nothing to do with ldp. It's bgp signaling and autodiscovery. Krasi On 8 September 2013 22:37, Darren O'Connor wrote: > > > > Hi list. > > I'm going over the VPLS multihoming options on Juniper's web site. I'm not > concerned with LAG and MC-LAG for the moment. > > As far as I'm aware, FEC128 is when you are using manual discovery of > pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery. > > Juniper techpub for FEC129 multihoming I don't have a problem with as it > shows how to multihome with BGP: > https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html > > The FEC128 multihome techpub says that you cannot enable LDP signalling, > you have to use BGP signalling: > http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html > > > I know that you can use LDP for manual discovery and LDP will then signal > VC labels. You can also use BGP for auto-discovery and LDP for VC label > signalling. You can also use BGP for both. > > What I don't get is how you could use FEC128 with BGP signalling. Junos > doesn't give you the option to only signal through BGP but manual discovery > through LDP. > > So my question is, when exactly would the FEC128 config be used over the > FEC129 config? If you are using BGP for signalling are you not using BGP > for discovery at the same time? > > Or maybe I'm just misunderstanding something. > > > Thanks > Darren > http://www.mellowd.co.uk/ccie > > > > ___ > 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] VPLS Multihoming on Junos - FEC confusion
Hi list. I'm going over the VPLS multihoming options on Juniper's web site. I'm not concerned with LAG and MC-LAG for the moment. As far as I'm aware, FEC128 is when you are using manual discovery of pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery. Juniper techpub for FEC129 multihoming I don't have a problem with as it shows how to multihome with BGP: https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html The FEC128 multihome techpub says that you cannot enable LDP signalling, you have to use BGP signalling: http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html I know that you can use LDP for manual discovery and LDP will then signal VC labels. You can also use BGP for auto-discovery and LDP for VC label signalling. You can also use BGP for both. What I don't get is how you could use FEC128 with BGP signalling. Junos doesn't give you the option to only signal through BGP but manual discovery through LDP. So my question is, when exactly would the FEC128 config be used over the FEC129 config? If you are using BGP for signalling are you not using BGP for discovery at the same time? Or maybe I'm just misunderstanding something. Thanks Darren http://www.mellowd.co.uk/ccie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming
Correct (Assuming each PE only has 1 Link to the CE Network…) Chris - Chairman of the "STP is evil and should be avoided if possible" Committee. =) On 2012-11-28, at 1:24 PM, Luca Salvatore wrote: > Right, this is what I thought. Thanks for the info. > So this type of configuration means that spanning-tree is not needed between > CE and PE then? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming
Right, this is what I thought. Thanks for the info. So this type of configuration means that spanning-tree is not needed between CE and PE then? Luca -Original Message- From: Chris Kawchuk [mailto:juniperd...@gmail.com] Sent: Wednesday, 28 November 2012 1:09 PM To: Luca Salvatore Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] VPLS Multihoming On 2012-11-28, at 9:36 AM, Luca Salvatore wrote: > So - my understanding is that VPLS multihoming is used to prevent layer 2 > loops. How is this accomplished? > Is it because the backup PE device does not forward any traffic (except for > LDP stuff) and hence no loop is formed since backup PE is in a sort of > 'blocking' state? The backup PE signals (to the rest of the network) that it isnt the "designated" PE for that particular site-identifier endpoint (due to the priority setting) via BGP. All the other PEs in the network simply don't forward traffic to it, nor does that 'backup' PE forward any CE traffic into the network. Ergo, no L2 loop. "show vpls connections" should reflect this state of affairs. - CK. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming
On 2012-11-28, at 9:36 AM, Luca Salvatore wrote: > So - my understanding is that VPLS multihoming is used to prevent layer 2 > loops. How is this accomplished? > Is it because the backup PE device does not forward any traffic (except for > LDP stuff) and hence no loop is formed since backup PE is in a sort of > 'blocking' state? The backup PE signals (to the rest of the network) that it isnt the "designated" PE for that particular site-identifier endpoint (due to the priority setting) via BGP. All the other PEs in the network simply don't forward traffic to it, nor does that 'backup' PE forward any CE traffic into the network. Ergo, no L2 loop. "show vpls connections" should reflect this state of affairs. - CK. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VPLS Multihoming
Hello, I have two PE MX10 routers at each end of a connection and I have configured them for VPLS multihoming. I have one device configured as primary and one device configured as backup. Everything is working as expected but I have a question regarding the PE in backup mode. So - my understanding is that VPLS multihoming is used to prevent layer 2 loops. How is this accomplished? Is it because the backup PE device does not forward any traffic (except for LDP stuff) and hence no loop is formed since backup PE is in a sort of 'blocking' state? Thanks, Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming
Luca, My question is - on PE2 is it normal for it to show the VPLS connections in a 'LN' (local site not designated) state, as shown below: PE2>show vpls connections Layer-2 VPN connections: Legend for interface status Up -- operational Dn -- down Instance: VPLS-DirectNetworks Local site: IC2-VPLS (2) connection-site Type St Time last up # Up trans 1 rmt LN 2 rmt LN This page on the juniper site seems to show a similar output but I just wanted to confirm http://www.juniper.net/techpubs/en_US/junos12.2/topics/example/vpls-multihomed-example.html Yes, this is typical. And so on PE1, your primary site probably shows status "RN" for site 2 (remote site not designated). Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VPLS Multihoming
Hi Guys,
I've configured two MX routers (PE) to use VPLS multihoming.
Both PE routers connect into two EX4500's in VC mode
PE1 is configured as primary and PE2 is configured as backup
The config on each MX is:
PE1:
PE1> show configuration routing-instances
VPLS-DirectNetworks {
instance-type vpls;
vlan-id all;
interface ge-1/1/0.1;
route-distinguisher 10.255.0.11:2;
vrf-target target:65100:2;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site IC2-VPLS {
site-identifier 2;
multi-homing;
site-preference primary;
PE2:
PE2>show configuration routing-instances
VPLS-DirectNetworks {
instance-type vpls;
vlan-id all;
interface ge-1/1/0.1;
route-distinguisher 10.255.0.12:2;
vrf-target target:65100:2;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site IC2-VPLS {
site-identifier 2;
multi-homing;
site-preference backup;
My question is - on PE2 is it normal for it to show the VPLS connections in a
'LN' (local site not designated) state, as shown below:
PE2>show vpls connections
Layer-2 VPN connections:
Legend for interface status
Up -- operational
Dn -- down
Instance: VPLS-DirectNetworks
Local site: IC2-VPLS (2)
connection-site Type St Time last up # Up trans
1 rmt LN
2 rmt LN
This page on the juniper site seems to show a similar output but I just wanted
to confirm
http://www.juniper.net/techpubs/en_US/junos12.2/topics/example/vpls-multihomed-example.html
thanks,
Luca
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS multihoming in 9.1
It looks lie JUNOS 9.1 does not support multihomed and single homed sites on
the same PE in the same VPLS. When I removed the single homed site and left
only multihomes, things came up.
On Thu, Jul 31, 2008 at 2:40 PM, Marlon Duksa <[EMAIL PROTECTED]> wrote:
> Does anyone know why my multihomed site would not establish PW.
>
> I have a meshed topology of 3 nodes (PEs), and two of the three nodes are
> multihoming a single CE site.
> In addition, I also have singlehomed sites in my VPLS and they are just
> fine (connection is up).
>
> But for the multihomed site I get the LM status on one multihomed PE and LN
> and SC status on the other multihomed PE.
> Why would I get SC (collision) when the documentation clearly says that
> multihomed sites must have the same site ID?
> Not sure at all why I'm getting the LN and LM status.
> I do have the same RD and RT in all three PEs, but this should be fine.
>
> Can anyone help? Thanks,
> Marlon
>
> Here is the relevant config from the two nodes and 'show vpls connections'
> output:
>
> 1st PE:
> [EMAIL PROTECTED] show routing-instances
> vpls {
> instance-type vpls;
> interface ge-0/1/1.0;
> interface ge-8/2/0.0;
> interface ge-5/3/4.0;
> route-distinguisher 100:100;
> vrf-target target:200:200;
> protocols {
> vpls {
> site-range 10;
> no-tunnel-services;
> site green {
> site-identifier 1;
> interface ge-0/1/1.0;
> interface ge-8/2/0.0;
> }
> site multi {
> site-identifier 4;
> multi-homing;
> interface ge-5/3/4.0;
> }
> }
> }
> }
>
> [EMAIL PROTECTED] run show vpls connections extensive
> Layer-2 VPN connections:
>
> Legend for connection status (St)
> EI -- encapsulation invalid NC -- interface encapsulation not
> CCC/TCC/VPLS
> EM -- encapsulation mismatch WE -- interface and instance encaps not
> same
> VC-Dn -- Virtual circuit downNP -- interface hardware not present
> CM -- control-word mismatch -> -- only outbound connection is up
> CN -- circuit not provisioned<- -- only inbound connection is up
> OR -- out of range Up -- operational
> OL -- no outgoing label Dn -- down
> LD -- local site signaled down CF -- call admission control failure
> RD -- remote site signaled down SC -- local and remote site ID collision
> LN -- local site not designated LM -- local site ID not minimum designated
> RN -- remote site not designated RM -- remote site ID not minimum
> designated
> XX -- unknown connection status IL -- no incoming label
> MM -- MTU mismatch MI -- Mesh-Group ID not availble
>
> Legend for interface status
> Up -- operational
> Dn -- down
>
> Instance: vpls
> Local site: green (1)
> Number of local interfaces: 2
> Number of local interfaces up: 2
> IRB interface present: no
> ge-0/1/1.0
> ge-8/2/0.0
> lsi.1049088 2 Intf - vpls vpls local site 1 remote site
> 2
> lsi.1049089 3 Intf - vpls vpls local site 1 remote site
> 3
> 262145 1 8 100
> status-vector: 9F
> connection-site Type St Time last up # Up trans
> 2 rmt Up Jul 31 20:10:57 2008 1
> Local interface: lsi.1049088, Status: Up, Encapsulation: VPLS
> Description: Intf - vpls vpls local site 1 remote site 2
> Remote PE: 2.2.2.2, Negotiated control-word: No
> Incoming label: 262146, Outgoing label: 80
>
> Connection History:
> Jul 31 20:10:57 2008 status update timer
> Jul 31 20:10:57 2008 PE route changed
> Jul 31 20:10:57 2008 Out lbl Update80
> Jul 31 20:10:57 2008 In lbl Update 262146
> Jul 31 20:10:57 2008 loc intf up lsi.1049088
> 3 rmt Up Jul 31 20:10:57 2008 1
> Local interface: lsi.1049089, Status: Up, Encapsulation: VPLS
> Description: Intf - vpls vpls local site 1 remote site 3
> Remote PE: 3.3.3.3, Negotiated control-word: No
> Incoming label: 262147, Outgoing label: 80
>
> Connection History:
> Jul 31 20:10:57 2008 status update timer
> Jul 31 20:10:57 2008 PE route changed
> Jul 31 20:10:57 2008 Out lbl Update80
> Jul 31 20:10:57 2008 In lbl Update 262147
> Jul 31 20:10:57 2008 loc intf up lsi.1049089
> Local site: multi (4)
> Number of local interfaces: 1
> Number of local interfaces up: 1
> IRB interface present: no
> ge-5/3/4.0
> lsi.1049090 2 Intf - vpls vpls local site 4 remote site
> 2
> Interface flags: VC-Down
> lsi.1049091 3 Intf - vpls vpls local site 4 remote si
[j-nsp] VPLS multihoming in 9.1
Does anyone know why my multihomed site would not establish PW.
I have a meshed topology of 3 nodes (PEs), and two of the three nodes are
multihoming a single CE site.
In addition, I also have singlehomed sites in my VPLS and they are just fine
(connection is up).
But for the multihomed site I get the LM status on one multihomed PE and LN
and SC status on the other multihomed PE.
Why would I get SC (collision) when the documentation clearly says that
multihomed sites must have the same site ID?
Not sure at all why I'm getting the LN and LM status.
I do have the same RD and RT in all three PEs, but this should be fine.
Can anyone help? Thanks,
Marlon
Here is the relevant config from the two nodes and 'show vpls connections'
output:
1st PE:
[EMAIL PROTECTED] show routing-instances
vpls {
instance-type vpls;
interface ge-0/1/1.0;
interface ge-8/2/0.0;
interface ge-5/3/4.0;
route-distinguisher 100:100;
vrf-target target:200:200;
protocols {
vpls {
site-range 10;
no-tunnel-services;
site green {
site-identifier 1;
interface ge-0/1/1.0;
interface ge-8/2/0.0;
}
site multi {
site-identifier 4;
multi-homing;
interface ge-5/3/4.0;
}
}
}
}
[EMAIL PROTECTED] run show vpls connections extensive
Layer-2 VPN connections:
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not
CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not
same
VC-Dn -- Virtual circuit downNP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned<- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch MI -- Mesh-Group ID not availble
Legend for interface status
Up -- operational
Dn -- down
Instance: vpls
Local site: green (1)
Number of local interfaces: 2
Number of local interfaces up: 2
IRB interface present: no
ge-0/1/1.0
ge-8/2/0.0
lsi.1049088 2 Intf - vpls vpls local site 1 remote site
2
lsi.1049089 3 Intf - vpls vpls local site 1 remote site
3
262145 1 8 100
status-vector: 9F
connection-site Type St Time last up # Up trans
2 rmt Up Jul 31 20:10:57 2008 1
Local interface: lsi.1049088, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls local site 1 remote site 2
Remote PE: 2.2.2.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 80
Connection History:
Jul 31 20:10:57 2008 status update timer
Jul 31 20:10:57 2008 PE route changed
Jul 31 20:10:57 2008 Out lbl Update80
Jul 31 20:10:57 2008 In lbl Update 262146
Jul 31 20:10:57 2008 loc intf up lsi.1049088
3 rmt Up Jul 31 20:10:57 2008 1
Local interface: lsi.1049089, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls local site 1 remote site 3
Remote PE: 3.3.3.3, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 80
Connection History:
Jul 31 20:10:57 2008 status update timer
Jul 31 20:10:57 2008 PE route changed
Jul 31 20:10:57 2008 Out lbl Update80
Jul 31 20:10:57 2008 In lbl Update 262147
Jul 31 20:10:57 2008 loc intf up lsi.1049089
Local site: multi (4)
Number of local interfaces: 1
Number of local interfaces up: 1
IRB interface present: no
ge-5/3/4.0
lsi.1049090 2 Intf - vpls vpls local site 4 remote site
2
Interface flags: VC-Down
lsi.1049091 3 Intf - vpls vpls local site 4 remote site
3
Interface flags: VC-Down
262153 1 8 100
status-vector: 9F
connection-site Type St Time last up # Up trans
2 rmt LM
3 rmt LM
{master}[edit]
[EMAIL PROTECTED]
second PE:
routing-instances {
vpls {
instance-type vpls;
interface ge-5/0/0.0;
interface ge-3/0/2.0;
interface
