Can any one guide me to learn the technical difference between virtual router and logical router?
J-series and M-series routers support both ?
- Logical router (called now logical system ... from 9.3) and virtual router exists in M and T series.
- In J series you only have virtual routers.
The main difference between them is that logical router configuration activate a new routing deamon in the router, birual router doesn't. Saying that if you activate a logical router that have a problem , if it crashes , there will be no impact on the other ones (the main one ... regular config, or others logical routers.
The other difference is in the way to configure them.
The logical router is configured exactly like the main router but under the [edit logical-systems Name] logical interfaces included.
The virtual router is configured under [edit routing-instances Name] you add a ref to the interfaces ther but the logical configuration of the interfaces itself is done under the main router.
You can find two different examples there:
On top of what Loup2 indicated, here's some additional tips:
- you can configure users to be able to connect to a particular logical-system. To do so, simply define a new class and include the "logical-system" statement under the class' configuration. Also, you can use the 'set cli logical-system xxx' knob in operation mode to restrict your CLI to a particular logical-system. To fall back, simply do a 'clear cli logical-system'
- you can't leak routes between a logical-system and the main instance. To exchange routes between a logical-system and the 'main' router, you need to either configure a logical tunnel (lt-) interface (available with a services or a tunnel PIC) or build an external physical connection.
- For an interface to be able to used in a logical-system, it first needs to be configured in [edit interfaces] stenza (main router). The minimal configuration (e.g. "set interfaces ge-0/0/0 description "logical-system L1") will be enough.
- You can't configure some statements (e.g. class-of-service, snmp ) because those aren't aware of logical systems. These need to be configured under the main configuration and will work as expected within logical systems; it's just the place in the configuration that is not supported.
- Sampling, port mirroring, IP Security (IPSEC), adaptive services, are not supported. You cannot configure sampling or export cflow records for traffic within a logical router.
- To query a logical-system via SNMP, you need to use the SNMP community like LS-NAME@community
As for virtual routers, they act like layer3 vpns that are not signalled via BGP to other PEs. Unlike logical-systems, you can leak routes between a VR and the main instance using either rib-groups or instance-import and instance-export statements.
Thanks for answering. Can you people explain what are the practical scenarios in which we use virtual router and where we use logical routers and why?
Think of logical routers as a super-set of a virtual router. ie: You can run routing-instances in each logical router.
In general, most tasks are efficiently handled by routing-instances (virtual routers) in JUNOS. However, LRs add a couple features:
note: both LR and routing-instances have exactly the same hardware separation at the data-plane, the difference is 100% control plane. Both LR and VR share the same FIB resources, so a LR will not help control scalability of the number of prefixes or next-hops in hardware.
- a separate copy of RPD, so if there is an issue in one LR, the RPD in another is not affected (process separation)
- CLI partition with user access control: a LR has a different hierarchy in the CLI, and you can restrict users to one or another
- MPLS core protocol separation requires an LR, not just a routing-instance. If you want one Juniper router to behave as two MPLS nodes (ie: separate P and PE functions between two routers), you will need logical routers
- Logical routers are only supported on the M/T/MX series. You cannot use an LR in the J series. I'm also not sure if it's fully supported in the SRX series currently.
- JUNOS feature support in LRs versus the root routing instance is not 100%. There are some things that aren't supported in an LR context. Although this has been a strong focus of development recently, so the gap is narrowing with many releases
- JUNOS requires you to /purchase/ a logical-router right-to-use license per chassis.
* routing-instances are free in JUNOS, logical routers are /NOT/
Also, it's worth pointing out that earlier this year, Juniper renamed the "Logical Router" to the "Logical System" in JUNOS. It's the same feature, but the name has been expanded to support JUNOS devices that aren't necessarily "routers" (such as the EX series, SRX, etc).
Finally, there is a third form of system virtualization called the Hardware Logical Router, or "Protected System Domain". This is something that is only supported on the T series currently, and requires an external control plane chassis called the JCS, or "Juniper Control System". This allows for both data-plane and control-plane separation between logical routers, and also dedicates a separate routing-engine (CPU complex, route-processor) for each protected system domain (PSD). One of the biggest advantages of a PSD is that each PSD has its own scaling numbers, and is also a descrete maintenance domain. For instance, you can upgrade the version of JUNOS in one PSD, while the other PSDs remain unaffected (this includes updating the firmware on the associated linecards and PICs).
In terms of applications:
Simple routing-instances (virtual routers) are normally used for most tasks when you need to separate routing, such as MPLS L3VPN (private IP services), or simply mutiple route table support (what cisco calls VRF-lite, or Multi-VRF).
Logical routers are normally used when you are taking the functions of two descrete routers, and collapsing them into a single chassis. Think of a provider PoP where you may have one pair of routers for external peering, and another pair of routers for backbone connectivity to the provider's core network. In this case, you could leverage the Logical Router (aka: Logical System) support to make one instance of an internal core router and one instance of an edge peering router in the same chassis. The advantage is that they are still run as two separate processes and can have different user permissions.