Legacy Apps and Network Design

I just ran across yet another legacy app with a design that runs contrary to networking best practices. If you’ve been in the industry for a while, you’re probably thinking “so what else is new?” – and have tales to tell over a beer. This blog is about a couple-three things I’ve encountered over the years (alongside occasional rather bad network design), offered as virtual experience for readers to maybe learn from.?

VLANs Everywhere

We’ve been planning to deploy SD-Access for a government entity. A mix of routing and VLANs, with some inter-site VLANs from way back, ancient Juniper and optical gear, now modernized. The idea was/is to use SD-Access and Layer 3 VN’s, since we had yet to encounter an application that actually required a sprawling user VLAN. In addition, we hoped/hope to add more user segmentation after the initial buildout.?

What just surfaced was a unique requirement. Namely, the Public Safety team has an application that requires fixed IP addresses so it can contact specific people’s laptops. And the people move around between sites.??

In some organizations, this would not be a problem, because all the relevant staff would be working out of one location. Up until now, this wasn’t a problem for this organization, because the prior switch-centric network had trunks over optical devices/fiber.?

With SD-Access this would is not a problem within a site. SD-Access is built to support VLANs that extend throughout a site.?

The plan was (is) to use SD-Access doing SDA Transit between sites. That entails underlay routing with VXLAN overlay tunnels within and also between sites. VLANs directly between sites go away. We viewed that as a plus, since large scale VLANs and stability are frequently a major problem, poor stability. With VXLAN, stability good, outages less frequent (hopefully)! (Downside: perhaps tech complexity when there is a problem. Overall maybe fewer problems due to automated configuration?)

Anyway, the question then becomes how to accommodate the need for limited but extended Layer 2, which by any measure is highy undesirable, not scalable, not robust? Probably about 90 users in a few sites, so Layer 2 “noise” shouldn’t be terrible (propagation of BUM traffic – broadcast, unknown, multicast within the extended VLAN).?

I believe (but have not tested) that Cisco SD-Access supports this scenario, with Layer 2 VN’s. I say “believe” because there may be caveats I have not yet encountered, despite looking for them. I recall noting the functionality a couple of years ago, initially the primary use case seemed to be supporting legacy guest wireless (the infamous Guest VLAN). I last looked at this a couple of years ago. And missed testing it since we did not know of this particular application’s behavior. Oh well, requirements change and grow.?

Broadcast/L2 Multicast Apps

Another undesirable legacy app behavior I’ve encountered was in a medical setting. The app uses broadcast or multicast for the nurse station console to receive alerts from patient monitors. Which is fine in a small LAN environment, but not if you are a large hospital that rolls patients beds between buildings, and needs larger scale.?

The vendor in question also pitches that you need them managing a dedicated network to mitigate risks. What they have built in the past was a network of many (30?) low end Cisco Layer 2 switches with spanning tree running. And over time, some of the redundancy may have gone away, but that was probably not their fault. Unless someone had to shut down some redundant links to quickly resolve a spanning tree traffic looping problem.?

I’m going to be polite and not state my opinion. You probably wouldn’t learn any new four-letter words anyway. My opinion doesn’t matter once the solution got purchased, you just have to somehow support it. I’m not going to name the company providing this solution, for obvious reasons.?

PCI

We had a bet going on this one. Initial research suggested that various internal functions requiring accepting credit card payments were all done via end systems that used a VPN tunnel back to a processing server. In which case, segmentation might well not be needed. After a while, it turned out that there were some devices that did NOT do that, with more planned. The conclusion was to put the endpoints into a SD-Access VN, to ensure isolation and make it easier to limit external connectivity to going through firewall layers.?

Personal Conclusion

Personal conclusion is that both firms should have re-engineered their apps a while ago. Also maybe caveat emptor – but the people buying the apps are probably not networking people, plus they have different priorities.?

Historical Note

