Showing posts with label Enterprise Networking. Show all posts
Showing posts with label Enterprise Networking. Show all posts

Tuesday, June 1, 2021

Modernizing Enterprise WAN: SD-WAN vs MPLS Revisited

June, 2021 • 7 min read

Context and Momentum

As 2021 progresses, the ongoing pressure on enterprise networks highlights the urgent need for flexibility and cost-effectiveness. SD-WAN (Software-Defined Wide Area Networking) has matured, transforming how businesses build and manage their WAN infrastructure. With more cloud-centric architectures and hybrid work scenarios in place, traditional MPLS circuits continue to face scrutiny over scalability, cost, and agility.

Architectural Shifts in the WAN Landscape

In pre-2020 architectures, MPLS provided predictable performance and strong SLAs but struggled with agility. As enterprises adopted cloud applications and remote workforces, traffic patterns became more internet-bound. This shift caused backhaul through centralized MPLS links to become inefficient. SD-WAN addresses this challenge by providing intelligent path selection, dynamic routing, and local breakout—modernizing the WAN edge.

Control and Orchestration

A key benefit of SD-WAN lies in its centralized management plane. Network architects can define policies based on application sensitivity, security posture, or user roles—automating deployment across thousands of sites. This contrasts with legacy MPLS where configuration is manual and prone to error. As controller platforms evolve, SD-WAN integrates with other orchestration domains such as security (SASE) and cloud (IaaS/VPC). These synergies are reshaping IT operations models.

Security Integration

In 2021, SD-WAN is rarely deployed standalone. Enterprises now demand integrated security—whether through SASE stacks, native firewalls, or third-party services. This makes SD-WAN a launchpad for Zero Trust Network Access (ZTNA), enabling segmentation, identity-aware access, and internet-bound protection. MPLS, by contrast, lacks intrinsic security features and often requires overlay solutions.

Resiliency and Performance

Another consideration is link diversity. MPLS delivers performance through dedicated lines, but can become a single point of failure. SD-WAN, with support for broadband, LTE/5G, and satellite, offers resilient paths with real-time failover. Techniques like Forward Error Correction (FEC), jitter buffering, and application-aware QoS further ensure consistent performance—even over less reliable circuits.

Cost Structures and ROI

Cost remains a major driver in WAN decisions. MPLS is often priced at a premium due to carrier SLAs and circuit provisioning costs. SD-WAN's ability to leverage commodity broadband introduces significant savings—particularly across global or distributed environments. While upfront investments in appliances and management platforms are needed, TCO analysis often favors SD-WAN beyond 12–18 months.

Deployment Realities

Adoption, however, is not one-size-fits-all. Enterprises with existing MPLS investments may consider a hybrid approach, gradually offloading traffic to SD-WAN where latency and control justify it. Some verticals (e.g., finance or healthcare) may also retain MPLS for compliance or deterministic traffic handling. The role of WAN in architecture must align with risk profiles, operational maturity, and digital objectives.

Architectural Reflections

From an architectural standpoint, the shift toward SD-WAN illustrates a broader transition from static, circuit-switched thinking to software-defined intent. This is not just a routing technology—it’s a platform strategy that converges connectivity, policy, visibility, and security. Designing the modern WAN thus involves stakeholders beyond the network team: security, cloud architects, and business owners must co-create resilient edge architectures that match modern application needs.

Conclusion

As of June 2021, SD-WAN stands as a mature alternative to MPLS for most enterprise use cases. While MPLS continues to serve niche functions, the broader momentum favors architectures that are programmable, cloud-aligned, and security-driven. The network edge is no longer a boundary—it’s a control point. IT leaders who embrace this paradigm shift will gain the agility and insight needed to support evolving business strategies.



Eduardo Wnorowski is a network infrastructure consultant and Director.
With over 26 years of experience in IT and consulting, he helps organizations maintain stable and secure environments through proactive auditing, optimization, and strategic guidance.
LinkedIn Profile

Friday, March 1, 2019

Network Automation: Scaling Your Infrastructure Strategically

March, 2019  |  Reading time: 8 min

