[c-nsp] ME3600 VPLS configuration with L2VPN CLI

Jason Lixfeld jason at lixfeld.ca
Wed Jun 26 10:59:42 EDT 2013


Hi Nick,

So even though the bridge-domain is an anchor to latch the VLAN into the global vlan space, and you can add a bridge-domain as a member of a vfi, you still need an SVI (which is also a global VLAN space anchor) in order to get a VFI to come up.  Seems like a hook is missing somewhere, no?  I would imagine that an SVI as an anchor is a relic from the old days (unless, that is, routed VPLS).

On 2013-06-26, at 10:41 AM, Nick Ryce <nick at fluency.net.uk> wrote:

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




More information about the cisco-nsp mailing list