The New Routers Are Here! Cisco Catalyst 8000 Series

Justin Hippen on 10/26/2020

The New Routers Are Here!
Cisco announced the new Cisco Catalyst 8000 Series Routers Edge Platforms last week, so lets go over what was announced and what I expect to see in the future.

(Full Disclosure: I received a pre-briefing on this as part of being a Cisco Champion. I received no compensation, monetary or otherwise, to write this article. My viewpoints are my own and not that of Cisco’s marketing department.)

The Announcement

Over the past few years Cisco has released new small office/home office routers (ISR 1100) and a few new higher-end large campus/data center/aggregation routers (ASR 1000) but the mid-performance branch routers have been essentially the same since the introduction of the ISR 4000 series in 2013 & 2014. These routers have performed admirably over the past seven years, surviving the IWAN faux pas, and gaining SD-WAN capabilities from the Viptela acquisition. But there has been a bit of a performance gap between the higher-end 4000s (500Mb to 2Gb) and the non-modular ASR 1000s (5+Gb), especially when you start looking at SD-WAN encrypted throughput and QoS/DPI/Security. The Catalyst 8000 Edge Platforms now has filled that gap (and then some).

The new hotness

  • Catalyst 8300 – Intel x86 based 1 & 2RU modular platform. There are currently four models available:
    • C8300-1N1S-6T – 1RU, 1 NIM module slot, 1 SM module slot, 1 PIM module slot (for 4G/5G wireless WAN), and 6x 1GbE interfaces – Up to 1.9 Gbps SD-WAN throughput
    • C8300-1N1S-4T2X – 1RU, 1 NIM module slot, 1 SM module slot, 1 PIM module slot, and 4x 1GbE interfaces + 2x 10GbE interfaces – Up to 15 Gbps SD-WAN throughput
    • C8300-2N2S-6T – 2RU, 2 NIM module slots, 2 SM module slots, 1 PIM module slot, and 6x 1GbE interfaces – Up to 1.9 Gbps SD-WAN throughput
    • C8300-2N2S-4T2X – 2RU, 2 NIM module slots, 2 SM module slots, 1 PIM module slot, and 4x 1GbE interfaces + 2x 10GbE interfaces – Up to 18 Gbps SD-WAN throughput
  • Catalyst 8500 – Cisco QFP 3.0 ASIC based 1RU fixed platform. The QFP 3.0 is an evolution of the ASIC used in the ASR 1000 line. There are currently two models available:
    • C8500-12X – 1RU, with 12x 1/10GbE interfaces – Up to 40 Gbps SD-WAN throughput OR 118 Gbps of standard forwarding throughput
    • C8500-12X4QC – 1RU, with 12x 1/10GbE interfaces, 2x 40/100GbE interfaces, and 2x 40GbE interfaces – Up to 68 Gbps SD-WAN throughput OR 197 Gbps of standard forwarding throughput
  • Catalyst 8000V – A virtual router platform that is an evolution of both the CSR 1000v and the ISRv network functions virtualization (NFV) offerings. (Note: I still don’t understand why Cisco had both the CSR1kv and the ISRv. Seems like duplicated effort.) Data sheets state that the Cat8kv can be licensed for over 10Gbps of SD-WAN throughput. It will be available on AWS, Azure, and GCP public clouds as well as ESXi and KVM for on-prem.

Other Details

Platform?!?

If you talk to anyone at Cisco, they are very quick to point out that the Catalyst 8000 isn’t just a router, it’s a “platform”. This kinda makes sense when you dig into it. These devices have powerful CPUs (either Intel x86 or custom Cisco QFP) which enable them to do more than route data or voice (yes, UC gurus, the Catalyst 8000 can do that too). They can host containerized functions on board just like the Catalyst 9000 switches and some of the later ISRs. I expect to see the Wireshark container and a Snort IDS/IPS/FW container when they ship. I’m also waiting to see if they announce a ThousandEyes container or integration now that their acquisition has completed. The new switch module for the Catalyst 8300 has the same UADP ASICs as the Catalyst 9300 switches, so basically you have a branch-in-a-box.

Catalyst? I thought those were switches…

Yes, Timmy. Cisco marketing & branding got their way again. Just like they did with the newest generation of Cisco wireless, they have decided to swap the ISR/ASR name for Catalyst. The word on the street is that it is to create a “unified branding” across the enterprise portfolio. I don’t care what it’s called as long as it works.

Didn’t I read about some new Cisco 8000 routers last year?