In March 2019, network teams face growing pressure to manage ever-larger infrastructures while maintaining agility, uptime, and compliance. As networks span across on-premises, cloud, and hybrid environments, the role of automation becomes essential. Network automation moves beyond the convenience of scripting—it becomes a necessity for scale, accuracy, and rapid deployment.

Why Network Automation Now?

Organizations increasingly operate in real-time digital environments. Manual configuration simply cannot keep up with the speed of demand. Network automation addresses this gap by enabling consistency and repeatability, minimizing configuration errors, and accelerating service delivery.

By automating provisioning, monitoring, and compliance, engineers reclaim time and focus on higher-value activities such as design, performance optimization, and strategic planning. This shift is not about eliminating human roles but about empowering teams to work smarter.

Key Use Cases Driving Automation

  • Zero-touch provisioning (ZTP): Automatically configures new devices as they come online.
  • Configuration management: Ensures all devices adhere to golden configurations and compliance baselines.
  • Automated remediation: Responds to events such as link failure, latency, or policy violation in real time.
  • Cloud integration: Automates networking components as infrastructure is deployed or scaled in public clouds.

Choosing the Right Tools

The 2019 landscape includes a robust ecosystem of tools designed to support automation across multiple layers. Popular choices include:

  • Ansible: Widely used for its agentless design and YAML-based playbooks, ideal for network devices and systems alike.
  • SaltStack: Offers high scalability and robust remote execution features.
  • Python and Nornir: Offers full programmability for engineers wanting full control with extensibility.
  • Vendor-specific platforms: Cisco NSO, Juniper Contrail, and Arista CloudVision provide deep integration with their ecosystems.

Tool choice should align with the environment’s diversity and the team’s expertise. Open-source frameworks offer flexibility and cost savings but may require more ramp-up time.

Integrating with Change Management

Automation must coexist with enterprise change control processes. Integration with ITSM platforms like ServiceNow and ticketing workflows ensures visibility and accountability. Teams should build in automated pre-checks, rollback logic, and post-change validations to support safe deployment practices.

Security Considerations

Automation frameworks often require privileged access. Best practices in 2019 include:

  • Using secure credential vaults (e.g., HashiCorp Vault, CyberArk)
  • Implementing role-based access control (RBAC) for playbooks and scripts
  • Auditing changes made by automation tools

Security must be part of the automation strategy from day one.

Scaling the Automation Journey

Start small. A pilot project—like automated backup configuration or interface description syncing—builds credibility and trust. Document success, gather metrics (e.g., time saved, incidents reduced), and expand gradually. Teams should treat playbooks and scripts as production code, following CI/CD principles and version control (e.g., Git).

Looking Ahead

As we progress through 2019, intent-based networking and closed-loop automation gain traction. These approaches elevate automation to the level of business intent, automatically translating goals into device configurations and behaviors. While early in adoption, they hint at the future: a self-operating, self-healing network.



Eduardo Wnorowski is a network infrastructure consultant and Director.
With over 24 years of experience in IT and consulting, he helps organizations maintain stable and secure environments through proactive auditing, optimization, and strategic guidance.
LinkedIn Profile

Wednesday, November 1, 2017

Network Telemetry and Streaming Analytics: Real-Time Insights for the Modern Enterprise

November 2017 · Estimated Reading Time: 8 minutes

Introduction

As networks continue to grow in complexity and scale, traditional methods of monitoring are no longer sufficient to provide the real-time visibility that enterprise environments require. Enter network telemetry and streaming analytics: a powerful combination that delivers unprecedented insight into live traffic flows, device performance, and application behavior. In this post, we explore how modern enterprises can leverage these technologies to gain actionable, real-time intelligence and maintain optimal network performance.

Understanding Network Telemetry

Network telemetry is the automated, real-time collection of network data at scale. Unlike traditional SNMP polling, telemetry uses a push model to stream data directly from devices to collectors. This allows for more frequent updates, lower overhead, and more granular insight.

