Matt has worked in Technical Marketing at Cisco for the last 20 years running an obstacle course of technologies including SNA, ATM and Ethernet switching, Service Provider Aggregation, Metro Ethernet, Network Management and Enterprise Branch Architectures. He has also worked on a variety of products including the Cisco 7500, 7200, LS1010, 8540, 7300, and Cisco 10K before finally settling down for the last several years as the Platform Architect for the ISR series of branch routers. In his spare time Matt is an avid SCUBA diver in North Carolina.
Matt has worked in Technical Marketing at Cisco for the last 20 years running an obstacle course of technologies including SNA, ATM and Ethernet switching, Service Provider Aggregation, Metro Ethernet, Network Management and Enterprise Branch Architectures. He has also worked on a variety of products including the Cisco 7500, 7200, LS1010, 8540, 7300, and Cisco 1
The phone charger feature was an added benefit to adding USB ports to the router. We didn't build it that way, but it does come in handy from time to time. ;-)
Thanks for the feedback!
... View more
Way back in the early 2000s, we noticed a trend in branch routing. Customers started asking for a “branch in a box.” The problem they were having was that the complexity of networks of the day required lots of stuff  . They needed separate devices for routing, switching, VoIP, firewalling, WAN optimizing, app serving and lots of other stuff. All of these devices took up space, added complexity and, sometimes most importantly, added noise to the office.
Like any good company interested in selling lots of stuff serving our customers’ needs, Cisco responded with the 2600/3600 and later the ISR series of products. ISR stands for Integrated Services Router which is a perfect name for what this device did  . The ISR could integrate routing, switching, call control, firewall, application hosting, WAAS and even charge your cell phone  . Naturally the naysayers  immediately responded with cries of “too many eggs in one basket” and “your branch will fail and you’ll have to move in with your parents if you do this!” While that objection might feel intuitive it shows a fundamental misunderstanding of reliability statistics  . Let me show you why putting everything into a single device is actually better for the network than using separate dedicated devices.
First, let’s think about what we mean by a “critical component” to the network. Something is critical if the failure causes a significant or complete reduction in functionality in the network. If you lose the LAN switch that your devices connect to, that’s a critical component. The same is true for the WAN router but may or may not be true for the WAN Optimizer, app server, call control or other service if the branch can still function possibly with a backup service in the cloud. Let’s assume in that we have 5 of these “critical” components in a typical branch office: switch, server, router, WAN optimizer, and firewall. If any of these fail we kick the customers out and send the staff home. Each of these devices has a reliability associated with it. Perfect reliability would be 1.0 and reliability of 0.8 in a given year is good for a complex piece of compute hardware with power supplies and fans so let’s use that for all devices  . This is known as serial reliability and the reliability of the entire branch is the reliability of all devices multiplied together. In this example that would be 0.8 5 or 0.33 for the system. That means the annual failure rate for the branch is 67% !
So how can we get this number higher? Well if we take a look at the reliability of components in most of these devices it’s pretty obvious what causes most failures: fans and power supplies  . Here’s a look at the Mean Time Between Failures, Failure Rate, and Uptime for common components in any system. As you can see the things we can actually control when building a device are largely the power supply and fan reliability including adding additional redundant power supplies and fans.
MTBF (hours - higher is better)
Annual Failure Rate
(assumes 24hrs to repair)
So, if we can eliminate those high-failure-rate components from most of the devices in our branch and add redundancy in the place we’re “integrating” them, it might look something like this. The reliability of 4 of the devices went up because they no longer have their own fan or power supply while the reliability of the router also went up because it has redundant fans and power supplies  . In this scenario reliability improves to 0.62 with an annual failure rate of 3 8% . While that’s definitely better, it shows that no matter how reliable a device is the series reliability will be decreased when adding it to the network.
See? Putting all your eggs in one basket is a really good thing. This isn’t rocket science. Data centers and cloud providers figured all this out a long time ago. In the early days of server virtualization there were plenty of detractors worried about replacing multiple physical servers with a single hypervisor. Today it is assumed that putting all of your VMs in a single, reliable server or cloud provider is going to improve reliability rather than reduce it. The same is true for critical network services.
What if that level of reliability isn’t good enough for you? That’s where network design can really help you out by using redundant physical hardware. Parallel redundancy is statistically a much better option than serial redundancy. If you assume two redundant integrated systems of 0.62 reliability, the parallel reliability is 0.85 with an annual failure rate of only 15%! Of course, there’s additional cost and complexity involved in a dual router setup, but if availability of the network is important nothing beats redundant hardware.
Disclaimer: The actual numbers used in this blog post are for demonstration purposes only and were largely pulled straight from the south end of a north-bound burro. PLEASE do not use them for any real-world planning unless your resumé is in tip-top shape.
 “Lots of stuff” is a highly technical quantity greater than 2 but less than “tons of stuff.”
 Rejected names were Branch Universal Gateway (BUG), Services Unifying Controller (SUC), and Branch Unifying Terminal (BUT). (Guess which one of those was real.)
 Seriously. Why did you think we put 2 USB ports on there?
 Mostly companies that are now out of business funny enough.
 or a full understanding of competitive marketing.
 This number is just to demonstrate a point. Cisco devices (especially ISRs) typically have much greater reliability but those numbers are secret and stuff.
 Power mains and WAN circuits are both WAY less reliable than anything here but adding dual WAN circuits and diverse paths along with backup power is beyond the space they let me have for a single blog.
 This is known as parallel redundancy which is equal to: 1-[(1-R 1 )(1-R 2 )…(1-R n )]. It’s the same whether you’re talking about redundant fans, redundant switches, or redundant routers.
