Re: [c-nsp] IOS-XE?
--- Begin Message --- On 10/11/2020 10:33 am, Scott Voll wrote: 16.9.6 or 16.12.4? and Why? Any issues seen in the 16.12 line? I've seen some unexplained reboots in the 16.9.5 train that TAC can't explain so need to upgrade. 16.9.6 is the Starred release. I've not been impressed with the whole 16.9.x train over the last two years so really thinking hard about 16.12.4. Thanks Scott You haven't mentioned which platform specifically. However 16.9 has been announced EoL and reaches End of Software Maintenance in January so a move to 16.12 is probably the logical next step. https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/eos-eol-notice-c51-742700.html In other words, likely no more fixes in 16.9 now anyway. Reuben --- 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] Devil's Advocate - Segment Routing, Why?
--- Begin Message --- On 21/06/2020 7:30 am, Mark Tinka wrote: Personally I would only recommend Meraki for a small business with very basic and well defined requirements. Even then once you factor in the cost of licensing + hardware and compare it to a low end Cisco Enterprise product that does not have said limitations, you may find the cost is about the same over 3 or more years. Sounds like pfSense might be a better option :-). If I can summarize it in one sentence, is Meraki meant to be Cisco's SD-WAN job? Mark. No. Meraki is their "Small Enterprise" product line. The SDWAN capability is there in Meraki MX - yes - but it is very basic. The full SDWAN solution is what was Viptela, which is now being baked into mainstream IOS XE. It's very good, but very complex, very capable, runs on existing IOS-XE devices, requires multiple VMs and a lot of infrastructure to use, and of course very expensive. Unfortunately there's no middle ground Cisco SDWAN solution; you're either going big (Viptela) or small (Meraki) and with matching pocket depths. Reuben --- 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] Devil's Advocate - Segment Routing, Why?
--- Begin Message --- On 20/06/2020 4:14 pm, c...@marenda.net wrote: I've been told Merak is very nice... if all you're interested in is "sell to Enterprise customers and make lots of cash". We asked the sales-person weather that meraki devices can handle ipv6 (as customer traffic) and for the cloudy management access (in an ipv4 free world) But they did not know this, told us they will ask, but we did not get any answer yet ... Meraki doesn't currently support IPv6 in any way, shape or form. Some other things you'll find missing in Meraki products: - Zone based firewalls - Meraki MX doesn't do zones - Routing protocols for all but the most absolutely basic use cases - Client side VPN. More specifically it does PPTP but not so many people are sold on the security and NAT problems that come with PPTP - Modern crypto - IPSec Auth is limited to MD5/SHA1 for example. - Any sort of xDSL, they only have Ethernet models. If you need xDSL you'll need a bridge modem for the carriage circuit - Extremely limited NAT capabilities, no ALG, no ability to disable NAT between eg WAN and LAN ports which means it's almost useless for an MPLS circuit. The lack of control over NAT also makes it impossible to run a publically addressable DMZ - SSL decryption which makes content filtering a bit less useful - Cellular is limited to not all 4G bands (notably does not support 700MHz here in Australia) and Cell backup is not supported in an HA setup And dare I say it, Segment Routing and MPLS definitely are not part of the featureset ;) There are many good things about Meraki (eg dashboard, autovpn, updates, ease of provisioning), but in my recent experience with MX/MS products you have to spend as much if not more time working out what Meraki products *can not* do as what they *can* do - and know the product limitations before you design and deploy not during (don't assume anything). Personally I would only recommend Meraki for a small business with very basic and well defined requirements. Even then once you factor in the cost of licensing + hardware and compare it to a low end Cisco Enterprise product that does not have said limitations, you may find the cost is about the same over 3 or more years. Reuben --- 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] ASR920 is a ticking timebomb (CSCvk35460)
--- Begin Message --- On 24/01/2019 6:23 am, Giles Coochey wrote: I think the tack the OP was meant to imply that Cisco Bughunt for issues leaves a lot to be desired, with terse messages attached to bugs, incomplete versions affected, etc... The thing that sends me off the deep end with bugs like this is when they are marked with a status of "Terminated" especially if they have a high severity. Perhaps it is just a case of a bad choice of words, but that reads to me the effect of "we have made a conscious decision to not fix this bug" and implies that it's most likely a waste of time opening a TAC case about it. Reuben --- 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] Multicast within VLAN on Nexus7K over vPC
--- Begin Message --- Hi, Have you read the Best Pratices guide: http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf Specifically the section about vPC multicast? Reuben On 20/10/2016 9:27 PM, Yham wrote: Hi All, I have two cisco nexus 7K as core switches and two cisco 4500 as distribution/access switches. Nexus switches have vPC with each downstream 4500 switch and there is no connection between 4500 switch. Vlan100 exist on all four switches and all devices part of this vlan are connected to 4500 switches. I believe this is pretty standard design. Though vlan 100 has regular users and services that communicate over unicast but there are some devices that need to send and receive multicast. Both Multicast sender and receivers are in same vlan but receivers are spread across both 4500 switches. In diagram (no link below), receivers connected to switch 4K-1 (where source is connected) can receive the multicast stream but receivers connected to 4K-2 don't see anything. I believe its expected behavior due to IGMP snooping enabled on switches by default but i am trying to figure out how to make receivers on other switch able to get multicast stream. I did some research and found different ways but unfortunately i don't have non-production devices to test which one actually works. Here what i found 1) configuring IGMP querier for vlan 100 on all four switches 2) only enable 'ip pim sparse-mode' under SVIs (interface vlan100) at N7K-01 & N7K-02 3) disable IGMP snooping for vlan 100 on all four switches (which i don't think a right solution) Topology Diagram https://s22.postimg.org/3tsnta4s1/topology.png Your any help will be highly appreciated. Thanks YH ___ 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/
Re: [c-nsp] ASR920 "console" port....ugh
--- Begin Message --- On 16/01/2016 10:43 PM, Gert Doering wrote: Hi, On Sat, Jan 16, 2016 at 09:07:00AM +, CiscoNSP List wrote: Cheers for the replies guys - I'm really interested in the rational behind moving to USB from traditional RJ45 portsrealestate?boggles the mind. Well, if done properly, it's actually easier to the admins than having to carry around a usb-to-serial adapter all the time (since almost all current machines do not have a built-in serial port anymore). "properly" implies something else, though, like: - the "real" USB console has a mini-b or micro-B plug, so a bog-standard USB cable otherwise used to charge your mobile will do the job (as for driver installation, well, if you can find a USB-to-serial chip that windows supports by default, even better - but otherwise, unavoidable misery. On Linux, it just works with the common chipsets) USB console is a good idea but the execution of this changeover was botched. As of today we have most routers and switches rolling out with USB serial ports and what appears to be USB->Serial chips onboard to do the translation. This required only a standard mini-b to USB cable to work. Big tick there. The hardware teams did a good job on their part of the job and the implementation of hardware is usually good. But where Cisco seriously lost all credibility with this was the software/driver support. As of today: Windows 7 driver - available on CCO and works OK Windows 8 driver - never supported Windows 8.1 driver - never supported Windows 10 driver - seems to be built into Windows 10 Note that the Windows 7 driver did not work on Windows 8. And in practice on every laptop I tried it on the driver got in a messed up loop whereby it created 255 COM ports in Windows before deciding that there were none left. This left a right royal mess in device manager to clean up. At least a part of this bug was being tracked under CSCuh52585 which has never been made customer visible. There was some comment on this in: https://supportforums.cisco.com/discussion/11996231/usb-console-drivers-windows-8 In the end I just went and bought a decent dongle that did have good driver support and haven't had to deal with the problem since. There are still some routers which don't have USB console ports such as the C819G's though. So it's not quite yet ubiquitous. But that's the exception not the norm. Reuben --- 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] switch for SAN
--- Begin Message --- On 9/01/2016 3:53 AM, Chuck Church wrote: What are your needs? 10GE? Layer 3 capable? There are a lot of small Cisco switches. The main difference between the 3650 and 3850 is the wireless controller thing to my knowledge. Not really beneficial to a SAN switch. Since Cisco tends to not publish buffer sizes for a lot of these small switches, it's a bit of a guess. The 2960X are decent for a lot of purposes, maybe SAN. That's just a guess though. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3650-series-switches/qa_c67-729531.html As of 3.7.1E the 3650 supports the same number of AP's (50) as the 3850. If you only need a standalone switch or one with limited stacking capabilities and no need to change uplink modules, then the 3650 is much better value than a 3850. Definitely more suited to the task than a 2960X. Reuben --- 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] Multihoming
--- Begin Message --- On 1/09/2015 6:43 AM, Justin M. Streiner wrote: On Mon, 31 Aug 2015, Jason Berenson wrote: Was interested in getting any pointers anyone might have about multihoming. I've got an ASN and am working on a /24 from ARIN now. I was thinking about a pair of Cisco 3560's one for each provider and I was going to take default routes from each, one with a higher metric and announce my prefix over the primary link and pad the secondary link. No customer or full tables needed. I was thinking about vlan'ing each switch into half public half private side also. Any pointers or tips or recommendations would be greatly appreciated. It's been a while since doing this type of stuff. You might need to get your IPv4 space from one of your upstream providers. As far as ARIN is concerned, that well is dry. You will also want to start giving serious thought to IPv6. I don't know how well 3560s handle BGP, but if you're just taking default routes from your upstreams, the resource needs are pretty light. As the other person who responded mentioned - 4-byte ASNs could be an issue as well. 3560's handle 4 byte ASNs just fine provided: - You have sufficient flash. 4 byte ASN support in the Catalyst platforms was introduced in 15.2(1)E so this is the absolute minimum version you will need to run - and this image (in fact anything newer than 12.2(55)SE) requires 32M flash. - You have the IPSERVICES image/license as BGP is not supported in IPBASE. As you're only handling a handful of prefixes if you meet the requirements above you should be fine. Reuben --- 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] ME3600 migration to something with more 10 gig ports
---BeginMessage--- On 14/07/2015 9:34 PM, Gert Doering wrote: Hi, On Tue, Jul 14, 2015 at 11:06:37AM +, Adam Vitkovsky wrote: Or from a different angle why would they bother designing test procedure that tests every possible permutation making sure the box is error free if no one is using certain config combinations. The live audience makes sure they only need to deal with the widely used features and not waste money on fixing features that almost no one actually uses. While that is a bit cynical, it would actually work *IF* they gave TAC enough developer resources to then fix anything that comes up in reasonably short time *AND* add regression tests to their setup to ensure that they are not breaking this (obviously important) feature again with new code... The not enough support from dev is one of my major gripes with TAC - these folks are friendly and helpful, but if they are left dangling without backend support, there's not much they can do. Unfortunately I have to agree with this about insufficient dev resources as well - and the situation appears worse than I think it has ever been. I have 6 TAC cases open at the moment - some have been open 6+ months, practically all are awaiting a response from engineers who have contacted DE to either fix a bug or respond with where to go next given a collection of outputs that clearly illustrate problems and that the engineer needs to escalate. Most have been waiting a double digit number of weeks (not days) for responses from DE. Unfortunately this means that the engineer who assisted is probably going to be lumped with a very poor survey score for Timely Resolution even though it may not be his/her fault :-( Reuben ---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] ASR920 - ISR4431
---BeginMessage--- On 3/06/2015 7:59 PM, Nick Cutting wrote: Thank you for the suggestion - I've been using these in the lab quite a bit lately as I've lost faith in GNS3 (watching it fall apart when showing clients proof of concept - this won't happen on the real kit..) , however I am a little scared to run the internet vlan(s) into the esx estate at this time, there is a rather old fashioned security policy in place. Perhaps if we had dedicated hosts I think we can pick up 2 of the new little 3560's-CX's for £~5k each with ip services netflow - just hoping 11k prefixes is enough. It probably won't be. Here's from a WS-C3560CX-12PD-S: switch-2#show sdm prefer The current template is default template. The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 16K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 5K number of directly-connected IPv4 hosts: 4K number of indirect IPv4 routes: 1K number of IPv6 multicast groups: 1K number of IPv6 unicast routes: 5K number of directly-connected IPv6 addresses: 4K number of indirect IPv6 unicast routes: 1K number of IPv4 policy based routing aces: 0.25K number of IPv4/MAC qos aces: 0.375k number of IPv4/MAC security aces: 0.375k number of IPv6 policy based routing aces: 0.25K number of IPv6 qos aces: 0.25K number of IPv6 security aces: 0.375k switch-2# There's only one SDM template at this stage. A 3650 switch (not a 3560) would be sufficient though - think this is as low as you could go while fitting that many prefixes in tcam. Aside from this I'm quite disappointed with how the ISR 4300/G3 platform has been put together in so far as the licensing and throughput restrictions. It seems to me that it's a big step backwards from the ISR G2 platform, and the upgrade from G2 to G3 is a hard sell. I would be most interested to see how the sales figures are looking...and other peoples thoughts on this. Reuben ---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] Cisco Security Advisory: Cisco IOS Software RSVP Vulnerability
Another similar change I've noticed recently in so far as release notes and details of changes go is this - release notes for 15.1(4)M9: http://www.cisco.com/c/en/us/td/docs/ios/15_1/release/notes/15_1m_and_t/151-4MCAVS.html#pgfId-62747 All resolved bugs for this release are available in the Cisco Bug Search Tool through the fixed bug search. For that release the release notes just point to the Bug Search Tool on CCO. Which for me I find an abominable tool in all browsers - it's slow, really kills performance on all other open browser windows as well and the Load Saved Search function is just unusable - it tries to emulate real menus but fails badly (things need to be double clicked to work, it doesn't work well if you have folders and bugs saved in any sort of hierarchy for example). I hope that the pointing to BST for details at the expense of listed summaries is not a strategy that is going to be deployed across the board for other release notes. There's a lot to be said for being able to quickly skim through the open P1 and P2 caveats of a new release in a plain HTML page. tongue-in-cheek It's probably a good candidate function/feature that could be replaced by another classy Java/JRE app on the CCO website ;) /tongue-in-cheek Reuben On 25/09/2014 11:18 PM, Clay Seaman-Kossmeyer (ckossmey) wrote: Hi Folks - We definitely appreciate the feedback and will put some thought into how we can satisfy this request. Behind the scenes, we’ve moved to a very different infrastructure for compiling vulnerability information for each IOS release, which allows us to greatly improve our ability to show granular, real-time exposure vs. a 6-month static snapshot. The compromise that we always struggled with in the tables was the lack of release-level granularity, especially given the depth of branching in some (many) IOS trains. We’ll put our heads together and kick around some ideas for how we can provide some quick-reference, summary information, though it’s unlikely we’ll be able to do anything in short order for this bundle. Thanks again for the feedback. Clay On Sep 25, 2014, at 7:50 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Thu, Sep 25, 2014 at 11:35:01AM +0200, Peter Rathlev wrote: IOS Software Checker is a nice tool, do keep it. But for the helicopter view the comprehensive list is a really great help. This! +1 ___ 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/
