[c-nsp] ME3600X Embedded Packet Capture

[adam vitkovsky]

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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ivan
Sent: Monday, August 13, 2012 11:19 AM
To: Waris Sagheer (waris)
Cc: cisco-nsp at puck.nether.net
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:cisco-nsp at itpro.co.nz]
> Sent: Sunday, August 12, 2012 7:17 PM
> To: Pshem Kowalczyk
> Cc: Ivan; Waris Sagheer (waris); cisco-nsp at puck.nether.net
> 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 <cisco-nsp at itpro.co.nz> 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  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/