You sure did Timmy. Cisco has been on a kick over the past few years naming multiple product lines with the same numeric identifier, mostly with 9000 (Nexus 9000, Catalyst 9000, ASR 9000, MDS 9000,…). Now they are starting with the 8s. It might be confusing briefly, but the Cisco 8000 routers are big Service Provider routers that cost the same as a small mansion (depending on your market). The Catalyst 8000s are priced, well, I don’t really know, but I would expect them to be in line with the ISR 4000s and the ASR 1000s.

Do I have to buy a subscription license for this?

Timmy, you will be (probably) unhappy to know that, yes, Cisco is requiring you to buy a subscription license to go along with the hardware. The license is broken up into 3 feature tiers and 4 bandwidth tiers. Cisco has at least simplified the bandwidth licensing so that is tiered instead of 7 or 8 bandwidth values.

So are the ISR 4000s & ASR 1000s going away?

Officially, no. There are no routers being retired with this announcement as the Catalyst 8000s are “complimenting” the ISRs and ASRs. There is a slide and a translation from the Cisco Schweiz Blog that shows that the Cat8300 is a replacement for the ISR 4431 & 4451 while the Cat8500 is a replacement for the ASR 1001-HX & 1002-HX.

German

Catalyst 8000V: Virtueller Software Router und Ersatz für den CSR1000v sowie ISRv

Catalyst 8300: CPU basierendes Gerät als Ersatz der ISR 4400 Modelle

Catalyst 8500: QFP basierendes Gerät als Ersatz der ASR-1000HX Modelle

https://gblogs.cisco.com/ch-de/2020/10/21/es-ist-zeit-fuer-etwas-neues-die-catalyst-8000-router-sind-da/

English Translation

Catalyst 8000V: Virtual software router and replacement for the CSR1000v and ISRv

Catalyst 8300: CPU based device to replace the ISR 4400 models

Catalyst 8500: QFP based device to replace the ASR-1000HX models

https://translate.google.com/translate?hl=en&tab=TT&sl=auto&tl=en&u=https%3A%2F%2Fgblogs.cisco.com%2Fch-de%2F2020%2F10%2F21%2Fes-ist-zeit-fuer-etwas-neues-die-catalyst-8000-router-sind-da%2F

I do believe that in addition to the eventual replacement of the ISR 4000s and ASR 1000s, the Catalyst 8000s also set up the end of the classic vEdge platforms. EoL/EoS has already been announced for the vEdge 100/100b/100m/1000 which leaves the vEdge 2000 & 5000, which are easily replaced with the Catalyst 8300/8500.

What do I expect to see in the future

(Note: I have no inside information on any future platforms or devices. These are just my deductions based off of past performance and a couple of public leaks.)

While this is an exciting launch, there are a few things (and numbers) missing. We don’t have any replacements for the ISR 42xx, 43xx, or 4461 routers. Nor do we have a replacement for the modular ASR 1000 routers. If I take a hint from the Catalyst 9000 line, this is what I would predict.

  • Catalyst 8200 – A replacement for the lower-end ISR 42xx & 43xx routers (sooner than later)
  • Catalyst 8300 – More SKUs to replace the rest of the ISR 43xx & 44xx routers (sooner than later)
  • Catalyst 8500 – More SKUs
  • Catalyst 8600 – A chassis based solution to replace the modular ASR 1000s (probably at least a couple of years away)

The little insight I have on this is from the publicly accessable CISCO-PRODUCTS-MIB.my and CISCO-ENTITY-VENDORTYPE-OID-MIB.my SNMP MIB files. Here is what I was able to find:

  • C8200-1N-4T (A replacement for some of the 4300s?)
    • 4xGE, 1 NIM, 1PIM, 8Core, 8G FLASH, 8G DRAM
    • (ENTITY line 2018; PRODUCTS line 2645)
  • C8200-L-4G (No NIM slot. A replacement for the 4221/4321?)
    • Nobelium – AMD, 4xGE, 1PIM, 8Core, 8G FLASH, 8G DRAM
    • (ENTITY line 2019)
  • C8500L-8G4X (Less interfaces than the other Cat8500s but more than the 8300s. Possible replacement for the 4461?)
    • Fugazi, 4x10GE SFP+, 8x1GE SFP, 12Core, 16G FLASH, 16G DRAM
    • (ENTITY line 2026; PRODUCTS line 2651)

Conclusions

