[c-nsp] ME3600 VPLS configuration with L2VPN CLI

[Jason Lixfeld]

I don't think I'd ever expect a PW to bring up an SVI, but it's an interesting point.  Technically a PW would be like a VLAN on a trunk, which would qualify as something that would be able to bring an SVI up in a flat VLAN environment.

On 2013-06-26, at 11:05 AM, "Aaron" <aaron1 at gvtc.com> wrote:

> Slightly on-topic I guess is...
> 
> I was trying to get an svi to come up with no local ac but only a remote pw
> attached via xconnect to svi and svi would not come up.
> 
> Then I tried to xconnect vfi to svi and then have neighbor under l2 vfi and
> svi still wouldn't come up (I think 15.2(4)S1)
> 
> Is that not possible to get an svi to come up with only a pw attached to it
> ?  ( I moved it all to asr9k and worked fine..... bvi will come up within
> bg:bd even if only pw ac's are used, regardless of whether or not there is a
> local ac phy/subint)
> 
> Aaron
> 
> 
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nick
> Ryce
> Sent: Wednesday, June 26, 2013 9:42 AM
> To: Jason Lixfeld; cisco-nsp at puck.nether.net NSP
> Subject: Re: [c-nsp] ME3600 VPLS configuration with L2VPN CLI
> 
> Hi Jason,
> 
> Just tested this myself.
> 
> Only appears to work if the SVI is created and the member statement added
> there.
> 
> Nick
> 
> --
> Nick Ryce
> 
> Fluency Communications Ltd.
> e. nick at fluency.net.uk
> w. http://fluency.net.uk/
> t. 0845 874 7000
> 
> 
> 
> 
> 
> On 26/06/2013 02:07, "Jason Lixfeld" <jason at lixfeld.ca> wrote:
> 
>> So I'm just trying to understand how VPLS is 'supposed' to work on 
>> ME3600s...
>> 
>> This seems to work:
>> 
>> !
>> interface GigabitEthernet0/3
>> description Facing CE
>> switchport trunk allowed vlan none
>> switchport mode trunk
>> logging event link-status
>> no cdp enable
>> service instance 1 ethernet
>> encapsulation dot1q 4013
>> rewrite ingress tag pop 1 symmetric
>> !
>> !
>> bridge-domain 4013
>> member GigabitEthernet0/3 service-instance 1 !
>> interface Vlan4013
>> vrf forwarding management
>> no ip address
>> member vfi management
>> !
>> 
>> #show l2vpn vfi name management
>> Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
>> 
>> VFI name: management, state: up, type: multipoint, signaling: BGP
>> VPN ID: 4013, VE-ID: 10129, VE-SIZE: 10
>> RD: 21949:2194904013, RT: 21949:4013, 21949:2194904013
>> Bridge-Domain 4013 attachment circuits:
>>   Vlan4013
>> Pseudo-port interface: pseudowire100036
>> Interface          Peer Address    VE-ID  Local Label  Remote Label    S
>> pseudowire100037   72.15.50.33     10033  299          354             Y
>> 
>> However this does not:
>> 
>> !
>> interface GigabitEthernet0/3
>> description Facing CE
>> switchport trunk allowed vlan none
>> switchport mode trunk
>> logging event link-status
>> no cdp enable
>> service instance 1 ethernet
>> encapsulation dot1q 4013
>> rewrite ingress tag pop 1 symmetric
>> !
>> !
>> bridge-domain 4013
>> member GigabitEthernet0/3 service-instance 1  member vfi management !
>> 
>> #show l2vpn vfi name management
>> Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
>> 
>> VFI name: management, state: down, type: multipoint, signaling: BGP
>> VPN ID: 4013, VE-ID: 10129, VE-SIZE: 10
>> RD: 21949:2194904013, RT: 21949:4013, 21949:2194904013
>> Bridge-Domain 4013 attachment circuits:
>> Pseudo-port interface: pseudowire100036
>> Interface          Peer Address    VE-ID  Local Label  Remote Label    S
>> pseudowire100037   72.15.50.33     10033  299          354             Y
>> 
>> So even though in the latter example, vfi management is a member of 
>> bridge-domain 4013, it can't seem to find the attachment circuit.  I 
>> get that the AC wouldn't be Vlan4013, but I'd sorta expect it to know 
>> that it's Gi0/3 si 1.  I'm assuming that since we can now map a vfi to 
>> a bridge-domain, an SVI is no longer required, unless the VPLS instance 
>> is routed VPLS; we'd need somewhere to apply the IP and mask.  Is this 
>> an incorrect assumption or is something not working that really should 
>> be working?
>> 
>> Thanks in advance.
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>