Re: [c-nsp] ME3600X Embedded Packet Capture

2012-08-12 Thread Ivan
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 wrote: > > {cut} > >> xconnect 1.2.3.4 666 en

Re: [c-nsp] ME3600X Embedded Packet Capture

2012-08-12 Thread Pshem Kowalczyk
Hi, On 11 August 2012 10:32, Ivan 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 r

[c-nsp] Serving static AAAA records with IOS

2012-08-12 Thread e...@linux.ca
Hi guys, Has anyone managed to get IOS to serve statically defined records? I do this just fine with A records as such : ip dns server ip host ns.example.com 1.1.1.1 ip host somehost.example.com 1.1.1.2 ip dns primary example.org soa ns.example.org some...@example.com 21600 900 7776000 86400

Re: [c-nsp] ASR9K limitations

2012-08-12 Thread Mikael Abrahamsson
On Sun, 12 Aug 2012, Mark Tinka wrote: Last I heard from Cisco is that it is likely expected behaviour because the RFC implies the same, i.e., DAD conflicts are not cleared automatically (I'll be honest, I haven't verified this claim in the RFC itself). Best way is to just disable DAD on core

Re: [c-nsp] ASR9K limitations

2012-08-12 Thread Mark Tinka
On Friday, June 29, 2012 07:39:06 PM Florian Lohoff wrote: > The only bug we have had so far was IPv6 native going > down on an interface when looping externally e.g. DWDM > transport and not getting back up until ipv6 is removed > from and added to the interface again. We monitor IPv6 > interface