... View more
Presenting at Cisco Live is fun.
Actually, the weeks of work getting slides together with a Session Manager bugging you for submitting them late and doing slide reviews with brand police is not fun at all. What's really fun are the conversations that you have after the session. You always get the most interesting stories and problems in the 15 minutes after the session ends.
That was the case at Cisco Live Barcelona a few weeks ago. After one of my sessions I had a customer come up to tell me about an interesting problem he had choosing a router in a design for train ticketing kiosks. Train stations, and the machines that sell you tickets, aren't always in the nicest of environments. Not all stations are indoor air-conditioned cosmopolitan affairs. Quite often they're utilitarian outdoor sheds with just a roof to keep them somewhat dry. Definitely not a place you want to hang out 24x7 even if you're an avid trainspotter. His problem was picking a router that would be happy in such a harsh environment and could connect via LTE to primary and backup providers. For bonus points he also needed to connect to a couple other devices inside the kiosk for actually selling the tickets.
C1109-4PLTE2P As luck would have it, we had just introduced a couple of new members of the Integrated Services Router (ISR) portfolio that would be perfect for him. The ISR 1109 was designed for these type of not-quite-IoT environments but certainly places a normal network device would suffer. Officially it's referred to as a "Machine to Machine" product which means that it is passively cooled with an extended temperature range, but not to the extremes of something designed to sit outside directly exposed to the elements. It's a good combination of ruggedness and affordability that makes it perfect for these type of kiosk deployments.
The ISR 1109 is a member of the Cisco ISR 1000 Series which means that it is built on IOS-XE for performance with a dizzying assortment of features and can also support the Cisco SD-WAN solution for simple management and efficient use of any WAN link you have available. You have options for 802.11ac wireless LAN plus up to 4 wired GE LAN ports in addition to 1 or 2 LTE radios. Each LTE radio supports dual SIMs so you can have up to four providers configured with up to two active at any time. They're designed for -20 to +55C so quite literally they're designed for places you just don't want to be. C1109-2PLTEXX
When I told him all of this it was as if the heavens had opened up and he had just discovered mana that would justify his trip to his boss. When you can solve a real problem directly with something released at just the perfect time is what makes all the work getting ready for a Cisco Live worth it. My dream is for a 90 minute session at Cisco Live where we do nothing more than answer design questions like this. I don't think there's a Session Manager on the planet that would approve a session like that, but I can dream right?
More information on the ISR 1000 Series, including the 1109, can be found here.
To help in my quest for an open jam session at Cisco Live, email email@example.com.
(That last one is a joke - mostly.)
... View more
If by "inbuilt" you mean the native front-panel SFP interfaces on the system then the answer is no. These are only 1G interfaces so they support SFP not SFP+. If you insert an SFP+ it won't even be recognized. The 4331 can support a 10G interface in an SM-X module as was mentioned here. However, the 4331 cannot come close to filling a 10G interface and can only handle 300Mbps with services (ignoring boost licenses). This router is not designed to forward 10G worth of traffic (or anything approaching that). Yes you can install a 10G SM-X and yes it is supported, but do you really want to?
... View more
The short answer is there isn't one. The slightly longer answer is that you don't need one because we give it to you for free. The much longer answer: The ISM-VPN-29 along with all crypto modules for the ISR G2 added additional hardware crypto functionality to the router. All ISR G2s did encryption in hardware, but the default system did not include enough hardware to fill the router forwarding capacity with encrypted traffic. Hardware encrypters are expensive especially when the ISR G2s were developed. The ISM-VPN gave you additional capacity to fill the box with encrypted traffic. When the ISR 4Ks were developed hardware encryption had come down in price to the point it was possible to include hardware encryption that could fill the box. Essentially that's like including an ISM-VPN on every ISR4K that you buy so it isn't needed. We do have the option in the future of using the ISE (Integrated Services Engine) slot inside the ISR4K to add more crypto capacity if we do ever need it. That might happen if there's an especially complex transform set that means our on-board crypto can't keep up with the data plane. So far that hasn't happened so we've never built, and likely never will build, and ISE-VPN. An interesting side-effect of that has to do with US Department of Commerce export controls. They control how much "strong encryption" we can export in order to make sure that it isn't going to embargoed countries. To comply with that we have to record who the end customer is for all strong encryption so they can guarantee it isn't going somewhere they don't like. (We have to record it but we don't send it to them unless they ask. AFAIK they've never asked.) That's relatively easy with an ISM-VPN. We just track where that hardware is ordered and we're done (the ASR1K uses a similar mechanism). With the ISR4K we don't have a hardware order we can track, so we have to use the HSEC license which opens up the box encryption capacity to "export controlled" levels. Since we have to track the end-user for HSEC licenses that means that it has to be an enforced license tied to the box which is why HSEC is the only node-locked license that must be installed on the box. That's just something to be aware of because this can cause a headache for resellers and integrators who often order hardware before they know exactly where it's going.
... View more
I'm not an expert, but I can think of a couple places where this would be handy. First, if you're dealing with WAN links that already have a reasonably large MTU, override allows you to bump up the MPLS MTU higher to account for the additional MPLS encapsulation so that the resulting packet fully consumes the interface MTU. Without override you can only do this on interfaces with MTUs less than 1524 bytes. Second, in some cases it might be desirable to allow larger packets in the MPLS core than what is available on the local WAN link. Maybe the core can handle nice large jumbo frames but the local link can't. For efficiency across the network as a whole, you might accept fragmentation at the edge which impacts fewer users, than dealing with smaller less efficient packets in the core. The performance impact could be minimal if you have a platform on either end of the link that can handle fragmentation and reassembly in hardware. In general, it's probably one of those commands (the override portion), that should be used with caution and only if you're sure it's what you need. I don't know the history, but this looks like a command that was implemented because of a specific customer environment that would really benefit from it. Here's the command reference for curious folks: Cisco IOS Multiprotocol Label Switching Command Reference - mpls ldp atm vc-merge through mpls static binding ipv4 [Sup…
... View more
Hi Bakaji, The easiest way is probably to just use a static route, but there are other options using route maps and policy routing. Here's a whitepaper that outlines a few of the options. Configure Route Leaking between Global and VRF Routing Table without using Next-hop - Cisco Matt
... View more
I don't believe there is the capability of mapping the cache parameter from YAML. YAML only maps some of the most common libvert parameters that don't change between versions. I'm checking with some of the developers, but my suspicion is that this isn't something YAML does today.
... View more
Cisco doesn't really make home routers (DSL or otherwise) any longer since we sold off the Linksys division. There are plenty of small to medium business routers from Cisco that would work for you, but they're probably more expensive and more feature-rich than what you could use.
... View more
In general I think you've got it although I don't believe that Inverse ARP and no split-horizon are enabled by default on physical interfaces. Most often you'll see this configuration using sub-interfaces for the DLCIs although there's nothing technically wrong with using the physical interface. Using sub-interfaces and explicitly configuring them is a good way to avoid any ambiguity. I believe show frame-relay interface will also show you the status if I remember the command correctly. It's been years (maybe decades now) since I've spent a lot of time on frame-relay though. There are a lot of good guides and examples in the Googles though for something that never dies.
... View more
The NFVIS operating system includes a local web portal that lets you deploy NFVs on an individual box. That's great for lab testing but it isn't really scalable for any real deployment size. Most Enterprise-scale deployments will want to use APIC-EM with the ESA application to orchestrate multiple devices in different locations.
... View more