How can you design LANs for real-time applications?

Crafting LANs for real-time applications is akin to planning a gourmet meal. Begin by carefully evaluating the specific ingredients – your real-time applications and devices. Just as a chef considers flavors and textures, analyze the expected traffic patterns, identifying the "ingredients" that contribute to a smooth, efficient network. Much like balancing the elements in a recipe, tailor bandwidth and quality of service to create a network that serves up a delightful, seamless experience for your real-time applications.

Make sure you answer important questions such as: - What types of networks will be involved (WAN, WiFi, Wired, VPN)? - How much traffic will be directly between devices (phone/video calls) vs hairpin through an SBC or PBX that is on-prem or in the cloud? - Does conferencing happen locally via multicast, or does it go to an n-way conference mixer in a cloud PBX? - How will my devices come online and discover their configuration? - Is the real-time application running on a dedicated device or as an application on a PC or a mobile device? - What audio/video codecs will be involved (H265 uses less BW than H264, and G729 uses much less BW than G711 or G722)?

Given we're talking about LAN, make sure you understand how RTP will flow between devices in the same subnet, a different subnet on the same LAN, or an external network. SBCs often allow same-NAT media release by default, but require additional config to enable release for different subnets behind the same public IP. Use L3 switching to improve east-west traffic flow. Try and isolate real-time traffic physically, if possible. At worst, use VLANs to separate it, and protocols like LLDP to auto-discover the native and tagged VLANs. Understand MTU and MSS, and how 802.1Q, MPLS, VPNs and other protocols affect payload size to avoid IP fragmentation.

There are some easily accessible and standard guides on recommendations for QoS for real-time voice and video. What I'll share here is that you can minimize configuration by understanding what your devices and applications can support for QoS. If your IP phone can set DSCP, don't bother classifiyinguand setting DSCP on the network port. However, if your real-time application is a desktop application and you can't control it's behaviour, you'll want to classify using L3 info, since L2 info won't have information on transport. Make sure RTP is always in an LLQ, and with adequate reserved bandwidth. Consult your device specific documentation for what you can and can't do for QoS.

Use SIP-TCP to have better success with firewalls and NAT timers. Know your RTP ports ranges and use port-ACLs to block all host-to-host traffic on the same VLANs (for good security hygiene), except RTP ranges. Use SIP-TLS, and consider using SRTP when going over unencrypted networks. If you're already doing IPSec or SSL VPNs, the double encryption might not be worth the performance tradeoff of doing SRTP. SIP is easier to eavesdrop, so always use TLS. Use Mutual TLS for config discovery and download. Don't risk exposing your SIP credentials. If you have a supporting RADIUS solution, 802.1x will simplify configuration through automation. Disable HW acceleration on IDS/IPS appliances for real-time traffic.

In the journey of crafting LANs for real-time applications, the fifth step is all about staying in the groove – monitoring and troubleshooting. It's like having your network on a heartbeat check, swiftly detecting and fixing any hiccups that could throw off your real-time applications. Picture it as using a toolkit with ping, traceroute, SNMP, NetFlow, and Wireshark – the tech-savvy troubleshooters. But here's the cool twist – before rolling out your design, you get a rehearsal space with network simulators like GNS3 or NS3. It's like fine-tuning your band before hitting the big stage, ensuring your network performance is ready for the spotlight. In my experience before this is where most architects stop without seeing it all through.

Get comfortable collecting and understanding packet captures with Wireshark. Make sure your monitoring things like registrations and session from your NMS. There are great commercial solutions such as Hammer for scaling VoIP analysis and troubleshooting efforts. Make sure your devices, SBCs, or PBXs offer some form of MOS or RFactor scoring for voice quality. Understand the external networks that communicate with your border. Take regular registration snapshots from your SBCs, and lookup the source network info using WHOIS. Learn if some networks perform better than others. Be careful relying too much on traceroute or pings for quality measurement. Analyze SIP/RTP traffic from captures to identify loss, jitter, fragments, and more.

You can also consider plannnig for network redundancy and failover mechanisms to ensure continuous operation in case of network disruption or hardware failure, also design and implement remote access solutions and VPN to facilitate secure connection for remote users.

Creating LANs for real-time applications means thinking about things like how much data can be sent at once, how quickly it gets there, and how dependable it is. Use Quality of Service (QoS) tools to make sure important data gets priority, set up VLANs to keep different types of data separate, and pick networking equipment that doesn't delay things too much.