Re: [c-nsp] ME3600X Stable IOS version

2016-07-14 Thread Jason Lixfeld
15.3(3)S2 here, but if you run IPv6 and egress ACLs, you must pick one or the other. Running them concurrently in any code train on that platform is very likely cause mass chaos on your box due to incorrectly allocating system memory between both features without corruption. Sent from my

Re: [c-nsp] VPLS and RSPAN fun

2016-07-14 Thread Dino Sosic
Hm, yeah, that's my last resort, considering I'll be burning physical interfaces then. I saw some people have done it with L2TPv3 and stuff, so I figured it must be possible with VPLS as well. But hey, 920 is on the lower end anyway. Cheers man Dino -Original Message- From: Jason

Re: [c-nsp] VPLS and RSPAN fun

2016-07-14 Thread Jason Lixfeld
You may not be able to. But, what I've done in the past with success is use a loopback cable with an EoMPLS PW i.e.: ASR920: Physically loop Gi0/1 to Gi0/2 monitor session 1 source int gi0/3 dest int gi0/2 Int gi0/1 Xconnect 1.1.1.1 69 encap mpls Box connected to wireshark: Int gi0/1

[c-nsp] VPLS and RSPAN fun

2016-07-14 Thread Dino Sosic
Hi guys, I have a bit of a tricky thing to set up, so I wonder if someone has experience with this. I have a bunch of ASR920s sitting at the edge, acting as PE devices. On the other side of the VPNv4/l2VPN cloud I have a wireshark box sitting and listening on an interface. I want to be able to

[c-nsp] ME3600X Stable IOS version

2016-07-14 Thread eyeballi77
Hi folks, looking to get opinions on the above. I have reviewed some older posts with 15.3(3) being a common mention, but looking to see what folk are currently running with little / least issues.. Standard fare is MPLS, OSPFv2, BGP VPNv4, EFP with PW. Features for consideration are around

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread David Wilkinson
Thanks, that worked. with l2tp enabled it was giving me a inconsistent peer vlan id, soon as I disabled it STP on the 4948 worked as expected. On 14/07/2016 13:48, Lukas Tribus wrote: So: - match dot1q, not 1ad - pop 1 tag - don't tunnel l2tp

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread David Wilkinson
ah yes, good spot, 9198 plus 14 bytes Ethernet header is 9212 not 9206. On 14/07/2016 12:31, James Bensley wrote: On 14 July 2016 at 12:24, David Wilkinson wrote: The port MTU on the ASR is 9206 and 9198 on the 4948s I'd fix that before it bites you in the bum.

Re: [c-nsp] 40G options for 6807

2016-07-14 Thread Nick Cutting
Yes - I have a few 6807/sup2t's But wanted to know if it is worth waiting for the Sup6T - given that as stated, there are no cards utilizing even the 220G I do have the new 10 gig line cards - and as there is no software to support the 4 x 10 -> 40 - I have already had to breakout 40 gig access

Re: [c-nsp] ASR 9000 Upgrade Expectations

