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" <[email protected]> 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:[email protected]] On Behalf Of Nick > Ryce > Sent: Wednesday, June 26, 2013 9:42 AM > To: Jason Lixfeld; [email protected] 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. [email protected] > w. http://fluency.net.uk/ > t. 0845 874 7000 > > > > > > On 26/06/2013 02:07, "Jason Lixfeld" <[email protected]> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