Key telemetry technologies include:

  • gNMI (gRPC Network Management Interface): A protocol developed by Google that uses gRPC to transport data efficiently and securely.
  • Model-Driven Telemetry: Allows devices to push data based on YANG data models, improving consistency and interoperability.
  • IPFIX/NetFlow: Often used for flow data but now extended in many platforms for real-time telemetry export.

Why Traditional Monitoring Falls Short

Legacy monitoring tools rely heavily on periodic polling, which results in delayed visibility and limited context. Additionally, the volume of data produced by modern networks has outpaced what SNMP and syslog systems were designed to handle. As a result, administrators are often left with gaps in visibility that can lead to delayed incident response and troubleshooting.

The Power of Streaming Analytics

Streaming analytics tools consume telemetry data as it arrives, allowing real-time dashboards, anomaly detection, and trend analysis. These platforms, such as Kafka, Elasticsearch, InfluxDB, and Prometheus, can scale horizontally and handle millions of data points per second.

For example, telemetry from a router can include interface statistics, queue drops, CPU usage, BGP peer status, and QoS metrics. This data can be visualized using Grafana or Kibana, and correlated with other infrastructure metrics to provide end-to-end visibility.

Use Case: Proactive Performance Monitoring

One of the primary use cases for telemetry is proactive performance monitoring. Instead of waiting for users to report slow applications or outages, network engineers can detect rising latency, packet drops, or utilization spikes before they impact users.

Consider a scenario where interface buffer drops are rising on a WAN router. With telemetry, this can be observed in near real-time, triggering alerts or automated scripts to reroute traffic or adjust QoS policies before packet loss becomes noticeable.

Use Case: Security and Anomaly Detection

Telemetry is also instrumental in network security. By continuously streaming flow data, it’s possible to detect volumetric attacks, data exfiltration, or misconfigured devices. Tools like Cisco Stealthwatch or open-source Suricata can ingest this data and detect deviations from normal behavior.

Streaming analytics can also be used to baseline normal behavior and alert on anomalies, such as an unusual increase in DNS traffic or new peer connections that don’t match expected patterns.

Deployment Considerations

To implement network telemetry and streaming analytics effectively, organizations need to consider:

  • Device Support: Ensure that network hardware supports model-driven telemetry and appropriate export protocols.
  • Scalable Collector Infrastructure: Use distributed systems that can handle large-scale ingestion and processing of data.
  • Data Retention and Analysis: Decide what data to keep long-term vs. what to process in-memory for real-time dashboards.

Integration with Automation

Telemetry is a foundational pillar for network automation. By feeding telemetry data into automation systems, enterprises can build closed-loop systems that monitor, detect, and respond to conditions automatically.

For instance, if a telemetry feed indicates a failed BGP session, an automation script can verify the path, ping endpoints, and trigger a failover or remediation action in seconds — without human intervention.

Challenges and Future Trends

While powerful, telemetry implementations must be carefully managed. Excessive data collection can consume bandwidth and storage, and improperly configured collectors can introduce latency. Security is another concern — encryption and access control must be enforced to prevent unauthorized access to sensitive metrics.

Looking ahead, we expect to see tighter integration of telemetry with AI/ML-driven analytics, SD-WAN orchestration, and SASE platforms. Vendors are increasingly embedding telemetry hooks into their products, making real-time insight a built-in feature rather than a bolt-on.

Conclusion

Network telemetry and streaming analytics are transforming how enterprises manage, monitor, and secure their networks. By shifting from reactive to proactive monitoring, IT teams can maintain higher uptime, detect issues faster, and ensure better experiences for users and customers alike.



Eduardo Wnorowski is a network infrastructure consultant and Director.
With over 22 years of experience in IT and consulting, he helps organizations maintain stable and secure environments through proactive auditing, optimization, and strategic guidance.
LinkedIn Profile

Sunday, October 1, 2017

Software-Defined Access (SD-Access): Evolving Network Control in the Enterprise

October 2017 · 8 min read

Enterprise networks in 2017 are undergoing a dramatic transformation, driven by user expectations, security demands, and the need for operational agility. Cisco’s Software-Defined Access (SD-Access) architecture emerges as a powerful response to this transformation — reimagining how networks are designed, operated, and secured.

