I think that Juniper logical systems are fantastic. They are a great way to study for certifications. In this post, we’re going to look at what they are, how to connect them together, and how to configure and work with them.
Table of Contents
What Is A Logical System
Logical systems are a way of virtualizing some of the Juniper hardware platforms, essentially turning them into multiple routers. Although this sounds like just they are just a virtual router or routing instance, logical systems are much more powerful and feature-rich.
One of the main software processes on a Juniper device is the Routing Protocol Daemon – RPD. It looks after routing protocols like OSPF and BGP, and the routing tables for the configured routing instances.
When we configure logical systems, each logical system runs its own instance of RPD.
What Can Logical Systems Be Used For
Logical systems are basically used to virtualize one physical device into multiple systems. If needed, these systems can be managed separately by different teams but they don’t have to be.
One example is instead of installing several smaller physical routers into a site, each performing a separate function, one larger physical device is installed and configured with one logical system per function. You might use one logical system for Internet traffic, another for MPLS VPNs, and another for core transit services.
How Have I Used Logical Systems
I use logical systems heavily for learning and made extensive use of them when studying the routing portions of JNCIE exams. Because logical systems support MPLS and related protocols, it is easy to create a good sized MPLS network with only one device, whether that is a physical router or a vMX instance. Using logical systems on one vMX, rather than several vMX instances helps me get more out of my lab devices.
I’ve also used them to test or validate network designs I have been working on, to see whether they behave as I want them to. Whilst there may be some differences or limitations with the logical systems compared to an actual device, they behave close enough for my initial design work.
They can also be useful when working on routing faults. You can build a general approximation of the customer’s network using logical systems and work through how the routing is behaving.
One thing worth noting is that if you just want to practice some basic routing, then routing instances will be fine, and you don’t need to use logical systems, especially if you don’t need their added functionality.
Connecting Logical Systems Together
Before looking at examples of how to configure logical systems, let’s look at how we can connect them together.
The two main ways are to either connect two physical interfaces together or to use logical tunnel (lt-) interfaces.
With the physical interface method, you connect two ports together. For example, you might connect ge-0/0/1 and ge-0/0/2 together. Ideally, you want interfaces that you can create multiple sub-interfaces or units on, so ethernet interfaces with vlans are a good choice.
This is sometimes called using a handbag cable, as the connection between the two physical ports can look like a handle to carry the router around with.
Logical tunnel interfaces are virtual point-to-point interfaces. They are basically a way of looping a packet back through the forwarding plane and are the easiest way to connect logical systems together if you have an lt- interface available.
When configuring a connection using lt- interfaces, you configure two units. These two units represent each end of a point-to-point connection. Each unit should be configured with the encapsulation you want to use and refer to its partner unit with the peer-unit statement. In most cases, you’ll also configure IP addressing.
Some platforms like the M and T series will need some form of services or tunnel PIC to have an lt- interface present. On platforms like the MX and vMX series, you can enable tunnel services on one of the FPCs to provide the logical tunnel interface.
Using logical tunnel interfaces or physical interfaces in this manner provides us with point-to-point connections. We can use a VPLS instance to connect multiple logical systems to the same layer 2 network.
Logical System Configuration Examples
Configuring logical systems is pretty easy. The configuration of most items is exactly the same, just done at a different level of the config hierarchy.
set protocols ospf reference-bandwidth 10gbecomes
set logical-systems LS-A protocols ospf reference-bandwidth 10gLS-A is a user-defined name for the logical system, so it can be anything you want within reason.
One key area of difference, however, is interfaces. The physical interface and its properties are configured under the main or base logical system. The logical interface configuration occurs under the logical system configuration. In short, all of the config you would place under an interface unit is configured under the logical system.
Example 1 – Basic Connectivity
In this example, we’re creating two pairs of logical systems. One pair is connected by logical tunnel interfaces, and the other pair is connected by ethernet interfaces. Each logical system has a loopback address and a static route to the loopback of the logical system it is connected to.
There are a couple things to note with this example. The link-net between each pair of logical systems is the same subnet. Because they are separate systems with separate routing tables this does not cause an issue.
The configuration for this example is listed below.
A few things worth pointing out:
- The physical interfaces ge-0/0/1 and ge-0/0/2 have the physical property vlan-tagging configured under the base system
- All interface logical details, the units, are configured under the logical systems
- All the loopback interfaces use a different unit number. Since there is only one loopback interface, we need to keep the units unique
- Although the ge- interface unit numbers match the vlan-id, this is only for convenience and these two values don’t have to match
interfaces {
ge-0/0/1 {
description "Connected to ge-0/0/2";
vlan-tagging;
}
ge-0/0/2 {
description "Connected to ge-0/0/1";
vlan-tagging;
}
}
logical-systems {
LS-A {
interfaces {
lt-0/0/0 {
unit 1 {
encapsulation ethernet;
peer-unit 2;
family inet {
address 10.0.1.1/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-options {
static {
route 192.168.0.2/32 next-hop 10.0.1.2;
}
}
}
LS-B {
interfaces {
lt-0/0/0 {
unit 2 {
encapsulation ethernet;
peer-unit 1;
family inet {
address 10.0.1.2/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.168.0.2/32;
}
}
}
}
routing-options {
static {
route 192.168.0.1/32 next-hop 10.0.1.1;
}
}
}
LS-C {
interfaces {
ge-0/0/1 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.1/30;
}
}
}
lo0 {
unit 3 {
family inet {
address 192.168.0.3/32;
}
}
}
}
routing-options {
static {
route 192.168.0.4/32 next-hop 10.0.1.2;
}
}
}
LS-D {
interfaces {
ge-0/0/2 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.2/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.4/32;
}
}
}
}
routing-options {
static {
route 192.168.0.3/32 next-hop 10.0.1.1;
}
}
}
}Now that we’ve deployed this config, does it work? Let’s try some pings, and source the traffic from the loopback interfaces. We need to use the logical-system parameter so the router knows which context to use. If you forget to specify the logical system you might get an error saying can’t assign requested address.
lab@vMX-1> ping 192.168.0.2 source 192.168.0.1 count 2 logical-system LS-A
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=2.220 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=42.605 ms
--- 192.168.0.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.220/22.412/42.605/20.192 ms
lab@vMX-1> ping 192.168.0.4 source 192.168.0.3 count 2 logical-system LS-C
PING 192.168.0.4 (192.168.0.4): 56 data bytes
64 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=4.260 ms
64 bytes from 192.168.0.4: icmp_seq=1 ttl=64 time=43.389 ms
--- 192.168.0.4 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.260/23.825/43.389/19.565 msExample 2 – Basic Connectivity And Routing Instances
This expands on the first example by adding routing instances to the logical systems.
Some things of note for the following config
- The routing instances are configured under the logical systems in this example but are usually created under the base system. I’ve done it this way to show what is possible with logical systems.
- The interfaces for the routing instances are configured under the logical system and then referenced in the routing instance.
- The routing instance VR-C inside of LS-C is using ge-0/0/2, rather than ge-0/0/1. I’ve done this to show that it is the logical interface that belongs to the logical system, not the physical interface.
interfaces {
ge-0/0/1 {
description "Connected to ge-0/0/2";
vlan-tagging;
}
ge-0/0/2 {
description "Connected to ge-0/0/1";
vlan-tagging;
}
}
logical-systems {
LS-A {
interfaces {
lt-0/0/0 {
unit 1 {
encapsulation ethernet;
peer-unit 2;
family inet {
address 10.0.1.1/30;
}
}
unit 21 {
encapsulation ethernet;
peer-unit 22;
family inet {
address 10.0.21.1/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.0.1/32;
}
}
unit 21 {
family inet {
address 192.168.0.21/32;
}
}
}
}
routing-instances {
VR-A {
routing-options {
static {
route 192.168.0.22/32 next-hop 10.0.21.2;
}
}
instance-type virtual-router;
interface lt-0/0/0.21;
interface lo0.21;
}
}
routing-options {
static {
route 192.168.0.2/32 next-hop 10.0.1.2;
}
}
}
LS-B {
interfaces {
lt-0/0/0 {
unit 2 {
encapsulation ethernet;
peer-unit 1;
family inet {
address 10.0.1.2/30;
}
}
unit 22 {
encapsulation ethernet;
peer-unit 21;
family inet {
address 10.0.21.2/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.168.0.2/32;
}
}
unit 22 {
family inet {
address 192.168.0.22/32;
}
}
}
}
routing-instances {
VR-B {
routing-options {
static {
route 192.168.0.21/32 next-hop 10.0.21.1;
}
}
instance-type virtual-router;
interface lt-0/0/0.22;
interface lo0.22;
}
}
routing-options {
static {
route 192.168.0.1/32 next-hop 10.0.1.1;
}
}
}
LS-C {
interfaces {
ge-0/0/1 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.1/30;
}
}
}
ge-0/0/2 {
unit 200 {
vlan-id 200;
family inet {
address 10.0.21.1/30;
}
}
}
lo0 {
unit 3 {
family inet {
address 192.168.0.3/32;
}
}
unit 23 {
family inet {
address 192.168.0.23/32;
}
}
}
}
routing-instances {
VR-C {
routing-options {
static {
route 192.168.0.24/32 next-hop 10.0.21.2;
}
}
instance-type virtual-router;
interface ge-0/0/2.200;
interface lo0.23;
}
}
routing-options {
static {
route 192.168.0.4/32 next-hop 10.0.1.2;
}
}
}
LS-D {
interfaces {
ge-0/0/1 {
unit 200 {
vlan-id 200;
family inet {
address 10.0.21.2/30;
}
}
}
ge-0/0/2 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.2/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.4/32;
}
}
unit 24 {
family inet {
address 192.168.0.24/32;
}
}
}
}
routing-instances {
VR-D {
routing-options {
static {
route 192.168.0.23/32 next-hop 10.0.21.1;
}
}
instance-type virtual-router;
interface ge-0/0/1.200;
interface lo0.24;
}
}
routing-options {
static {
route 192.168.0.3/32 next-hop 10.0.1.1;
}
}
}
}Now, let’s test the connectivity between the routing instances. We need to specify both the logical system and the routing instance for the ping command.
lab@vMX-1> ping 192.168.0.22 source 192.168.0.21 count 2 logical-system LS-A routing-instance VR-A
PING 192.168.0.22 (192.168.0.22): 56 data bytes
64 bytes from 192.168.0.22: icmp_seq=0 ttl=64 time=1.514 ms
64 bytes from 192.168.0.22: icmp_seq=1 ttl=64 time=1.916 ms
--- 192.168.0.22 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.514/1.715/1.916/0.201 ms
lab@vMX-1> ping 192.168.0.24 source 192.168.0.23 count 2 logical-system LS-C routing-instance VR-C
PING 192.168.0.24 (192.168.0.24): 56 data bytes
64 bytes from 192.168.0.24: icmp_seq=0 ttl=64 time=4.293 ms
64 bytes from 192.168.0.24: icmp_seq=1 ttl=64 time=3.898 ms
--- 192.168.0.24 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.898/4.096/4.293/0.197 msExample 3 – Adding Routing Protocols
This example is based on the logical systems from example 1, with no routing instances configured. We configure OSPF between LS-A and LS-B, and BGP between LS-C and LS-D.
In both cases, the static routes from example one, pointing to the loopback 0 interfaces, are removed.
The configuration for this is below. Since it isn’t always easy to follow along with just the config, I have created a walkthrough of this logical system configuration as well.
logical-systems {
LS-A {
interfaces {
lt-0/0/0 {
unit 1 {
encapsulation ethernet;
peer-unit 2;
family inet {
address 10.0.1.1/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.0.1/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.1 {
passive;
}
interface lt-0/0/0.1;
}
}
}
}
LS-B {
interfaces {
lt-0/0/0 {
unit 2 {
encapsulation ethernet;
peer-unit 1;
family inet {
address 10.0.1.2/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.168.0.2/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface lt-0/0/0.2;
}
}
}
}
LS-C {
interfaces {
ge-0/0/1 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.1/30;
}
}
}
lo0 {
unit 3 {
family inet {
address 192.168.0.3/32;
}
}
}
}
protocols {
bgp {
group LS-D {
type external;
export export-static;
peer-as 65200;
neighbor 10.0.1.2;
}
}
}
policy-options {
policy-statement export-static {
term statics {
from protocol static;
then accept;
}
term final {
then reject;
}
}
}
routing-options {
static {
route 172.16.0.0/24 reject;
}
autonomous-system 65100;
}
}
LS-D {
interfaces {
ge-0/0/2 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.2/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.4/32;
}
}
}
}
protocols {
bgp {
group LS-C {
type external;
export export-static;
peer-as 65100;
neighbor 10.0.1.1;
}
}
}
policy-options {
policy-statement export-static {
term statics {
from protocol static;
then accept;
}
term final {
then reject;
}
}
}
routing-options {
static {
route 172.16.1.0/24 reject;
}
autonomous-system 65200;
}
}
}To prove all is working as intended, let’s look at the OSPF neighbors from LS-A and its route table. Then look at LS-C’s route table to see if we have a BGP route.
lab@vMX-1> show ospf neighbor logical-system LS-A
Address Interface State ID Pri Dead
10.0.1.2 lt-0/0/0.1 Full 192.168.0.2 128 35
lab@vMX-1> show route logical-system LS-A
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/30 *[Direct/0] 00:17:41
> via lt-0/0/0.1
10.0.1.1/32 *[Local/0] 00:17:41
Local via lt-0/0/0.1
192.168.0.1/32 *[Direct/0] 00:19:10
> via lo0.1
192.168.0.2/32 *[OSPF/10] 00:16:51, metric 1
> to 10.0.1.2 via lt-0/0/0.1
224.0.0.5/32 *[OSPF/10] 00:19:11, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 00:19:11
MultiRecv
lab@vMX-1> show route logical-system LS-C
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/30 *[Direct/0] 00:17:47
> via ge-0/0/1.100
10.0.1.1/32 *[Local/0] 00:17:47
Local via ge-0/0/1.100
172.16.0.0/24 *[Static/5] 00:19:18
Reject
172.16.1.0/24 *[BGP/170] 00:17:45, localpref 100
AS path: 65200 I, validation-state: unverified
> to 10.0.1.2 via ge-0/0/1.100
192.168.0.3/32 *[Direct/0] 00:19:18
> via lo0.3
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 00:19:18
MultiRecv
lab@vMX-1> Differences Between Logical Systems And Routing Instances
The key difference is that a logical system behaves much more like a fully-fledged router. Routing instances simply provide routing table separation or are used for MPLS provider-provisioned VPNs – L3VPN, L2VPN, VPLS, EVPN, etc.
| Logical System | Routing Instance (vrf or virtual router) | |
| Separate instance of RPD | Yes | No |
| Scale | 15 (routing platforms) 32 (security platforms) | Thousands. |
| Supported platforms | MX, vMX, M, T, PTX, and EX9200 series routing platforms, SRX 1400, 1500, 3000, 4000, and 5000 series security platforms. | Exact types of routing instances may vary by platform, but almost all support routing instances of type virtual router |
| Supports resource quotas, eg cpu quota | Yes (On security platforms) | No |
| Supports separate management | Yes | No |
| Supports routing protocols, eg RIP, OSPF, IS-IS, BGP | Yes | Yes |
| Supports MPLS functionality, eg RSVP, LDP, LSPs, VRFs, etc | Yes | No |
| Physical interface configuration | Configured in the base system | Configured in the base system |
| Logical interface configuration | Configured under logical system | Configured under system hosting the routing instance, then referenced in the routing instance |
| Route Leaking | Can’t leak routes between logical systems, Needs a connection configured between the two systems and routing to be configured. | Can leak routes between routing instances in the same system (e.g. you can leak routes between instances in the base system, or between instances in a configured logical system, but can’t leak routes between a routing instance in the base system to a routing instance in a configured logical system). |
Working With Logical Systems
Now that we have logical systems deployed, how do we work with them?
Getting Output From A Logical System
The commands are mostly the same, simply with logical-system <LS-Name> appended to the end.
Below is an example to look at the BGP summary on LS-D
lab@vMX-1> show bgp summary logical-system LS-D
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.1.1 65100 53 53 0 0 22:38 Establ
inet.0: 1/1/1/0
lab@vMX-1> Change CLI To Be In A Logical System
Rather than adding the logical-system parameter to every command you run, you can also change the cli view with the ‘set cli logical-system’ command
This effectively places your cli session “inside” the logical system you specify. Commands are run exactly as if you were in a router as usual. Even the configuration you see is limited to the bounds of the logical system.
Note how the command prompt has changed as well. You can exit this with a ‘clear cli logical-system’.
lab@vMX-1> set cli logical-system LS-D
Logical system: LS-D
lab@vMX-1:LS-D> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.1.1 65100 60 60 0 0 25:56 Establ
inet.0: 1/1/1/0
lab@vMX-1:LS-D> edit
Entering configuration mode
[edit]
lab@vMX-1:LS-D# show
interfaces {
ge-0/0/2 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.2/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.4/32;
}
}
}
}
protocols {
bgp {
group LS-C {
type external;
export export-static;
peer-as 65100;
neighbor 10.0.1.1;
}
}
}
policy-options {
policy-statement export-static {
term statics {
from protocol static;
then accept;
}
term final {
then reject;
}
}
}
routing-options {
static {
route 172.16.1.0/24 reject;
}
autonomous-system 65200;
}
[edit]
lab@vMX-1:LS-D# exit
Exiting configuration mode
lab@vMX-1:LS-D> clear cli logical-system
Cleared default logical system
lab@vMX-1>Restricting A User To A Logical System
By creating login classes and users, it is possible to restrict a user to a specific logical system. This user could then be used as a role account when using RADIUS authentication.
system {
login {
class testclass {
logical-system LS-D;
permissions all;
}
user testuser {
uid 2007;
class testclass;
authentication {
encrypted-password "<PASSWORD HASH REMOVED>"; ## SECRET-DATA
}
}
}
}Now that we’ve created the user, what can they do?
Note how after logging in, the user can’t clear the logical system setting.
$ ssh [email protected]
Password:
Last login: Mon Jan 9 03:55:34 2023 from 10.0.0.1
--- JUNOS 20.4R3-S2.6 Kernel 64-bit JNPR-11.0-20211117.c779bdc_buil
testuser@vMX-1:LS-D> clear cli logical-system
error: You are not a allowed to execute this command
testuser@vMX-1:LS-D>If we try editing the configuration, we only see the logical system LS-D portion of the config file. We can’t add a new interface, or add a new unit to an existing interface. We can only modify the existing interface unit.
testuser@vMX-1:LS-D> edit
Entering configuration mode
[edit]
testuser@vMX-1:LS-D# show interfaces
ge-0/0/2 {
unit 100 {
vlan-id 100;
family inet {
address 10.0.1.2/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.4/32;
}
}
}
[edit]
testuser@vMX-1:LS-D# set interfaces ge-0/0/3 unit 100 description "Test"
error: statement not found 'ge-0/0/3'
error: could not set description
[edit]
testuser@vMX-1:LS-D# set interfaces ge-0/0/2 unit 200 description "Test"
error: statement not found 'unit'
error: could not set description
[edit]
testuser@vMX-1:LS-D# set interfaces ge-0/0/2 unit 100 description "Test"
[edit]
testuser@vMX-1:LS-D# show | compare
[edit logical-systems LS-D interfaces ge-0/0/2 unit 100]
+ description Test;
[edit]
testuser@vMX-1:LS-D#We can add new policy-options and add OSPF configuration. Interestingly, the rollback command is different and only allows us to ‘rollback’ not ‘rollback <version>’.
[edit]
testuser@vMX-1:LS-D# set policy-options policy-statement rp-test then accept
[edit]
testuser@vMX-1:LS-D# show protocols
bgp {
group LS-C {
type external;
export export-static;
peer-as 65100;
neighbor 10.0.1.1;
}
}
[edit]
testuser@vMX-1:LS-D# set protocols ospf area 0 interface lo0.4 passive
[edit]
testuser@vMX-1:LS-D# show protocols
bgp {
group LS-C {
type external;
export export-static;
peer-as 65100;
neighbor 10.0.1.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.4 {
passive;
}
}
}
[edit]
testuser@vMX-1:LS-D# show | compare
[edit logical-systems LS-D interfaces ge-0/0/2 unit 100]
+ description Test;
[edit logical-systems LS-D protocols]
+ ospf {
+ area 0.0.0.0 {
+ interface lo0.4 {
+ passive;
+ }
+ }
+ }
[edit logical-systems LS-D policy-options]
+ policy-statement rp-test {
+ then accept;
+ }
[edit]
testuser@vMX-1:LS-D# rollback ?
Possible completions:
<[Enter]> Execute this command
| Pipe through a command
[edit]
testuser@vMX-1:LS-D# show | compare
[edit logical-systems LS-D interfaces ge-0/0/2 unit 100]
+ description Test;
[edit logical-systems LS-D protocols]
+ ospf {
+ area 0.0.0.0 {
+ interface lo0.4 {
+ passive;
+ }
+ }
+ }
[edit logical-systems LS-D policy-options]
+ policy-statement rp-test {
+ then accept;
+ }
[edit]
testuser@vMX-1:LS-D# rollback 0
^
syntax error, expecting <command>.
[edit]
testuser@vMX-1:LS-D# rollback
load complete
[edit]
testuser@vMX-1:LS-D# show | compare
[edit]
testuser@vMX-1:LS-D#Logical System Log Files And Traceoption Files
The logging from the new logical systems is found in the messages log as per normal and should look similar to the following
Jan 9 02:33:06 vMX-1 LS-D:rpd[8842]: RPD_RT_HWM_NOTICE: New RIB highwatermark for unique destinations: 6 [2023-01-09 02:32:39]
Jan 9 02:33:06 vMX-1 LS-D:rpd[8842]: RPD_RT_HWM_NOTICE: New RIB highwatermark for routes: 6 [2023-01-09 02:32:39]The traceoptions files can be found in /var/log/<logical system name>/. The show log command already looks under /var/log so we simply add the directory and filename. Below you can see both the traceoptions configuration and some output from the tracefile.
ab@vMX-1> show configuration logical-systems LS-D protocols bgp
group LS-C {
type external;
export export-static;
peer-as 65100;
neighbor 10.0.1.1;
}
traceoptions {
file bgp-traceoptions size 1m files 10;
flag packets;
}
lab@vMX-1> show log LS-D/bgp-traceoptions | last 10
Jan 9 04:27:22.368589 BGP RECV message type 4 (KeepAlive) length 19
Jan 9 04:27:50.403761
Jan 9 04:27:50.403761 BGP RECV 10.0.1.1+179 -> 10.0.1.2+62187
Jan 9 04:27:50.403781 BGP RECV message type 4 (KeepAlive) length 19
Jan 9 04:28:16.826629
Jan 9 04:28:16.826629 BGP RECV 10.0.1.1+179 -> 10.0.1.2+62187
Jan 9 04:28:16.826651 BGP RECV message type 4 (KeepAlive) length 19
Jan 9 04:28:45.486382
Jan 9 04:28:45.486382 BGP RECV 10.0.1.1+179 -> 10.0.1.2+62187
Jan 9 04:28:45.486406 BGP RECV message type 4 (KeepAlive) length 19
lab@vMX-1>Review
In this post we have looked at:
- What logical systems are
- What they can be used for
- How to connect them
- Example configuration
- How to work with logical systems
It’s been a bit of a whirlwind tour, but I hope you now feel comfortable trying out logical systems for yourself.