[c-nsp] Dell VLT to Cisco VSS
I'm told Dell VLT is very similar to Nexus VPC. I plan to connect 2 Dell S4820T switches to a VSS'ed 6500 (QSFP+ breakout cables) It would be similar to 2 nexus5/7k's connected to a VSS pair. Or am I a mad man, dancing with inter-vendor prop tech - and would be better off with a normal LACP port channel to one 6500, for each switch? Does anyone have an field experience doing this? Thanks, Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
> Using the dispute mechanism included in the IEEE 802.1D-2004 RSTP > standard... I'm wondering if there's any reason to keep loop guard configured I think the dispute mechanism can detect unidirectionality where data out of the designated bridge is lost (which is enough to prevent loops), not the unidirectionality in the other direction. So the dispute does half of what UDLD does, if I got it right. Loop guard is different, it protects only from self-looped ports. I don't know if the wording of RSTP are written in a way to protect you from that, but I'm sure that the original STP standard was written in such a way that any compliant implementation was unable to block the loop caused by a self-looped port. Most vendors quietly worked around this, and I don't know if 802.1d corrected this error in the previous standard. I know that it is very unlikely to find a switch whose STP can't protect you from such a situation. So I bet that if you use RSTP you can disable loopguard, and if you like UDLD there is still a reason to use it. My personal best practice when using this errdisable features is to always enable auto recovery after a suitable time. Cheers, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 1000BASE-ZX/LH multi-manufacturer interconnection
> equipments of different vendors using 1000BASE-ZX/LH. Since 1000BASE-ZX > isn`t standardized by IEEE, ... Can I connect 2 equipments of different > manufactures > using their own manufactured transceiver? We do it all the time and never had any problem. Of course you have to comply with minumum attenuation requirements (don't test them with a short patch, you could damage your receivers). I too am curious to hear about stories of such incompatibilities, if any. The lack of a standard means that if it actually doesn't work, you will have a hard time to blame it on vendors. I'm afraid you have to accept this risk. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Dell VLT to Cisco VSS
VSS is single control plane so it's all one big chassis, the dell switch would have no idea it isn't connected to a single 6500 and should work without issues. VPC is dual control planes using mLAG which is still transparent to the LAG partner as long as the control protocol is standard (802.1ax w/ LACP for example) there *should* be no issues. stritcly talking about link aggregation here, whatever else you might be running is another story as with everything... test it first :) On 1/18/2016 3:12 AM, Nick Cutting wrote: I'm told Dell VLT is very similar to Nexus VPC. I plan to connect 2 Dell S4820T switches to a VSS'ed 6500 (QSFP+ breakout cables) It would be similar to 2 nexus5/7k's connected to a VSS pair. Or am I a mad man, dancing with inter-vendor prop tech - and would be better off with a normal LACP port channel to one 6500, for each switch? Does anyone have an field experience doing this? Thanks, Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 p...@gtcomm.net http://www.gtcomm.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Dell VLT to Cisco VSS
I am familiar with the theory I was wondering If anyone had actually done this, and if there are any real world caveats. I will be testing this week, however the kit is in Hong Kong, so it's a bit "remote handsy" -Original Message- From: Paul [mailto:p...@gtcomm.net] Sent: 18 January 2016 09:38 To: Nick Cutting; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Dell VLT to Cisco VSS VSS is single control plane so it's all one big chassis, the dell switch would have no idea it isn't connected to a single 6500 and should work without issues. VPC is dual control planes using mLAG which is still transparent to the LAG partner as long as the control protocol is standard (802.1ax w/ LACP for example) there *should* be no issues. stritcly talking about link aggregation here, whatever else you might be running is another story as with everything... test it first :) On 1/18/2016 3:12 AM, Nick Cutting wrote: > I'm told Dell VLT is very similar to Nexus VPC. > I plan to connect 2 Dell S4820T switches to a VSS'ed 6500 (QSFP+ > breakout cables) It would be similar to 2 nexus5/7k's connected to a VSS pair. > > Or am I a mad man, dancing with inter-vendor prop tech - and would be better > off with a normal LACP port channel to one 6500, for each switch? > > Does anyone have an field experience doing this? > > Thanks, > Nick > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 p...@gtcomm.net http://www.gtcomm.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] PPPoE on ASR1000
Hello Folks! I need IOS-XE suggestion for PPPoE termination on Cisco ASR1004. I have nearly 5k sessions. Now we use Cisco IOS XE Software, Version 03.11.04.S. On this ASR1000 the following services are configured: PPPoE termination IPoE termination ISG Thanks in advance. Murat Kaipov ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
On 18 January 2016 at 10:57, Michele Bergonzoni wrote: Hey, > So the dispute does half of what UDLD does, if I got it right. Ethernet with autonegotiation on should detect unidirectional links automatically and go down on both ends at RTT/2 delay. On A-B link, where A=>B works but A<=B does not, A will go down and A will assert RFI or remote fault indicator on the line. B will receive this, and go down as well. Some platforms can assert this RFI for non-fault reasons, like port might be configured to assert RFI if xconnect/l2circuit goes down, so client will see port physically down, if EoMPLS fails. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR920 "console" port....ugh
On 17/01/16 11:10, Saku Ytti wrote: On 17 January 2016 at 04:04, Erik Sundberg wrote: Nah... The next model will be console via bluetooth. I would hope people include in their RFPs true OOB as requirement. I think only one in networking market doing that is Cisco in their products with CMP. So Nexus7k RP1, SUP2T, RSP880? As I'm sure you know, Cisco ditched this in N7k sup-2, because "customer didn't want it". So evidently, no, people aren't putting this in RFPs :o( ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 1000BASE-ZX/LH multi-manufacturer interconnection
Well, I need manufacturers warranty for every piece of the equipment, including the optical transceiver... That's the reason. Also, I don't know what manufacturer will win the RFP/buying processes for each equipment Thanks for your reply! 2016-01-16 9:34 GMT-02:00 Nick Hilliard : > Livio Zanol Puppim wrote: > > *So my question is: Can I connect 2 equipments of different manufactures > > using their own manufactured transceiver? Will there be a problem in this > > connection?* > > it's nearly certain to work fine - almost all transceivers use wide-band > receivers. > > But why on earth are you buying vendor transceivers? Reputable third > party transceivers work just as well and there are several vendors with > transceiver programmers. Vendor transceivers are mostly a waste of money. > > Nick > > -- []'s Lívio Zanol Puppim ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 1000BASE-ZX/LH multi-manufacturer interconnection
Michele, Thanks for your reply! From which manufacturers do you interconnect equipments with EX/ZX (or ER/ZR)? I'm worried because of the different Wavelenght Range of the transceivers... 2016-01-18 7:23 GMT-02:00 Michele Bergonzoni : > > equipments of different vendors using 1000BASE-ZX/LH. Since 1000BASE-ZX > > isn`t standardized by IEEE, ... Can I connect 2 equipments of different > manufactures > > using their own manufactured transceiver? > > We do it all the time and never had any problem. Of course you have to > comply with minumum attenuation requirements (don't test them with a short > patch, you could damage your receivers). > > I too am curious to hear about stories of such incompatibilities, if any. > > The lack of a standard means that if it actually doesn't work, you will > have a hard time to blame it on vendors. I'm afraid you have to accept this > risk. > > Regards, >Bergonz > > -- > Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. > Phone:+39-051-6781926 e-mail: berg...@labs.it > alt.advanced.networks.design.configure.operate > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- []'s Lívio Zanol Puppim ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 1000BASE-ZX/LH multi-manufacturer interconnection
> From which manufacturers do you interconnect equipments with EX/ZX (or > ER/ZR)? I've seen working links among Cisco, Juniper and Extreme networks. Bye, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
> On A-B link, where A=>B works but A<=B does not, A will go down and A > will assert RFI or remote fault indicator on the line. B will receive > this, and go down as well. You're right as usual. I actually happened to see a 1000baseLX port in dispute a few years ago, so you made me dig through old emails and tickets. It was a 6500 facing a 3750, and it was because MSTP BPDUs where incorrectly tagged, probably due to CSCta17209, we fixed upgrading the 3750. Probably UDLD wouldn't have helped either. Thanks, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 1000BASE-ZX/LH multi-manufacturer interconnection
On 18/01/16 11:23, Livio Zanol Puppim wrote: Well, I need manufacturers warranty for every piece of the equipment, including the optical transceiver... That's the reason. Also, I don't know what manufacturer will win the RFP/buying processes for each equipment You can get manufacturer warranty on 3rd party transceivers - from the transceiver vendor. Nick is right, equipment vendor transceivers are overpriced and not better quality, as well as offering a narrower choice of optics. It is (almost) always better to get reputable 3rd party transceivers which can be recoded for "compatibility". But it's your choice, of course ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 1000BASE-ZX/LH multi-manufacturer interconnection
Hi, On Mon, Jan 18, 2016 at 12:00:47PM +, Phil Mayers wrote: > But it's your choice, of course Don't talk too many people out of buying vendor optics - if that source of revenue is no longer working, they will have to compensate by introducing silly extra license fees, etc. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations
Thanks everyone for the responses as they have been quite informative. QoS strategies/testing was next/last on my list to hammer out this week so the behavior mentioned below is especially helpful. Regards, Darin From: cisco-nsp on behalf of James Jun Sent: Saturday, January 16, 2016 10:15 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations On Sat, Jan 16, 2016 at 03:54:01PM +0200, Mark Tinka wrote: > > On 16/Jan/16 13:57, Eric Van Tol wrote: > > > > > We've been pretty happy with the ASR, especially the models with 4x10G > > on-board. The cost is significantly less than an ME3600, even with a full > > suite of licenses (Advanced IP Metro, all 10G ports, all GE ports), and the > > footprint is much smaller (well, more shallow). > > +1. > > We've started rolling them out since last December, and so far so good. > +1 also, we have several ASR920-24SZ-IM's and 24SZ-M's out in the field and we're very happy with them. Aside from LAG limitations (workaround solution was to not use them :-S), the only other issue I've run into is that default port buffer/queue sizes (48KB?) are rather small. This is a slight annoyance since typical deployment of 920 has at least 2x 10GE feeding the 1GE revenue ports on the box. As I understand, 920 only has 12MB shared buffer space so that probably explains it, but on default queue sizes, almost every 1GE end-user port (no traffic-shaping on user ports, just full-rate 1G port with 10G uplink) excessively collects output drops on practically most trivial IMIX usage. For example, a FreeBSD box sitting with 1GE behind ASR920 just doing wget from a download mirror 50ms away records output drops on 920; whereas a 1GE port off of ASR9K or MX80 would not collect output drops for this type of usage. Sure, it is reasonable to expect an end-user running Speedtest.net or watching Netflix spamming multiple flows to cause output drops, but not on single flow of download. As a workaround, raising the queue-limit to 512 KB per 1G port dramatically gets rid of output drops for trivial traffic. You should still see drops for longhaul bursty traffic overwhelming a 1GE interface when stepping down from 10G uplink, but that's pretty much a reasonable congestion at that point, so dropping packet is better. 512KB seems to be reasonable; 24x1GE * 512KB = 12.2MB, so we don't oversubscribe the global buffer space, and it's roughly ~4ms of output buffer per port. ! class-map match-any cos_all match cos 0 1 2 3 4 5 6 7 policy-map MC_1G_512kb class cos_all bandwidth percent 100 queue-limit 512000 bytes ! James ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations
--- Begin Message --- Not exactly related to BVI, but we have many cases where the ASR920 (different sw releases) stops forwarding/responding-to packets without any apparent trigger and a reboot is required in order to return to normal operation. Installation environment is 10G access rings using mostly EoMPLS/VPLS & various carrier ethernet features. Cisco is still trying to figure out the root cause, unsuccessfully until now. -- Tassos Darin Herteen wrote on 18/1/2016 3:34 μμ: > Thanks everyone for the responses as they have been quite informative. > > QoS strategies/testing was next/last on my list to hammer out this week so > the behavior mentioned below is especially helpful. > > Regards, > > Darin > > > From: cisco-nsp on behalf of James Jun > > Sent: Saturday, January 16, 2016 10:15 AM > To: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations > > On Sat, Jan 16, 2016 at 03:54:01PM +0200, Mark Tinka wrote: >> On 16/Jan/16 13:57, Eric Van Tol wrote: >> >>> We've been pretty happy with the ASR, especially the models with 4x10G >>> on-board. The cost is significantly less than an ME3600, even with a full >>> suite of licenses (Advanced IP Metro, all 10G ports, all GE ports), and the >>> footprint is much smaller (well, more shallow). >> +1. >> >> We've started rolling them out since last December, and so far so good. >> > +1 also, we have several ASR920-24SZ-IM's and 24SZ-M's out in the field and > we're very happy with them. > > Aside from LAG limitations (workaround solution was to not use them :-S), the > only other issue I've run into is that default port buffer/queue sizes > (48KB?) are rather small. This is a slight annoyance since typical > deployment of 920 has at least 2x 10GE feeding the 1GE revenue ports on the > box. As I understand, 920 only has 12MB shared buffer space so that probably > explains it, but on default queue sizes, almost every 1GE end-user port (no > traffic-shaping on user ports, just full-rate 1G port with 10G uplink) > excessively collects output drops on practically most trivial IMIX usage. > > For example, a FreeBSD box sitting with 1GE behind ASR920 just doing wget > from a download mirror 50ms away records output drops on 920; whereas a 1GE > port off of ASR9K or MX80 would not collect output drops for this type of > usage. Sure, it is reasonable to expect an end-user running Speedtest.net or > watching Netflix spamming multiple flows to cause output drops, but not on > single flow of download. > > As a workaround, raising the queue-limit to 512 KB per 1G port dramatically > gets rid of output drops for trivial traffic. You should still see drops for > longhaul bursty traffic overwhelming a 1GE interface when stepping down from > 10G uplink, but that's pretty much a reasonable congestion at that point, so > dropping packet is better. > > 512KB seems to be reasonable; 24x1GE * 512KB = 12.2MB, so we don't > oversubscribe the global buffer space, and it's roughly ~4ms of output buffer > per port. > > ! > class-map match-any cos_all > match cos 0 1 2 3 4 5 6 7 > policy-map MC_1G_512kb > class cos_all > bandwidth percent 100 > queue-limit 512000 bytes > ! > > > James > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > --- End Message --- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] EEM not triggering on IOS-XE 3.11.1S
Hi all,
I'm working on an EEM script which is triggered by an IP SLA down state
on an ASR1000 running IOS-XE 3.11.1S. While the IP SLA entry detects
the state properly, the EEM does not trigger. I'm not finding anything
relevant on the bug toolkit, and I am not seeing anything with my Google-fu.
Here's the configuration:
ip sla 1
icmp-echo 1.1.1.1 source-ip 1.1.1.2
vrf GREEN
tag SITE-DOWN
frequency 5
ip sla schedule 1 life forever start-time now
!
event manager applet SITE-DOWN
description Site 1.1.1.1 is down
event ipsla operation-id 1
action 1.0 syslog priority critical msg "ALERT: Site 1.1.1.1 is down"
!
And here is what I see when I look the status of the IP SLA entry and
the EEM entry. IP SLA looks fine, the EEM isn't triggering despite
being registered.
rtr5#sh ip sla statistics 1
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 11:42:21 EST Mon Jan 18 2016
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 301
Operation time to live: Forever
!
rtr5#sh event manager policy registered
No. Class TypeEvent Type Trap Time Registered
Name
1appletuseripsla Off Mon Jan 18 11:24:46
2016 SITE-DOWN
operation-id {1}
maxrun 20.000
action 1.0 syslog priority critical msg "ALERT: Site 1.1.1.1 is down"
!
rtr5sh event manager statistics policy
AverageMaximum
No. Class Triggered Suppressed Run Time Run Time Name
---
1applet0 0 0.000 0.000
SITE-DOWN
event {} ipsla
Any ideas? I'm at a loss at this point. Upgrading to a newer version
of IOS-XE is in the cards, but won't happen immediately.
Thanks,
-- Stephen
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
Thanks for the response. On 1/18/16, Michele Bergonzoni wrote: >> Using the dispute mechanism included in the IEEE 802.1D-2004 RSTP >> standard... I'm wondering if there's any reason to keep loop guard >> configured > > I think the dispute mechanism can detect unidirectionality where data out of > the designated bridge is lost (which is enough to prevent loops), not the > unidirectionality in the other direction. Which is my point .. or question - enable RSTP on all the switches in the network and you don't need loop guard. Correct? > So the dispute does half of what UDLD does, if I got it right. > > Loop guard is different, it protects only from self-looped ports. My understanding is that it keeps stp blocked ports blocking if the other side stops sending BPDUs: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10596-84.html The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop. and a lot further down loop guard does not work on shared links or in situations where the link has been unidirectional since the link-up. So it seems like loop guard isn't needed if rstp is enabled. > I don't > know if the wording of RSTP are written in a way to protect you from that, > but I'm sure that the original STP standard was written in such a way that > any compliant implementation was unable to block the loop caused by a > self-looped port. If self-looped means the port sends a frame and then receives the same frame, you're right, stp doesn't protect you from that. > Most vendors quietly worked around this, and I don't know if 802.1d > corrected this error in the previous standard. I know that it is very > unlikely to find a switch whose STP can't protect you from such a > situation. > > So I bet that if you use RSTP you can disable loopguard, and if you like > UDLD there is still a reason to use it. No, I don't like UDLD at all - too many bad experiences with it. It was a necessary evil with cat5500s and 100Mb fiber connections, but you don't need UDLD on 1Gb fiber links. Thanks, Lee ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
On 1/18/16, Saku Ytti wrote: > On 18 January 2016 at 10:57, Michele Bergonzoni wrote: > > Hey, > >> So the dispute does half of what UDLD does, if I got it right. > > Ethernet with autonegotiation on should detect unidirectional links > automatically and go down on both ends at RTT/2 delay. I remember 100Mb fiber connections on cat5500s could have unidirectional links, but a quick search gives me this http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.html Most recently, fiber FastEthernet hardware implementations have Far End Fault Indication (FEFI) functions in order to bring the link down on both sides in these situations. so apparently 100Mb fiber doesn't have that problem any more. I don't think 1 or 10Gb fiber ever did.. Lee ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] virtual router on a cat4500
--- Begin Message --- Hi all,I need community feedback about carving a virtual router instance out of Cat4507r+e Sup7-e. Let me explain. I have a pair of said Cat4507 running as distribution switches. I need to add two new routers to terminate MPLS VPN connection. Currently this connection terminates on a firewall, which is not ideal and I would like to change it. Hence, two new routers. And then I thought, why not create a vrf on the catalyst and use it as my CE. All I need is two interfaces, BGP and OSPF. So physically I would still have same Cat4507 but logically it would be [L3 distribution] --- [ firewall ] --- [ mpls ce ]where distribution is the default VRF on the Cat4507 and CE is the new VRF on the same Catalyst.Any reasons why I should not do it?One concern I have is running OSPF between these two VRFs.Any insight would be greatly appreciated.Thanks,Eli--- End Message --- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
On 18 January 2016 at 21:22, Lee wrote: > so apparently 100Mb fiber doesn't have that problem any more. I don't > think 1 or 10Gb fiber ever did.. I believe if you implement autonego, you have to implement RFI. But I'm not 100% sure about that. IEEE 802.3 standard isn't exactly easiest standard to read. But there are quite many surprising goodies in autonego which are usually not known, not just RFI. Autonego can assert when link is configured operationally down, meaning far-end could produce syslog information about link going down, because far end was configured down, which would help lot with troubleshooting, when you can know if far-side is intentionally down or not. My understanding of reading hardware specs is that this feature is even supported in typical PHY, however I've NEVER seen software using this feature. I'd love recommendation on good, modern book about 802.3, with irrelevant bits not addressed, relevant bit discussed and practical view offered on how things are actually implemented in modern, common hardware. So far any book I've read, does not even discuss autonego in satisfactory detail, and I fear what else am I missing due to my unwillingness to weed through 802.3. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
First of all, I have to admit that I confused loop guard with keepalives (the one that errdisables self looped switchport interfaces, and then people do "no keepalives"). Sorry. > So it seems like loop guard isn't needed if rstp is enabled. I have no operational experience with loop guard, but from the description it seems to me that in order to trigger it the interface must become unidirectional *after* link up. Thus, if your Joe Average while troubleshooting does a shut/no shut, he actually gets the loop. So it will protect you on the other unidirectionality side, but not in all possible sequences of events. If you are operating an all-cisco net you might take a look at bridge assurance. I have no operational experience with it as well (apart from disabling it in the nexus), but looks much more like a bidirectional keepalive at the STP layer. It is proprietary and violates the standard as I understand it. > No, I don't like UDLD at all - too many bad experiences with it In fact after what Saku said I would consider trusting the layer 1, but I usually work in a multivendor environment, YMMV. Bye, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Dell VLT to Cisco VSS
Haven't tested it with Dell(force10 stuffs), but have with several other vendors and never had a problem with LAG implementation using the standard so I'd assume it would work but you just never know, different hardware versions, code versions, etc.. bugs.. On 1/18/2016 5:10 AM, Nick Cutting wrote: I am familiar with the theory I was wondering If anyone had actually done this, and if there are any real world caveats. I will be testing this week, however the kit is in Hong Kong, so it's a bit "remote handsy" -Original Message- From: Paul [mailto:p...@gtcomm.net] Sent: 18 January 2016 09:38 To: Nick Cutting; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Dell VLT to Cisco VSS VSS is single control plane so it's all one big chassis, the dell switch would have no idea it isn't connected to a single 6500 and should work without issues. VPC is dual control planes using mLAG which is still transparent to the LAG partner as long as the control protocol is standard (802.1ax w/ LACP for example) there *should* be no issues. stritcly talking about link aggregation here, whatever else you might be running is another story as with everything... test it first :) On 1/18/2016 3:12 AM, Nick Cutting wrote: I'm told Dell VLT is very similar to Nexus VPC. I plan to connect 2 Dell S4820T switches to a VSS'ed 6500 (QSFP+ breakout cables) It would be similar to 2 nexus5/7k's connected to a VSS pair. Or am I a mad man, dancing with inter-vendor prop tech - and would be better off with a normal LACP port channel to one 6500, for each switch? Does anyone have an field experience doing this? Thanks, Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 p...@gtcomm.net http://www.gtcomm.net -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 p...@gtcomm.net http://www.gtcomm.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
On 1/18/16, Saku Ytti wrote: > On 18 January 2016 at 21:22, Lee wrote: >> so apparently 100Mb fiber doesn't have that problem any more. I don't >> think 1 or 10Gb fiber ever did.. > > > I believe if you implement autonego, you have to implement RFI. But > I'm not 100% sure about that. > > IEEE 802.3 standard isn't exactly easiest standard to read. But there > are quite many surprising goodies in autonego which are usually not > known, not just RFI. Autonego can assert when link is configured > operationally down, meaning far-end could produce syslog information > about link going down, because far end was configured down, which > would help lot with troubleshooting, when you can know if far-side is > intentionally down or not. > My understanding of reading hardware specs is that this feature is > even supported in typical PHY, however I've NEVER seen software using > this feature. > > I'd love recommendation on good, modern book about 802.3, with > irrelevant bits not addressed, relevant bit discussed and practical > view offered on how things are actually implemented in modern, common > hardware. So far any book I've read, does not even discuss autonego in > satisfactory detail, and I fear what else am I missing due to my > unwillingness to weed through 802.3. If you get any off-list replies please post a summary. I haven't seen any good books about ethernet in ages, but I haven't really been looking either. Lee ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] virtual router on a cat4500
This should work with no major issues. I would consider making the firewall a layer 3 hop, and use something like VRRP for redundancy and maybe use BGP as the routing protocol... But these are just options. I personally don't like layer 2 firewalls, and there might be design complications due to spanning tree in a redundant mode... Another interesting approach for easy redundancy is to make the pair of 4500's a logical VSS node. https://supportforums.cisco.com/document/124626/virtual-switching-system-vss-configuration-cisco-4500-series-switches If you intend to run OSPF with VRF-lite, you need to enable "capability vrf-lite" http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/20ew/configuration/guide/config/vrf.html HTH Arie On Mon, Jan 18, 2016 at 11:41 AM Eli Kagan via cisco-nsp < cisco-nsp@puck.nether.net> wrote: > Hi all,I need community feedback about carving a virtual router instance > out of Cat4507r+e Sup7-e. Let me explain. I have a pair of said Cat4507 > running as distribution switches. I need to add two new routers to > terminate MPLS VPN connection. Currently this connection terminates on a > firewall, which is not ideal and I would like to change it. Hence, two new > routers. And then I thought, why not create a vrf on the catalyst and use > it as my CE. All I need is two interfaces, BGP and OSPF. So physically I > would still have same Cat4507 but logically it would be [L3 distribution] > --- [ firewall ] --- [ mpls ce ]where distribution is the default VRF on > the Cat4507 and CE is the new VRF on the same Catalyst.Any reasons why I > should not do it?One concern I have is running OSPF between these two > VRFs.Any insight would be greatly appreciated.Thanks,Eli > > > -- Forwarded message -- > From: Eli Kagan via cisco-nsp > To: "cisco-nsp@puck.nether.net" > Cc: > Date: Mon, 18 Jan 2016 14:41:31 -0500 (EST) > Subject: [c-nsp] virtual router on a cat4500 > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
--- Begin Message --- On Mon, Jan 18, 2016 at 3:57 PM, Lee wrote: > > If you get any off-list replies please post a summary. I haven't seen > any good books about ethernet in ages, but I haven't really been > looking either. FWIW: Cisco Live Doc BRKDCT-2333 goes over on BA, UDLD, and auto-neg link failure detection. --- End Message --- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
On 1/18/16, Michele Bergonzoni wrote: >> So it seems like loop guard isn't needed if rstp is enabled. > > I have no operational experience with loop guard, but from the description > it seems to me that in order to trigger it the interface must become > unidirectional *after* link up. Right > Thus, if your Joe Average while > troubleshooting does a shut/no shut, he actually gets the loop. I'm not sure about shut/no shut but a reboot after the link goes unidirectional -- yes, you get a loop. > So it will protect you on the other unidirectionality side, but not in all > possible sequences of events. > > If you are operating an all-cisco net you might take a look at bridge > assurance. I have no operational experience with it as well (apart from > disabling it in the nexus), but looks much more like a bidirectional > keepalive at the STP layer. It is proprietary and violates the standard as I > understand it. Sounds like loop guard except there's now edge, normal and network port types with network ports going into blocking/inconsistent state if they don't see BPDUs. Loop guard puts a port into blocking/inconsistent state if it _stops_ seeing BPDUs on a port. >> No, I don't like UDLD at all - too many bad experiences with it > > In fact after what Saku said I would consider trusting the layer 1, but I > usually work in a multivendor environment, YMMV. Right - it does sound like rstp might be good enuf. Regards, Lee ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EEM not triggering on IOS-XE 3.11.1S
Stephen,
I think you are missing a bit more specifics on your event definition... It
just doesn't match a reaction event from IP SLA.
If you look here:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/eem/command/eem-cr-book/eem-cr-e1.html#wp2241131084
You can see that there are quite a few options to set what exactly you want
to trigger on with regards to IP SLA.
I think you have to define reactions or triggers to match on IP SLA related
events (events being state transitions... up to down, down to up, threshold
limits, etc)
To be honest, I got best results from EEM and IP SLA by EEM matching on the
syslog messages IP SLA produces...
Tnx
Arie
On Mon, Jan 18, 2016 at 8:46 AM Stephen Fulton wrote:
> Hi all,
>
> I'm working on an EEM script which is triggered by an IP SLA down state
> on an ASR1000 running IOS-XE 3.11.1S. While the IP SLA entry detects
> the state properly, the EEM does not trigger. I'm not finding anything
> relevant on the bug toolkit, and I am not seeing anything with my
> Google-fu.
>
> Here's the configuration:
>
> ip sla 1
> icmp-echo 1.1.1.1 source-ip 1.1.1.2
> vrf GREEN
> tag SITE-DOWN
> frequency 5
> ip sla schedule 1 life forever start-time now
> !
> event manager applet SITE-DOWN
> description Site 1.1.1.1 is down
> event ipsla operation-id 1
> action 1.0 syslog priority critical msg "ALERT: Site 1.1.1.1 is down"
> !
>
> And here is what I see when I look the status of the IP SLA entry and
> the EEM entry. IP SLA looks fine, the EEM isn't triggering despite
> being registered.
>
>
> rtr5#sh ip sla statistics 1
> IPSLAs Latest Operation Statistics
>
> IPSLA operation id: 1
> Latest RTT: NoConnection/Busy/Timeout
> Latest operation start time: 11:42:21 EST Mon Jan 18 2016
> Latest operation return code: Timeout
> Number of successes: 0
> Number of failures: 301
> Operation time to live: Forever
> !
> rtr5#sh event manager policy registered
> No. Class TypeEvent Type Trap Time Registered
> Name
> 1appletuseripsla Off Mon Jan 18 11:24:46
> 2016 SITE-DOWN
> operation-id {1}
> maxrun 20.000
> action 1.0 syslog priority critical msg "ALERT: Site 1.1.1.1 is down"
> !
> rtr5sh event manager statistics policy
>
> AverageMaximum
> No. Class Triggered Suppressed Run Time Run Time Name
>
> ---
> 1applet0 0 0.000 0.000
> SITE-DOWN
> event {} ipsla
>
>
> Any ideas? I'm at a loss at this point. Upgrading to a newer version
> of IOS-XE is in the cards, but won't happen immediately.
>
> Thanks,
>
> -- Stephen
> ___
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] loop guard still useful?
Hello list, tl;dr rapid-pvst and autonegotiation will fail you, use UDLD and loop guard. > So I'm wondering if there's any reason to keep loop guard configured > on a switch? > Any current hardware that doesn't support rapidSTP? Some other reason? Whatever is documented on CCO, it will *NOT* prevent layer 2 loops in redundant layer 2 networks in all situations, at least with rapid-pvst. I don't think this is actually implemented in Cisco rapid-pvst, but it may be in MST. > Ethernet with autonegotiation on should detect unidirectional links > automatically and go down on both ends at RTT/2 delay. Ethernet autonegotiation will let you down if the HW or SW fails, you need control plane features to detect unidirectional links and that is also the case for directly connected switches on point-to-point dark-fibers with autonegotiation. > On A-B link, where A=>B works but A<=B does not, A will go down and A > will assert RFI or remote fault indicator on the line. B will receive > this, and go down as well. This assumption breaks when you have some kind of RX or TX stall, which I saw first-hand on a 7600 linecard that suddenly became faulty (and caused a major layer 2 loop because the links had neither UDLD nor loop guard, just plain old rapid-pvst and autonegotiation). Also, all of this is not true if you have EoMPLS, EoSDH, radio-links and other nasty stuff that can suddenly break a single direction and/or both directions without RFI'ing the failure end-to-end. Unless you operate a network exclusively on dark-fibers or passive WDM, you can't assume that everything will go physically down nice and easy. You carriers layer 2 circuit signaled RFI once? That doesn't mean it will continue to do so after (or within) the next maintenance window or if the carrier has a different kind of failure within his network. Would you deploy a routed or MPLS switched network without BFD and without IGP hello timeout, just relying on the interfaces operational state? I can't accept a layer 2 loop because of a single hardware defect. I need the control plane to protect me from that and this is what UDLD and loop guard can do. Thats why: > In fact after what Saku said I would consider trusting the layer 1 You can trust layer 1 so long that you trust that you will never ever have a single hardware defect, a single NP stall or ASIC freeze. Yes, both HW and SW defects can always cause layer 2 problems even with UDLD and loop-guard, but those cases are unrelated to STP and much less common (you can only migrate to layer 3 to eliminate that factor, because neither FabricPath, nor TRILL nor VPLS can fix fundamental layer 2 issues). > No, I don't like UDLD at all - too many bad experiences with it. It > was a necessary evil with cat5500s and 100Mb fiber connections, but > you don't need UDLD on 1Gb fiber links. UDLD had bugs, so did STP, RSTP, MST and even autonegotiation, but if your IOS image is younger than 6 years, those bugs have probably been fixed. > So it seems like loop guard isn't needed if rstp is enabled. I strongly disagree. Another example where loop guard will help you and where both UDLD and RSTP fail is this (no unidirectional link needed for this): Suppose two switches are interconnected with a primary and a backup EoWHATEVER link, and the backup link doesn't signal RFI: - backup links goes down (both directions, not unidirectional) - switches don't see each others BPDUs on the backup link, so they go into forwarding - backup links comes back up, and formes a loop right away (STP status is forwarding on all ports of all links) - when the BPDU is retransmitted (once every 2 seconds in rapid-pvst), there's already a loop on the circuit overloading the links capacity, so that the BPDU that are supposed to fix the problem are lost - because the primary link is also overloaded, BPDU will be lost on that link as well - you have to manually interrupt the loop to restore the service Loop guard will prevent the switch from making the stupid decision to move the port from blocking to forwarding, because it doesn't receive any BPDUs from the other switch anymore (Discarding -> Learning -> Forwarding in rapid-pvst). Instead, it will block the traffic indefinitely until BPDUs arrive again on that Vlan (this is per stp instance, so per vlan in rapid-pvst). One could argue that BPDUs need to be prioritized on all links, including Layer 2 Ethernet poing-to-point links, but thats besides the point, because you would still get a loop in the example mentioned above (until STP converges); also this is often difficult/not doable on layer 2 circuits. >> so apparently 100Mb fiber doesn't have that problem any more. I don't >> think 1 or 10Gb fiber ever did.. > I believe if you implement autonego, you have to implement RFI. But > I'm not 100% sure about that. I can tell that at least single-fiber 100BASE-BX10 (such as these [1]) don't do autonegotiation (in fact unidirectional links in 100BAS
Re: [c-nsp] EEM not triggering on IOS-XE 3.11.1S
Hello! > I'm working on an EEM script which is triggered by an IP SLA down state > on an ASR1000 running IOS-XE 3.11.1S. While the IP SLA entry detects > the state properly, the EEM does not trigger. A state is not an event. A state *change* is an event. So I suspect the script will trigger when the state CHANGES from UP to DOWN, but it won't continuously trigger WHILE the state is DOWN. > rtr5#sh ip sla statistics 1 > IPSLAs Latest Operation Statistics > > IPSLA operation id: 1 > Latest RTT: NoConnection/Busy/Timeout > Latest operation start time: 11:42:21 EST Mon Jan 18 2016 > Latest operation return code: Timeout > Number of successes: 0 > Number of failures: 301 > Operation time to live: Forever 0 successes, so there never was a state change. Bring that sla probe to success at least once, then make it fail. Regards, Lukas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Dell VLT to Cisco VSS
Hi Nick, I haven't done with Cisco VSS, however I have linked a pair of Dell F10 MXL-10/40GbEs with a pair of Cisco Nexus N3Ks On the Cisco Nexus end I used VPC and VLT on the Dell F10 side. Both sides were setup with LACP and worked fine without issues. As far as each side was concerned they were in a port channel with a single switch running LACP Hope that helps. Regards David On 18/01/2016 19:56, Paul wrote: Haven't tested it with Dell(force10 stuffs), but have with several other vendors and never had a problem with LAG implementation using the standard so I'd assume it would work but you just never know, different hardware versions, code versions, etc.. bugs.. On 1/18/2016 5:10 AM, Nick Cutting wrote: I am familiar with the theory I was wondering If anyone had actually done this, and if there are any real world caveats. I will be testing this week, however the kit is in Hong Kong, so it's a bit "remote handsy" -Original Message- From: Paul [mailto:p...@gtcomm.net] Sent: 18 January 2016 09:38 To: Nick Cutting; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Dell VLT to Cisco VSS VSS is single control plane so it's all one big chassis, the dell switch would have no idea it isn't connected to a single 6500 and should work without issues. VPC is dual control planes using mLAG which is still transparent to the LAG partner as long as the control protocol is standard (802.1ax w/ LACP for example) there *should* be no issues. stritcly talking about link aggregation here, whatever else you might be running is another story as with everything... test it first :) On 1/18/2016 3:12 AM, Nick Cutting wrote: I'm told Dell VLT is very similar to Nexus VPC. I plan to connect 2 Dell S4820T switches to a VSS'ed 6500 (QSFP+ breakout cables) It would be similar to 2 nexus5/7k's connected to a VSS pair. Or am I a mad man, dancing with inter-vendor prop tech - and would be better off with a normal LACP port channel to one 6500, for each switch? Does anyone have an field experience doing this? Thanks, Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 p...@gtcomm.net http://www.gtcomm.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations
Hello, Irrelevant of BVI feature, one another limitation also is the lack of support of mVPN (Draft-rosen model) and only mldp feature is supported at least prior to the IOS 3.17. Although, 3.17 CCO says that it supports the feature, during testing, there as some issues, such as no pim neighborship over VRF which seems the ASR920 cannot perform neighborship with the other PE, although the other PEs see the ASR920 as a neighbor. The above, can be "fix" with the selection of SDM video profile, that enables the neighborship over VRF to be working does come up, but no mcast traffic is flowing. We have an open case with TAC for this. Also in 3.17 the IPv4 scale witth SDP IP profile is increased from 20k to 24k but it decreases some others eg. VPLS instances etc. Michalis Bersimis ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations
On 19/Jan/16 08:22, michalis.bersi...@hq.cyta.gr wrote: > Hello, > > Irrelevant of BVI feature, one another limitation also is the lack of support > of mVPN (Draft-rosen model) and only mldp feature is supported at least prior > to the IOS 3.17. Although, 3.17 CCO says that it supports the feature, during > testing, there as some issues, such as no pim neighborship over VRF which > seems the ASR920 cannot perform neighborship with the other PE, although the > other PEs see the ASR920 as a neighbor. > > The above, can be "fix" with the selection of SDM video profile, that > enables the neighborship over VRF to be working does come up, but no mcast > traffic is flowing. We have an open case with TAC for this. Also in 3.17 the > IPv4 scale witth SDP IP profile is increased from 20k to 24k but it decreases > some others eg. VPLS instances etc. The ASR920 supports NG-MVPN, and we tested this. Are you testing NG-MVPN or Rosen? Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations
I am testing draft rosen model, as stated here for IOS XE 3.17 (http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes/new_features.html#pgfId-1085169 ) Michalis -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Tuesday, January 19, 2016 8:36 AM To: Μπερσίμης Μιχάλης (900356); cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations On 19/Jan/16 08:22, michalis.bersi...@hq.cyta.gr wrote: > Hello, > > Irrelevant of BVI feature, one another limitation also is the lack of support > of mVPN (Draft-rosen model) and only mldp feature is supported at least prior > to the IOS 3.17. Although, 3.17 CCO says that it supports the feature, during > testing, there as some issues, such as no pim neighborship over VRF which > seems the ASR920 cannot perform neighborship with the other PE, although the > other PEs see the ASR920 as a neighbor. > > The above, can be "fix" with the selection of SDM video profile, that > enables the neighborship over VRF to be working does come up, but no mcast > traffic is flowing. We have an open case with TAC for this. Also in 3.17 the > IPv4 scale witth SDP IP profile is increased from 20k to 24k but it decreases > some others eg. VPLS instances etc. The ASR920 supports NG-MVPN, and we tested this. Are you testing NG-MVPN or Rosen? Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASR920-24SZ-IM BVI Feature Limitations
On 19/Jan/16 08:40, michalis.bersi...@hq.cyta.gr wrote: > I am testing draft rosen model, as stated here for IOS XE 3.17 > (http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes/new_features.html#pgfId-1085169 > ) Waris and others might want to comment, but I have a feeling Rosen might be broken on the ASR920, in favour of NG-MVPN. I could be wrong... Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