What is Software-Defined Access (SD-Access)?

SD-Access is Cisco’s enterprise implementation of Software-Defined Networking (SDN) principles. It builds upon the Digital Network Architecture (Cisco DNA) and introduces a fabric-based model that abstracts control from the underlying hardware to a centralized policy engine. This shift enables automation, enhanced security, and visibility across the network stack.

At the heart of SD-Access is the concept of segmentation and identity. It moves beyond traditional VLANs and ACLs, offering a model where user identity, device type, or business role determines access privileges and network treatment — regardless of location or access method.

Core Components of SD-Access

The SD-Access fabric is composed of several key elements:

  • Fabric Edge Node: The switch where user endpoints connect. It provides Layer 2 and Layer 3 connectivity into the SD-Access fabric.
  • Control Plane Node: Maintains a topology map of the fabric using the Locator/ID Separation Protocol (LISP).
  • Fabric Border Node: Connects the fabric to external networks, such as the internet or data center.
  • Identity Services Engine (ISE): Acts as the policy decision point based on user identity, device profile, and posture.
  • DNA Center: The central controller for policy, automation, and assurance within SD-Access.

Why SD-Access Matters in the Modern Enterprise

Traditional network architectures struggle to cope with the dynamic nature of today’s user behaviors, IoT devices, and cybersecurity threats. SD-Access addresses these pain points through:

  • Policy-Based Segmentation: Micro- and macro-segmentation enforce policies based on user identity, reducing the attack surface.
  • Automated Provisioning: Reduces deployment times from days to minutes with intent-based workflows in DNA Center.
  • Assurance and Analytics: Continuous monitoring and insights via telemetry and analytics to maintain SLA and user experience.
  • Scalable Architecture: Decoupling hardware from policy simplifies expansion and change management.

SD-Access vs Traditional Campus Design

Let’s examine a side-by-side comparison:

FeatureTraditional NetworkSD-Access
Access ControlVLANs, ACLsIdentity-based, centralized
ProvisioningManualAutomated via DNA Center
SecurityPerimeter-focusedDistributed segmentation
Change ManagementError-pronePolicy-driven, intent-based

Deployment Considerations

While SD-Access offers compelling benefits, adoption requires careful planning:

  • Ensure hardware compatibility with fabric capabilities (e.g., Catalyst 9k).
  • Invest in DNA Center and ISE infrastructure.
  • Evaluate integration points with existing network and security policies.
  • Develop internal expertise or partner with SD-Access experienced integrators.

Real-World Use Cases

Organizations embracing SD-Access often report:

  • Streamlined onboarding of users and devices across sites
  • Faster segmentation for PCI or HIPAA zones
  • Improved visibility and troubleshooting across the network
  • Consistent policy enforcement in branch, campus, and remote settings

Conclusion

SD-Access represents a meaningful evolution in enterprise networking. It redefines the control plane, enhances security posture, and dramatically improves operational efficiency. As enterprise networks grow in complexity, adopting a fabric-based, identity-aware model like SD-Access becomes less a luxury and more a necessity.



Eduardo Wnorowski is a network infrastructure consultant and Director.
With over 22 years of experience in IT and consulting, he helps organizations maintain stable and secure environments through proactive auditing, optimization, and strategic guidance.
LinkedIn Profile

Saturday, August 1, 2015

BGP Attributes: Path Control and Policy Enforcement in Enterprise Networks

 August 2015 | 6 min read

Introduction

BGP (Border Gateway Protocol) plays a foundational role in modern enterprise network design, particularly in multi-site environments where policy-based routing and path optimization are critical. In the early days of networking, static routing and simple IGPs like OSPF or EIGRP sufficed for internal path determination. However, the complexity of today's enterprise WANs—with multiple internet uplinks, cloud interconnects, MPLS, and hybrid SD-WAN overlays—demands a more sophisticated control plane. This is where BGP excels.

Despite its origins as an exterior routing protocol, BGP's flexibility and rich attribute system allow it to be deployed internally (iBGP) to enforce granular path selection and traffic engineering policies. This article unpacks the key BGP attributes that influence path control and explores how they can be harnessed in enterprise scenarios to meet business and technical requirements.

