Mac in Mac Encapsulation
You set up mac in mac encapsulation by wrapping customer frames inside provider headers. Edge switches add an outer MAC header and a service ID to each frame. Network teams use this method to separate customer traffic across shared backbone links. Still, broad admin roles on these edge switches create high security risks. One bad change on a core switch can drop traffic for many customers. How mac in mac encapsulation works in practice Standard Ethernet bridges learn every device address that
Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up mac in mac encapsulation by wrapping customer frames inside provider headers. Edge switches add an outer MAC header and a service ID to each frame. Network teams use this method to separate customer traffic across shared backbone links. Still, broad admin roles on these edge switches create high security risks. One bad change on a core switch can drop traffic for many customers.
How mac in mac encapsulation works in practice
Standard Ethernet bridges learn every device address that passes through their ports. As networks grow, core switches run out of memory to store these addresses. Customer VLAN tags also hit strict limits on large provider backbones. Provider backbone bridges fix this issue by hiding customer addresses from core switches.
The process starts when a customer frame enters a provider edge switch. The edge switch reads the customer VLAN and maps it to a service tag. Next, the switch wraps the whole customer frame inside a new backbone header. This outer header uses the MAC addresses of the provider switches themselves.
Core switches along the path only read this outer backbone header. They forward the packet based on the destination provider switch address. Core switches never learn or store the inner customer MAC addresses. When the packet reaches the far edge switch, that switch strips the outer header. The original frame then exits to the customer site untouched.
What native switch roles solve and what they miss
Network gear includes built-in role controls to guard these backbone settings. Teams set up local user accounts or link switches to central login servers. You can give junior engineers read-only roles to check port states and logs. Senior engineers get full write roles to add service tags and edit trunks.
These native roles solve the basic problem of who can log in. They block unknown users from opening a console session on your edge switches. They also group engineers into broad tiers based on their job titles.
Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Yet login checks leave a big gap during active work sessions. Once an engineer logs in with a write role, the switch trusts every command. Native login tools do not check individual commands in flight before they run. An engineer fixing one customer port can change a shared backbone trunk by mistake. Also, shared admin keys often sit on engineer laptops for months. If a key leaks, an attacker gains full control over all customer traffic paths.
Managing admin sessions on provider edge switches
Securing a backbone requires more than checking who opens a switch session. Teams must also control what happens after the prompt appears on screen. You should limit each task to the exact commands needed for that change. When an engineer needs to check frame counters, grant only read commands.
Good audit logs are also vital when teams manage shared network gear. Standard switch logs often miss the full output of show commands. If sensitive data appears in terminal output, masking should rewrite matched fields in results. For example, masking can rewrite emails, phone numbers, card numbers, or national IDs. Tight controls over active sessions keep human errors from breaking core trunks.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What standard defines mac in mac encapsulation?
The IEEE 802.1ah standard defines this method, which is called Provider Backbone Bridges. It sets the rules for outer MAC headers and 24-bit service instance tags.
Does wrapping frames change the required link MTU size?
Yes, the outer MAC header and service tag add extra bytes to every frame. You must raise the MTU on backbone ports so switches do not drop full-sized packets.
Why do core switches ignore inner customer MAC addresses?
Core switches ignore inner addresses to save hardware table memory and cut broadcast traffic. They only need the outer edge switch addresses to move frames across the backbone.