While I might not be a huge fan of naming everything “Catalyst” or reusing the same numbering scheme on multiple similar products, I am actually looking forward to getting my hands on some of the new Catalyst 8000 routers edge platforms to put them through their paces.

What the… : Weirdness/Oddities Encountered in the Past Week(ish) #1

Justin Hippen on 01/25/2020

I have decided to start writing down some of the weird networking things I encounter in my day job. I am hoping that it helps others fix issues in their own environments; or at least give you a chuckle. 🙂

/31 Gotchas on Cisco\Viptela Equipment

  • Weirdness: I ran into this last fall & then promptly forgot about it. /31 subnet masks are supported on the Cisco (formerly Viptela) SD-WAN gear and have worked great for me for the past 18 months. Except if you are using vEdge 5000s. vManage will let you configure the interfaces with a /31 and the devices will accept the config, but they will not pass any traffic.
  • Investigation: I haven’t seen this issue on vEdge 100s, 1000s, or any converted ISRs. Just on vEdge 5000s
  • Fix: Changed the subnets to /30s and everything works. I can ping it now, so it has to be rock solid…

Routing issues for specific PI IPv4 address space

  • Weirdness: Thanks to a predecessor in the 90s at $DayJob, we have a good amount of provider independent IPv4 space (especially for a mid-sized company). We ran into an issue where some users trying to access a SaaS application from one location (and one PI block) would get constant timeouts. If those same users used their cell phones, the application responded immediately. To cause further confusion, users at a second location (and second PI block) could access the application without issue.
  • Investigation: Using WinMTR we tracked the path from our location (in the USA) to the SaaS application (hosted in Sweden). It appeared that somewhere in the UK we started having 50-80% packet loss. Performing this same test from the second location (and the adjoining /24 block), we did not see the same issue.
  • Fix (sorta): Using a centralized traffic data policy on our Cisco SD-WAN equipment, we took the SaaS provider’s /17 network and set it to route out of a different Internet circuit at the first location, which was not using our PI address space. As soon as this policy was pushed to our vSmart(s) and vEdge(s), the webpage started responding immediately.
vManage Data Policy Rule
vManage Data Policy Rule

IP Phones dropping out

  • Weirdness: Two call center employees reported that the screens on their Cisco IP Phone went dark momentarily and they were kicked out of Cisco Finesse multiple times over a 2 hour period.
  • Investigation: Looking at the switch logs, the two associated switch ports did not log any up/down events, nor did they log a PoE removal/granted. Also, the two switch ports were on separate switches in the switch stack. Talking to the users, the phones were not going through a full reboot process. The screens were just going dark and then coming back. For one user, we replaced their patch cable & then complete phone, but they still had the issue. But, while going through the switch logs, we came across another switch port; again, on an entirely different switch in the stack; that was logging frequent PoE events.
14:37:12.163 UTC: %ILPOWER-5-POWER_GRANTED: Interface Gi3/0/27: Power granted (3750SWITCH-3)
14:37:12.691 UTC: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi3/0/27: PD removed (3750SWITCH-3)
14:37:28.778 UTC: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi3/0/27: PD removed (3750SWITCH-3)
14:37:45.254 UTC: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi3/0/27: PD removed (3750SWITCH-3)
14:38:01.553 UTC: %ILPOWER-5-POWER_GRANTED: Interface Gi3/0/27: Power granted (3750SWITCH-3)
14:38:01.905 UTC: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi3/0/27: PD removed (3750SWITCH-3)
14:38:18.462 UTC: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi3/0/27: PD removed (3750SWITCH-3)
14:38:34.702 UTC: %ILPOWER-5-POWER_GRANTED: Interface Gi3/0/27: Power granted (3750SWITCH-3)
14:38:34.828 UTC: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi3/0/27: PD removed (3750SWITCH-3)
14:38:50.791 UTC: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi3/0/27: PD removed (3750SWITCH-3)
  • Fix: We went to the desk that was logging the PoE events & there we found that the user had NO IP PHONE (DUN, DUN, DUUUUNNN). They were using a softphone on their PC and their PC was plugged into the logged port. They were also using a 25 foot patch cable to plug their PC in the 5 feet they needed to reach the wall port. We replaced the cable with a 7 foot patch cable and the switch stopped logging the PoE events & the other users stopped reporting the issues with their phones.

Viptela 18.4/Cisco IOS-XE SD-WAN 16.10 Released

Justin Hippen on 01/01/2019

Happy New Year!!!

A little news that was missed in the pre-holiday change freeze was that Cisco released a new version of their SD-WAN software.