BGP Attributes Overview

At the heart of BGP's decision-making process lies its attribute-based path evaluation system. Each route received via BGP is associated with a set of attributes that influence the best path selection. Some attributes are well-known and mandatory; others are optional or transitive, allowing custom behavior across autonomous systems.

The most commonly used attributes in enterprise routing are:

  • Weight: Cisco proprietary and local to the router. Highest weight wins.
  • Local Preference: Used within an AS to prefer exit points; higher is better.
  • AS-Path: Shorter paths are preferred. Useful for loop prevention and basic routing policy.
  • Origin: Preference is IGP > EGP > Incomplete.
  • MED (Multi-Exit Discriminator): Suggests preferred entry points to neighboring ASes; lower is better.
  • Community and Extended Community: Tags to apply policies across route-maps and peer groups.

These attributes form the foundation of route manipulation strategies. They can be set or filtered using route-maps, prefix-lists, and policy-based routing statements.

Path Selection Mechanisms

Once BGP has collected multiple paths to the same destination prefix, it must determine the best route to install in the RIB (Routing Information Base). The BGP decision process is deterministic and follows a predefined sequence of attribute comparisons. This hierarchy is crucial to understand when implementing policy.

  1. Prefer the path with the highest Weight
  2. If equal, prefer the highest Local Preference
  3. If equal, prefer routes originated by the local router (originated via network or aggregate)
  4. Prefer the shortest AS Path
  5. Prefer the lowest Origin code (IGP < EGP < Incomplete)
  6. Prefer the lowest MED (if paths are from the same AS)
  7. Prefer eBGP over iBGP routes
  8. Prefer the path with the lowest IGP metric to the BGP next hop
  9. Prefer the oldest route (to promote stability)
  10. Prefer the path with the lowest router ID

This sequence ensures consistent behavior, but it can be altered using policy tools like route-maps, where administrators inject logic to override natural decisions based on business constraints, application performance, or link costs.

Policy Enforcement Strategies

BGP's real strength is in its ability to enforce policy at various points in the network. For instance, an enterprise might wish to prefer MPLS for VoIP traffic, but prefer DIA (Direct Internet Access) for cloud SaaS like Office 365. BGP can implement such logic by setting communities and local-preference tags at ingress points, then adjusting outbound decisions accordingly.

Key tools include:

  • Route-maps: Act as conditional logic gates, permitting or modifying routes based on ACLs, prefix-lists, or communities.
  • Prefix-lists: Fine-grained match filters for route announcements.
  • Community tagging: A scalable way to label routes for downstream processing.
  • Policy-based routing: Allows forwarding decisions based on fields like source IP or DSCP, outside of normal destination-based routing.

These tools allow enterprises to model policy that reflects business structure: preferring cheaper bandwidth for non-critical data, segmenting traffic flows per department, or engineering failover paths that meet SLA thresholds.

Enterprise Use Cases

Several real-world use cases highlight the power of BGP path control:

  • Dual WAN Uplink: Enterprises with both MPLS and Internet connections can use local-pref and communities to route critical traffic over MPLS and bulk traffic over broadband.
  • Inter-branch Traffic Engineering: Sites connected via multiple service providers can influence inbound path selection by adjusting MED or AS-PATH prepending.
  • Cloud On-Ramp: Enterprises with direct connections to Azure/AWS/GCP can tag routes to prefer the closest PoP (Point of Presence).
  • Redundancy & Failover: BGP timers and route withdrawal behavior can be tuned to speed up convergence in case of WAN failures, combined with static fallback routes as safety nets.

These patterns repeat across industries—whether it's a retail chain, a manufacturing plant with IoT gateways, or a university with hybrid connectivity.

Summary and Recommendations

Understanding BGP attributes and their role in path control is essential for any network engineer tasked with ensuring availability, performance, and policy compliance in modern enterprises. By leveraging tools like local-pref, MED, route-maps, and communities, organizations can design flexible, robust networks that respond to changing demands and operational conditions.