2016-07-14 Thread Werner le Grange
Hi Nick The SMU count for 5.3.3 has grown quite rapidly in the last 2 months. 5.3.4 will be released in about 2 months from now and will include the SMU fixes of 5.3.3. On Wed, Jul 13, 2016 at 3:31 PM, Nick Griffin wrote: > Hello, looking for some details in

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread Lukas Tribus
Hi, > wonder if the 4948 is using 8100 for both the outer and inner tags, in > which case using dot1ad wouldn't match. By default Cisco tags with 8100 for both outer and inner tag. Don't expected 1ad unless explicitly requested/configured on the Catalayst. > Is "rewrite ingress tag pop

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread David Wilkinson
We don't know what VLANs the customer is using within the QinQ. I wonder if the 4948 is using 8100 for both the outer and inner tags, in which case using dot1ad wouldn't match. I will try with dot1q again. Is "rewrite ingress tag pop [1|2] symmetrical" always required? I thought it was only

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread James Bensley
On 14 July 2016 at 12:24, David Wilkinson wrote: > The port MTU on the ASR is 9206 and 9198 on the 4948s I'd fix that before it bites you in the bum. Cheers, James. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread Tom Hill
On 14/07/16 12:09, David Wilkinson wrote: > Can any one point me in the right direction and let me know what I have > done wrong, I am assuming it something on the ASR configuration as QinQs > between the 4948s taking another path without the ASR in the middle work > fine. I *think* you're

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread James Bensley
Just a quick off-the-top-of-my-head response... Have you tried using (on the 9K): interface GigabitEthernet0/0/0/17.427 l2transport encapsulation dot1q 427 second-dot1q ABC ! and optionally rewrite ingress tag pop [1|2] symmetrical Or if it is a range of C-VLANs "encapsulation dot1q 427

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread David Wilkinson
Wouldn't that only affect large packets and not all packets? The port MTU on the ASR is 9206 and 9198 on the 4948s On 14/07/2016 12:15, Curtis Piehler wrote: Make sure the port mtu is higher to allow for additional vlan tags. 4 byte per vlan. On Jul 14, 2016 7:11 AM, "David Wilkinson"

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread Curtis Piehler
Make sure the port mtu is higher to allow for additional vlan tags. 4 byte per vlan. On Jul 14, 2016 7:11 AM, "David Wilkinson" wrote: > Hi, > > We are in the process of migrating some of our links over to Cisco ASR > 9006, they are running IOS XR 5.3.3. > > Normal

[c-nsp] Cisco ASR 9k transporting QinQ traffic

2016-07-14 Thread David Wilkinson
Hi, We are in the process of migrating some of our links over to Cisco ASR 9006, they are running IOS XR 5.3.3. Normal vlan tagged dot1q traffic seems be working fine, apart from some STP fun when pseudowire comes back up and STP doesn't know about the topology changing and both paths are

Re: [c-nsp] ASR 9000 Upgrade Expectations

2016-07-14 Thread James Bensley
On 14 July 2016 at 11:10, Nick Hilliard wrote: > James Bensley wrote: >> Or if you are erasing and installing from fresh on the new version, >> then the box is down for pretty much the whole 2 hours. > > turboboot is not necessarily a bad idea if you're doing jumps from one >

Re: [c-nsp] ASR 9000 Upgrade Expectations

2016-07-14 Thread Nick Hilliard
James Bensley wrote: > Or if you are erasing and installing from fresh on the new version, > then the box is down for pretty much the whole 2 hours. turboboot is not necessarily a bad idea if you're doing jumps from one major version to the next or even 4.3 to 6.0. The turboboot process will add

Re: [c-nsp] err-disable state on a cisco 3750 catalyst

2016-07-14 Thread James Bensley
On 13 July 2016 at 13:13, Olivier CALVANO wrote: > Hi > > i don't have the configuration of the other side, on my side : > > interface Port-channel1 > switchport trunk encapsulation dot1q > switchport mode trunk > > > interface GigabitEthernet1/0/1 > switchport trunk

Re: [c-nsp] ASR 9000 Upgrade Expectations

2016-07-14 Thread James Bensley
On 14 July 2016 at 10:26, James Bensley wrote: > assuming there are no problems, 2 hours actual time Sorry that wasn't clear. That isn't specifically all down time. If you are upgrading IOS-XR over-the-top of the existing version, downtime might be 45 minutes to 1 hour (you

Re: [c-nsp] ASR 9000 Upgrade Expectations

2016-07-14 Thread James Bensley
I'd go 5.3.3 with SP2 if you want stability, or wait for 6.1 to drop if you want to be on the forefront (and lab test heavily of course). I'd also schedule like 5 hours for the maintenance window, not 2 or 3. If you get 90% of the way through an have to roll back, you'll need more time. We are