Version 18.4 for the vManage/vBond/vSmart & vEdge devices and the corresponding IOS-XE SD-WAN version 16.10 was released on December 20th, 2018. This is a “short-term” support release that greatly expands the SD-WAN support on Cisco ISR & ASR hardware, along with a bunch of new security features.

Up until this point, if you wanted to run the SD-WAN IOS image on your existing/new ISR & ASRs you were limited to:

  • ASR 1001-X & HX
  • ASR 1002-X & HX
  • ISR 1111-8P and the LTE EA & LA variants
  • ISR 1117-4P LTE EA & LA variants
  • ISR 4221, 4321, 4331, 4351
  • ENCS 5412 running ISRv

Highlights in 18.4/16.10

Now with 18.4/16.10 IOS-XE support expands to:

  • CSR 1000v (Yay!)
  • Nearly all of the rest of the ISR 1100s (BTW, do we really need all of these different SKUs???)
    • 1101-4P
    • 1111-4P and the LTE EA & LA variants
    • 1116-4P and the LTE EA variant
    • 1117-4PM & 1117-4P MLTE EA
    • 1111X-8P
    • 1111-8PWx with integrated WiFi
    • 1111-8PLTEEAWx with integrated WiFi and LTE
  • ENCS 5104, 5406, 5408

Addtional Software features

The most exciting feature for me is that this release also adds some of the road-mapped security features that Cisco announced at Networking Field Day 19 (#NFD19 YouTube recording) including firewall, IPS, and OpenDNS Umbrella support.

Second, it also adds additional IPv6/Dual-Stack support on the service side of the SD-WAN. Previously, IPv6 support was limited to the WAN side of the platform. Unfortunately, this only applies to the IOS-XE platforms, not the Viptela vEdges. I reached out to Viptela vTAC to see if full IPv6 support was slated for the vEdges but was informed that it is NOT currently road-mapped to be ported over. (I have an upcoming rant on that one.)

As always, there are a bunch of other features in this release, but hit up the release notes for more details.

Closing Thoughts

My personal warning is that 18.4 is a short-term support release only & you cannot downgrade your vSmart/vBond/vManage back to a previous release if it is unstable.

I’m currently weighing out the positives & negatives of upgrading to this release.

I do have a couple of spare ISR 1111-8PWBs on my desk…
I could also spin up some CSR 1000v instances for testing…
I wonder if my Cisco/Viptela SEs can float me some temporary licenses…
😉

Runt Frame – Firepower Quick Tip – Management Interface & SNMP/Syslog

Justin Hippen on 12/13/2018

Runt frames are going to be some quick tips that I run into in my day to day life as a network engineer.

So, lets say that your preparing to migrate your firewalls to some shiny new ASAs or Firepowers running FTD mode, even though the Internet has tried to warn you off… (Reddit – Firepower Rant Part 1 & Reddit – Firepower Rant Part 2)

As part of your initial setup, you start to configure SNMP & Syslog, but to your horror you find that the system does not allow you to source the traffic from the management interface! It wants you to use a standard data interface, but you can’t activate any of those until you’re ready to complete the migration!

There is a workaround. But it’s not the cleanest.

You can use the “diagnostic” interface. This is a logical interface that shares the the physical management interface (at least on the ASA 5500-Xs). So put an IP address on the diagnostic interface (must be the same subnet used on the management interface), and then manually add the diagnostic interface to the SNMP settings under Platform Settings in FMC.

“But Justin,” you say, “It still doesn’t work!”

Yep. I ran into that myself. The diagnostic interface doesn’t utilize the default gateway that is configured on the management interface. You have to manually add routes for traffic from the diagnostic interface to your SNMP management stations. You can repeat this process if you want to do the same for Syslog traffic.

References

Wow… Someone might see this

Justin Hippen on 11/28/2018

So… If you are actually reading this (and I’m sorry), this network engineer successfully got WordPress working. 🙂

I’m starting this blog to document my thoughts on… something. Probably mostly enterprise networking & security related. Maybe some virtualization & server stuff too. But if I’m being honest, I’m also trying to document myself and my journey to the next level in my IT career. Whether that is a transition into something like Site Reliability Engineering (SRE) or Network Reliability Engineering (NRE) or something DevOpsy or whatever tomorrow will bring, my goal is to document my thoughts, trials, tribulations, failures, and successes here.

Soon (hopefully) there will be some real content here and this post will be lost to the wayback machine.