As enterprises continue to adopt SD-WAN and cloud architectures, BGP remains not only relevant but critical for integrating overlay control with underlay infrastructure.


Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 20 years of experience in IT and consulting, he brings deep expertise in networking, security, infrastructure, and transformation.
Connect on Linkedin

Wednesday, January 1, 2014

Designing Layer 3 Access Layer Architectures

January 2014 - Reading time: 7 minutes

Designing Layer 3 access layer architectures has become increasingly relevant in enterprise networks seeking performance, scalability, and simplified routing. In this post, we walk through the principles behind Layer 3 at the access layer and why it may be a better choice in modern enterprise networks than traditional Layer 2 access.

What Is Layer 3 at the Access Layer?

Traditionally, the access layer operates at Layer 2, forwarding frames based on MAC addresses and using VLANs for segmentation. However, in Layer 3 designs, the access layer performs routing between VLANs and communicates with the distribution layer via IP rather than Spanning Tree-based loops.

Advantages of Layer 3 Access

  • Improved Convergence: By removing Spanning Tree dependencies, Layer 3 designs converge faster after topology changes.
  • Better Scalability: Routing protocols scale better than Layer 2 flooding domains.
  • Simplified Troubleshooting: IP-based routing tools make problem resolution clearer and more deterministic.
  • Fault Isolation: Layer 3 boundaries help contain failures and limit broadcast storms.

Use Case: VLANs and SVI Design

Each access switch may host its own SVIs (Switched Virtual Interfaces) for connected VLANs. DHCP and access policies are typically localized at the switch, which becomes the default gateway for end devices.

For example, in a 3-floor office building, each floor might have its own access switch configured with:

interface Vlan10
  ip address 10.10.10.1 255.255.255.0
interface Vlan20
  ip address 10.10.20.1 255.255.255.0
  

Routing Protocols at the Edge

To advertise these SVIs upstream, a dynamic routing protocol such as OSPF or EIGRP can be enabled on the access switch. This simplifies redistribution and enables ECMP (Equal Cost Multipath) if supported.

router ospf 10
  network 10.10.10.0 0.0.0.255 area 0
  network 10.10.20.0 0.0.0.255 area 0
  

By advertising directly from the access layer, you reduce the distribution layer’s workload and create a more hierarchical, routed design.

Considerations

  • Routing Capacity: Ensure your access switches can support routing at wire speed.
  • Policy Enforcement: ACLs may need to be replicated on multiple access switches unless centrally managed.
  • Redundancy: Use dual uplinks and routing protocols with fast convergence (like OSPF or EIGRP with tuning).
  • Design Consistency: Standardize VLAN and IP schemes for easier support.

When to Use It

Layer 3 access designs are ideal when your organization requires:

  • Rapid failover with minimal downtime
  • Clear IP boundaries for security or compliance
  • Routing-centric data center or branch environments

Smaller, flat networks may still benefit from Layer 2 simplicity, but as organizations grow, the operational advantages of Layer 3 become undeniable.

Understanding Layer 3 at the access layer is key to unlocking scalable and resilient enterprise network designs.



Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 19 years of experience in IT and consulting, he brings deep expertise in networking, security, infrastructure, and transformation.
Connect on Linkedin

Monday, April 1, 2013

IPv6 Transition Mechanisms and Dual-Stack Enterprise Strategies

April 2013   |   Reading time: ~9 minutes

The transition from IPv4 to IPv6 is one of the most important evolutions in modern networking. In 2013, while IPv6 was already standardized and supported by most platforms, real-world deployment remained a challenge for many enterprise networks. This post explores the available IPv6 transition mechanisms and how dual-stack strategies allow organizations to prepare their infrastructure for a seamless transition.

Understanding the Need for IPv6

IPv4 exhaustion had become more than theoretical by 2011, and regional internet registries were running out of available public IPv4 addresses. IPv6, with its massive 128-bit address space, provides not just more addresses but also improvements in routing, autoconfiguration, and network efficiency.

Common Transition Mechanisms