IP Mobility and Mobile Router were Cisco features supporting a device or router that was not on its “home” network. I found a Cisco document from 2020 on this, plus some from 2018. I’m not sure if the feature is still supported, but it looks likely. I’m mentioning this because if you need it, you need it badly.?

One use case (the mobile router one) was for in-bus networking, where the bus router would hand off between upstream wireless (or whatever) connections. Mobile router would track which router (bus) to send your laptop traffic to. Cool stuff!?

(And if you poke around Cisco’s IOT pages, there’s now reliable high-speed mesh wireless with handoffs, with trains as one use case.)?

Conclusion

This is where a lot of experience in one particular industry or niche might help, in terms of experience and knowledge of the applications with weird, undesirable, or other unique behaviors. Even in that case, there may be enough unique niche products to provide surprises.?Medical applications appear to be one major kind of applications that do "interesting" things.

Some of my limited exploration of IOT topics suggests that similar legacy approaches may occur with sensor and other “small” devices, for various reasons (simplicity, assembly code running on smaller CPU chips, etc.). And may not change much over time.?

About all I can do is note that such things exist, so you too can add them to your mental list of “network-hostile” applications to look out for.?

Which I’ve now done. Enjoy!

Comments

Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!?

Hashtags:?#NetCraftsmen #CiscoChampion #CCIE1773?#Layer2IsEvil??

Disclosure statement

Twitter:?@pjwelcher

LinkedIn:?Peter Welcher

Andy Whitaker

Network Architect at Heartland Business Systems

2 年

Such a common problem. I still run into the old "insert firewall and find out x application does not do TCP Keepalive" problem from time to time. It does seem to be medical, manufacturing, IoT, etc... where it crops up the most. Unfortunately even large companies have tied our hands by making design decisions that don't utilize protocols and features as they probably should for the time they were developed (a certain major vendor who pushed our industry into stretched layer 2 datacenters and overlay networks because of one feature being layer 2 only comes to mind). :) Great post! Thanks Peter!!

回复

要查看或添加评论,请登录

Peter Welcher的更多文章

  • Introduction to Microsegmentation

    Introduction to Microsegmentation

    This blog begins an introductory series of moderately long blogs, covering key aspects of Microsegmentation and Zero…

    3 条评论
  • Pete’s Take: Catchpoint at Cloud Field Day 22

    Pete’s Take: Catchpoint at Cloud Field Day 22

    Tech Field Day always produces such great technical content! However, it can be a challenge keeping up with it due to…

  • AI Ate My Blog on RoCEv2

    AI Ate My Blog on RoCEv2

    I acknowledge I’ve been a blog technology summarizer for quite a while. It served to help me broaden/solidify my skills…

  • AI Datacenter Switch Math

    AI Datacenter Switch Math

    Author: Pete Welcher, Coauthor: Brad Gregory This is blog #3 in a small series about Networking for AI Datacenters…

  • AI Requirements for Datacenter Networking

    AI Requirements for Datacenter Networking

    Author: Pete Welcher. Coauthor: Brad Gregory.

  • Quick Takes #2, February 2025

    Quick Takes #2, February 2025

    I’m working on some longer blogs that I hope to be able post in the next week or two. In the meantime, lots of exciting…

  • Quick Takes: February 2025

    Quick Takes: February 2025

    I’ve got some longer technical blogs in the works. For this week, it’s time again for some of my “Quick Takes”:…

  • Pete’s Take: Pain Points in Networking and IT

    Pete’s Take: Pain Points in Networking and IT

    It’s a new year, so time to look at how Networking and IT have been evolving. Ignoring the AI elephant in the room.

    1 条评论
  • Pete’s Take: Pondering NetOps/AIOps Strategy

    Pete’s Take: Pondering NetOps/AIOps Strategy

    What’s new in NetOps, including AIOps, and where are things heading? Some thoughts ..

    1 条评论
  • Pete's Take: AI/ML and Error

    Pete's Take: AI/ML and Error

    Artificial Intelligence (AI) has certainly received a lot of press lately. And achieved new levels of hype.

社区洞察

其他会员也浏览了