Junos Logical Systems and Virtual Routers Explained

Junos has four different ways to partition one physical device, and their names are similar enough that design documents get them wrong. The choice matters: logical systems give you separate routing processes and separate administrators, virtual routers give you separate routing tables with one process, VRF-Lite gives you routing separation without management separation, and virtual switches do it for Layer 2. This article maps the four technologies to the problem each one solves, then shows the configuration that actually commits.

The Four Partitioning Models

The key structural difference is that a logical system supports multiple routing instances and is created with its own routing process (rpd) and its own administrative domain, while a tenant system supports exactly one routing instance but scales to far more tenants per box because they share a single routing process. That trade-off — features versus density — is the whole reason both exist.

When a Virtual Router Is Enough

If the goal is simply "keep these interfaces in their own routing table with no leakage", a virtual-router instance is the cheapest option: no VRF targets, no route distinguishers, no import/export policy required.

set routing-instances CUST-A instance-type virtual-router
set routing-instances CUST-A interface ge-0/0/1.10
set routing-instances CUST-A interface ge-0/0/2.20
set routing-instances CUST-A routing-options static route 0.0.0.0/0 next-hop 192.0.2.1

set routing-instances CUST-B instance-type virtual-router
set routing-instances CUST-B interface ge-0/0/1.20

commit check && commit

show route instance
show route table CUST-A.inet.0 brief
show interfaces ge-0/0/1.10 detail | match "Routing instance"
ping 192.0.2.1 routing-instance CUST-A count 3
traceroute 8.8.8.8 routing-instance CUST-B no-resolve

Remember that on EX-series switches only the virtual-router instance type is supported, and that binding an interface to a routing instance with family ethernet-switching will shut the interface down — the classic mistake when a switch port is meant to be routed but is still configured as a switchport.

Logical Systems: Separate Routing Processes

# 1. Create the logical system and its admin
set logical-systems SP-TENANT-1 interfaces ge-0/0/3 unit 0
set logical-systems SP-TENANT-1 interfaces ge-0/0/3 unit 0 family inet address 198.51.100.2/30

# 2. Give the tenant administrator credentials limited to the logical system
set system login user tenant1 class j-super-user
set system login user tenant1 uid 2001
set system login user tenant1 authentication plain-text-password
set system login user tenant1 logical-system SP-TENANT-1

# 3. Tenant-side routing inside the logical system
set logical-systems SP-TENANT-1 protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set logical-systems SP-TENANT-1 routing-options static route 0.0.0.0/0 next-hop 198.51.100.1

commit

Operating inside a logical system is a matter of prefixing commands:

show logical-systems SP-TENANT-1 route summary
show logical-systems SP-TENANT-1 interfaces terse
set cli logical-system SP-TENANT-1     # drop into that context
ping logical-system SP-TENANT-1 198.51.100.1

Two limitations to design around. First, the primary administrator owns the physical resources — interfaces, class-of-service, firewall filters that live at the physical level — and allocates them to logical systems; a logical system cannot invent interfaces. Second, not every feature is virtualised: some platform-specific and hardware-offload features remain global. Check the Feature Explorer for the exact release and platform, because logical-system support differs substantially between EX, MX and SRX.

Interconnecting Logical Systems

Traffic between two logical systems on the same device must leave one context and enter another, and that requires either physical loopback cabling or an lt- logical tunnel interface:

set interfaces lt-0/0/0 unit 0 encapsulation ethernet
set interfaces lt-0/0/0 unit 0 peer-unit 1
set logical-systems SP-TENANT-1 interfaces lt-0/0/0 unit 0 family inet address 10.255.0.1/30
set logical-systems SP-TENANT-2 interfaces lt-0/0/0 unit 1 family inet address 10.255.0.2/30

Without a peer interface the two logical systems are completely isolated, which is correct security behaviour but surprises people who expect them to route to each other like VRFs with route leaking.

Choosing, in Practice

• One customer, one management domain, rich routing features: logical system.
• Hundreds of small tenants on a security device: tenant systems (vSRX / Virtual Firewall 3.0), accepting one routing instance each.
• Segmenting your own networks, no separate admins: virtual-router instances.
• L2 separation between tenants: virtual switch instances.
• Migrating from an old design: do not convert everything at once; virtual-router instances can be moved into logical systems later, but the reverse migration is disruptive.

Verification Checklist

1. show route instance lists every instance with the expected interfaces and route counts.
2. Each tenant user can log in and sees only its own instance (show cli inside the session).
3. No routes leak between instances — verify with show route table X.inet.0 rather than assuming policy is correct.
4. Resource allocation (interfaces, filters, policers) is documented per logical system.
5. commit check passes after a reboot test in a lab, because logical-system configurations fail on boot far more often than they fail interactively.

Related reading: Junos firewall filters, Junos rollback and revision identifiers and Junos VRRP configuration.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/logical-system-security/topics/topic-map/tenant-systems-overview.html