To ensure compatibility during the transition phase, several mechanisms were developed. These include:

  • Dual-Stack: The device runs both IPv4 and IPv6 simultaneously. This is the most robust and preferred method, particularly for enterprises.
  • Tunneling (6to4, ISATAP, Teredo): These mechanisms encapsulate IPv6 packets within IPv4, allowing IPv6 to traverse legacy infrastructure.
  • Translation (NAT64/DNS64): Allows IPv6-only devices to access IPv4 services.

Implementing Dual-Stack in the Enterprise

Deploying dual-stack involves careful planning. Routers, switches, firewalls, and endpoints must all be configured with both IPv4 and IPv6. DNS infrastructure should support AAAA records, and applications must be tested for IPv6 compatibility.

In Cisco IOS, enabling dual-stack on an interface typically involves:

interface GigabitEthernet0/1
  ip address 192.168.1.1 255.255.255.0
  ipv6 address 2001:db8:abcd::1/64
  no shutdown
  

Challenges and Considerations

Enterprises face several challenges when deploying IPv6:

  • Security Policy Updates: Firewalls and IDS/IPS systems need rules for IPv6 traffic.
  • Monitoring and Logging: Tools must be updated to support IPv6 visibility.
  • Application Readiness: Legacy apps may need refactoring or dual-stack proxies.

Recommended Strategy for 2013

Given the state of IPv6 adoption in 2013, the best path forward for most organizations is to enable dual-stack in internal environments first. Then, extend IPv6 to the DMZ and edge. Careful use of tunneling may help with connectivity testing, but it's not suitable as a long-term solution for production.

Final Thoughts

IPv6 is no longer optional for growing networks. With continued adoption by ISPs and cloud providers, enterprises must ensure their infrastructure and policies are ready. A dual-stack approach offers the most flexibility and least risk during this critical transition period.



Eduardo Wnorowski is a network infrastructure consultant and technologist.
With over 18 years of experience in IT and consulting, he brings deep expertise in networking, security, infrastructure, and transformation.
Connect on Linkedin

Sunday, April 2, 2006

Integrating Wireless Security into Enterprise Networks

April 2006 | 6 min read

By 2006, enterprise wireless adoption is no longer speculative—it is strategic. But with this strategic adoption comes an equally strategic risk: security. Wireless LANs introduce vectors that traditional wired networks do not face. Understanding how to address these risks holistically is key for any enterprise network architect.

From rogue AP detection to client authentication, and from VLAN segmentation to WLAN controllers, a wide array of tools are available. Cisco’s Unified Wireless Network architecture becomes a cornerstone for managing both access and policy enforcement, particularly when tied into NAC (Network Admission Control) and RADIUS-based mechanisms.

Layered Wireless Security: The Essential Pillars

Best practices for securing WLANs now revolve around a layered approach:

  • Authentication: 802.1X with EAP variants like PEAP or EAP-TLS.
  • Encryption: WPA2-AES has become the default standard to meet compliance and protect data in transit.
  • Segmentation: Use dynamic VLAN assignments for user types and enforce ACLs per SSID or user role.
  • Monitoring: Deploy WIPS (Wireless Intrusion Prevention Systems) and scan constantly for rogue APs or policy violations.

Lessons from Real-World Deployments

In several large-scale deployments I’ve supported across hospital and banking environments, policy conflicts often arise when wireless overlays do not match the wired segmentation strategy. The key is to ensure that NAC policies and identity-based networking extend consistently into the wireless domain.

Also, don’t overlook RF design. Channel overlap, excessive co-channel interference, or even AP misplacement can degrade performance and increase security exposure. A strong security posture includes RF visibility and monitoring as part of the architecture—not as an afterthought.

As mobility becomes the new baseline, enterprises must view wireless not as an add-on but as a core access layer that deserves its own security strategy. The integration of wireless into the security fabric of the enterprise continues to evolve, and architects must evolve with it.


Eduardo Wnorowski is a technology consultant focused on network and infrastructure. He shares practical insights from the field for engineers and architects.

Network Reliability Engineering: Turning Modern Network Operations into a Discipline Network Reliability Engineering: Turning ...