Ivan, Now as you switched to MPLS to the access layer approach and literally creating p2p wires between two customer devices Customers should understand they cannot involve you with mac learning issues between two datacenters
Or you could consider managed services and start deploying ISP managed CE devices as a value added service addition to the p2p wire adam -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ivan Sent: Monday, August 13, 2012 11:19 AM To: Waris Sagheer (waris) Cc: [email protected] Subject: Re: [c-nsp] ME3600X Embedded Packet Capture Hi Waris, Thanks, I hadn't tested the bridging mode yet on this platform but have used on the ES+ linecards. Wouldn't be looking to use all the time as I like the per port vlan scope when doing the xconnect on the evc. Reconfiguring to bridging method for troubleshooting purposes seems to be the only option for checking mac address. Cheers Ivan On 13/Aug/2012 7:47 p.m., Waris Sagheer (waris) wrote: > Hi Ivan, > You can use the following EVPL configuration which would allow you to see the mac addresses e.g. in the following example you can see the mac addresses under bridge-domain 10. > > interface GigabitEthernet0/1 > switchport trunk allowed vlan none > switchport mode trunk > service instance 10 ethernet > encapsulation dot1q 100 > rewrite ingress tag pop 1 symmetric > bridge-domain 10 > > interface Vlan10 > no ip address > xconnect 2.2.2.2 10 encapsulation mpls > > > Regards, > Waris > > > -----Original Message----- > From: Ivan [mailto:[email protected]] > Sent: Sunday, August 12, 2012 7:17 PM > To: Pshem Kowalczyk > Cc: Ivan; Waris Sagheer (waris); [email protected] > Subject: Re: [c-nsp] ME3600X Embedded Packet Capture > > Hi, > > Yes, as far as I understand there is no mac learning which is great for resource utilisation and scalability. No requirement other than "it is helpful for troubleshooting" to see any macs. > > Cheers > > Ivan > >> Hi, >> >> >> On 11 August 2012 10:32, Ivan <[email protected]> wrote: >> >> {cut} >> >>> xconnect 1.2.3.4 666 encapsulation mpls >> Speaking from general experience - this is the culprit. In >> point-to-point L2VPNs there is (usually, I admit I'm not sure if >> that's the case on 3600x) no MAC address learning (which nicely >> conserves the resources on the switch). If you really need to see >> that address - you should turn that into a point-to-point VPLS. >> >> kind regards >> Pshem >> > _______________________________________________ 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/
