In the post on logical systems, I provided three examples. In this post, we are going to walk through in detail how to configure the third example.
It consists of two pairs of logical systems, one pair using OSPF and the other using BGP.
This walkthrough is being done on a vMX that has a factory default config, with a little bit of management config applied to it.
Physical Interfaces
Firstly, let’s check if we have a logical tunnel (lt-) interface. We can do this by either matching the output of show interface terse, or we can use a wildcard on the interface – lt*.
lab@vMX-2> show interfaces terse | match lt-
lab@vMX-2> show interfaces lt* terse
lab@vMX-2>As you can see, there is no logical tunnel interface available. Next, let’s check if we have the ge interfaces we’ll need.
lab@vMX-2> show interfaces ge* terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.16386 up up
ge-0/0/1 up up
ge-0/0/1.16386 up up
ge-0/0/2 up up
ge-0/0/2.16386 up up
ge-0/0/3 up up
ge-0/0/3.16386 up up
ge-0/0/4 up up
ge-0/0/4.16386 up up
ge-0/0/5 up up
ge-0/0/5.16386 up up
ge-0/0/6 up up
ge-0/0/6.16386 up up
ge-0/0/7 up up
ge-0/0/7.16386 up up
ge-0/0/8 up up
ge-0/0/8.16386 up up
ge-0/0/9 up up
ge-0/0/9.16386 up up
lab@vMX-2> show configuration interfaces ge-0/0/1
lab@vMX-2> show configuration interfaces ge-0/0/2
lab@vMX-2>We have the ge interfaces we need, but they don’t have any configuration.
Since we are using a vMX we can configure tunnel services under one of the FPCs to provide an lt- interface. We will also configure the ge interfaces we need with vlan-tagging. This vlan-tagging does not make the interfaces a trunk port, instead, it makes the interfaces vlan aware, so we can configure units underneath them with vlan ids. Note that this is done at the base level of the config, not under a logical system.
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# set chassis fpc 0 pic 0 tunnel-services
[edit]
lab@vMX-2# set interfaces ge-0/0/1 vlan-tagging
[edit]
lab@vMX-2# set interfaces ge-0/0/2 vlan-tagging
[edit]
lab@vMX-2# show | compare
[edit]
+ chassis {
+ fpc 0 {
+ pic 0 {
+ tunnel-services;
+ }
+ }
+ }
[edit interfaces]
+ ge-0/0/1 {
+ vlan-tagging;
+ }
+ ge-0/0/2 {
+ vlan-tagging;
+ }
[edit]
lab@vMX-2# commit and-quit
commit complete
Exiting configuration mode
lab@vMX-2>Now that we have configured tunnel services, we need to check again for an lt- interface.
lab@vMX-2> show interfaces terse | match lt-
lt-0/0/0 up up
lab@vMX-2> show interfaces lt* terse
Interface Admin Link Proto Local Remote
lt-0/0/0 up up
lab@vMX-2>Perfect. We now have an lt- interface we can connect our first pair of logical systems.
Configuring The Logical Systems
Before we configure our logical systems, we can show how many instances of RPD we have running by looking at the system processes. Note how there is only one instance of rpd running.
lab@vMX-2> show system processes detail | match rpd
8760 0 8625 0 20 0 107368 kqread 03:09 - S 0:01.45 /usr/sbin/rpd -N
8795 0 8625 0 20 0 9488 kqread 03:09 - S 0:00.09 /usr/sbin/rpdtmd -N
lab@vMX-2>The next step is to start configuring the logical systems themselves. In the below output, we configure the interfaces of LS-A.
Note the following:
- For the loopback interface, we did not specify a prefix length or subnet mask for the IP address. Because we left it off, Junos assumed a /32
- The interfaces did not already exist at this level of the config hierarchy, and so they needed to be typed out in full, not auto-completed
- All of the commands were run from the top of the configuration hierarchy
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# set logical-systems LS-A interfaces lo0 unit 1 family inet address 192.168.0.1
[edit]
lab@vMX-2# set logical-systems LS-A interfaces lt-0/0/0 unit 1 encapsulation ethernet
[edit]
lab@vMX-2# set logical-systems LS-A interfaces lt-0/0/0 unit 1 peer-unit 2
[edit]
lab@vMX-2# set logical-systems LS-A interfaces lt-0/0/0 unit 1 family inet address 10.0.1.1/30
[edit]
lab@vMX-2# show | compare
[edit]
+ 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;
+ }
+ }
+ }
+ }
+ }
+ }
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#Now that we have done LS-A, we should move on to LS-B. The config is very similar to LS-A for the interfaces.
Note the following:
- We moved down the config hierarchy to LS-B at the start, which makes all of the following commands shorter as we do not have to specify the logical system
- The lo0 address did have a /32 specified this time
- The lt-0/0/0 interface config was done as a single line specifying several statements, rather than doing one statement per line as we did with LS-A
[edit]
lab@vMX-2# edit logical-systems LS-B
[edit logical-systems LS-B]
lab@vMX-2# set interfaces lo0 unit 2 family inet address 192.168.0.2/32
[edit logical-systems LS-B]
lab@vMX-2# set interfaces lt-0/0/0 unit 2 encapsulation ethernet peer-unit 1 family inet address 10.0.1.2/30
[edit logical-systems LS-B]
lab@vMX-2# top
[edit]
lab@vMX-2# show | compare
[edit logical-systems]
+ 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;
+ }
+ }
+ }
+ }
+ }
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#At this stage, we now have two logical systems created and they are connected by an lt- interface. We should see an additional two instances of RPD running. Since we are still in configuration mode, we need to start with ‘run’ to run the operational mode command ‘show system processes’. You can see there are additional instances of RPD running.
[edit]
lab@vMX-2# run show system processes detail | match rpd
8760 0 8625 0 20 0 107392 kqread 03:09 - S 0:01.63 /usr/sbin/rpd -N
8795 0 8625 0 20 0 9508 kqread 03:09 - S 0:00.09 /usr/sbin/rpdtmd -N
9629 0 8625 0 20 0 107320 kqread 04:31 - S 0:00.78 /usr/sbin/rpd -N -JLLS-A
9704 0 8625 0 20 0 107324 kqread 04:36 - S 0:00.64 /usr/sbin/rpd -N -JLLS-B
[edit]
lab@vMX-2#We can test the logical systems by trying to ping the other end of the lt- interface they are configured with. We can’t ping the remote loopback addresses as we do not have any routes configured for those yet. I have already exited out of config mode, so the commands do not need to be preceded with ‘run’.
lab@vMX-2> ping 10.0.1.2 count 2 logical-system LS-A
PING 10.0.1.2 (10.0.1.2): 56 data bytes
64 bytes from 10.0.1.2: icmp_seq=0 ttl=64 time=2.234 ms
64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=1.236 ms
--- 10.0.1.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.236/1.735/2.234/0.499 ms
lab@vMX-2> ping 10.0.1.1 count 2 logical-system LS-B
PING 10.0.1.1 (10.0.1.1): 56 data bytes
64 bytes from 10.0.1.1: icmp_seq=0 ttl=64 time=2.126 ms
64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=1.195 ms
--- 10.0.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.195/1.660/2.126/0.466 ms
lab@vMX-2>We can look at the routing tables as well, again we need to specify the logical system.
lab@vMX-2> show route logical-system LS-A
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/30 *[Direct/0] 00:10:47
> via lt-0/0/0.1
10.0.1.1/32 *[Local/0] 00:10:47
Local via lt-0/0/0.1
192.168.0.1/32 *[Direct/0] 00:15:37
> via lo0.1
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 00:15:37
MultiRecv
lab@vMX-2> show route logical-system LS-B
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/30 *[Direct/0] 00:10:49
> via lt-0/0/0.2
10.0.1.2/32 *[Local/0] 00:10:49
Local via lt-0/0/0.2
192.168.0.2/32 *[Direct/0] 00:10:49
> via lo0.2
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 00:10:49
MultiRecv
lab@vMX-2>Now we can configure LS-C and LS-D. These are using physical interfaces rather than logical tunnels.
Note the following:
- For the ge interfaces the unit number and vlan-id match. This is for convenience only, and they can be different values
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# set logical-systems LS-C interfaces lo0 unit 3 family inet address 192.168.0.3
[edit]
lab@vMX-2# set logical-systems LS-C interfaces ge-0/0/1 unit 100 vlan-id 100 family inet address 10.0.1.1/30
[edit]
lab@vMX-2# set logical-systems LS-D interfaces lo0 unit 4 family inet address 192.168.0.4
[edit]
lab@vMX-2# set logical-systems LS-D interfaces ge-0/0/2 unit 100 vlan-id 100 family inet address 10.0.1.2/30
[edit]
lab@vMX-2# show | compare
[edit logical-systems]
+ 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;
+ }
+ }
+ }
+ }
+ }
+ 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;
+ }
+ }
+ }
+ }
+ }
[edit]
lab@vMX-2# commit and-quit
commit complete
Exiting configuration mode
lab@vMX-2>Let’s now look at the routing tables for LS-C and LS-D. The output is very similar to the first pair of logical systems we configured. The interface addressing overlaps on purpose to help show the routing tables are completely separate between the logical systems.
lab@vMX-2> show route logical-system LS-C
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/30 *[Direct/0] 00:02:19
> via ge-0/0/1.100
10.0.1.1/32 *[Local/0] 00:02:19
Local via ge-0/0/1.100
192.168.0.3/32 *[Direct/0] 00:02:19
> 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:02:19
MultiRecv
lab@vMX-2> show route logical-system LS-D
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/30 *[Direct/0] 00:02:22
> via ge-0/0/2.100
10.0.1.2/32 *[Local/0] 00:02:22
Local via ge-0/0/2.100
192.168.0.4/32 *[Direct/0] 00:02:22
> via lo0.4
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 00:02:22
MultiRecv
lab@vMX-2> Just configuring the interfaces isn’t very exciting. So next we’re going to spice things up by adding routing protocols. We’ll start with LS-A and LS-B by adding OSPF.
Note the following:
- For LS-A we again used the full commands
- For LS-B we edited down to the ospf stanza, then used ‘top’ to go to the top of the configuration.
- The loopback interfaces were configured as passive so the interface address will be advertised into OSPF, but the router will not try to form an adjacency over the loopback interface.
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# set logical-systems LS-A protocols ospf area 0 interface lo0.1 passive
[edit]
lab@vMX-2# set logical-systems LS-A protocols ospf area 0 interface lt-0/0/0.1
[edit]
lab@vMX-2# edit logical-systems LS-B protocols ospf
[edit logical-systems LS-B protocols ospf]
lab@vMX-2# set area 0 interface lo0.2 passive
[edit logical-systems LS-B protocols ospf]
lab@vMX-2# set area 0 interface lt-0/0/0.2
[edit logical-systems LS-B protocols ospf]
lab@vMX-2# top
[edit]
lab@vMX-2# commit and-quit
commit complete
Exiting configuration mode
lab@vMX-2>In the following output, you can see that LS-A has an OSPF neighbor and it has an OSPF route in the route table. By pinging the remote loopback address and sourcing the ping from the local loopback address we prove that both logical systems have a route to the loopback addresses.
lab@vMX-2> 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 39
lab@vMX-2> 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:40:37
> via lt-0/0/0.1
10.0.1.1/32 *[Local/0] 00:40:37
Local via lt-0/0/0.1
192.168.0.1/32 *[Direct/0] 00:45:27
> via lo0.1
192.168.0.2/32 *[OSPF/10] 00:02:10, metric 1
> to 10.0.1.2 via lt-0/0/0.1
224.0.0.5/32 *[OSPF/10] 00:03:01, 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:45:27
MultiRecv
lab@vMX-2> 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=7.519 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=3.988 ms
--- 192.168.0.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.988/5.753/7.519/1.766 ms
lab@vMX-2>For the LS-C and LS-D routers, we are going to configure BGP. This is slightly more involved than OSPF. We’ll start with LS-C first and will configure the autonomous system number, a static route to advertise to LS-D, a policy to advertise the route, and finally the BGP peering session.
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# set logical-systems LS-C routing-options autonomous-system 65100
[edit]
lab@vMX-2# set logical-systems LS-C routing-options static route 172.16.0.0/24 reject
[edit]
lab@vMX-2# set logical-systems LS-C policy-options policy-statement export-static term statics from protocol static
[edit]
lab@vMX-2# set logical-systems LS-C policy-options policy-statement export-static term statics then accept
[edit]
lab@vMX-2# set logical-systems LS-C policy-options policy-statement export-static term final then reject
[edit]
lab@vMX-2# set logical-systems LS-C protocols bgp group LS-D type external
[edit]
lab@vMX-2# set logical-systems LS-C protocols bgp group LS-D peer-as 65200
[edit]
lab@vMX-2# set logical-systems LS-C protocols bgp group LS-D export export-static
[edit]
lab@vMX-2# set logical-systems LS-C protocols bgp group LS-D neighbor 10.0.1.2
[edit]
lab@vMX-2# show | compare
[edit logical-systems LS-C]
+ 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;
+ }
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#Next, we will configure LS-D. We’ll edit our way down the hierarchy for this example.
[edit]
lab@vMX-2# edit logical-systems LS-D
[edit logical-systems LS-D]
lab@vMX-2# set routing-options autonomous-system 65200
[edit logical-systems LS-D]
lab@vMX-2# set routing-options static route 172.16.1.0/24 reject
lab@vMX-2# set policy-options policy-statement export-static term statics from protocol static
[edit logical-systems LS-D]
lab@vMX-2# set policy-options policy-statement export-static term statics then accept
[edit logical-systems LS-D]
lab@vMX-2# set policy-options policy-statement export-static term final then reject
[edit logical-systems LS-D]
lab@vMX-2# edit protocols bgp group LS-C
[edit logical-systems LS-D protocols bgp group LS-C]
lab@vMX-2# set type external export export-static peer-as 65100 neighbor 10.0.1.1
[edit logical-systems LS-D protocols bgp group LS-C]
lab@vMX-2# top
[edit]
lab@vMX-2# show | compare
[edit logical-systems LS-D]
+ 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-2# commit
commit complete
[edit]
lab@vMX-2# exit
Exiting configuration mode
lab@vMX-2>Now that BGP is configured on both LS-C and LS-D, we can look at the status of BGP on each of them, and their route tables to see what is different.
Note the following:
- The normal state for a working BGP connection is Established
- BGP may take some time to move to the Established state, be patient and wait a few minutes if it has not come up immediately
- You should see 1 route being received, as shown in the output below
- There should be a single BGP route in each routing table
lab@vMX-2> show bgp summary logical-system LS-C
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.2 65200 6 5 0 0 1:00 Establ
inet.0: 1/1/1/0
lab@vMX-2> 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:25:21
> via ge-0/0/1.100
10.0.1.1/32 *[Local/0] 00:25:21
Local via ge-0/0/1.100
172.16.0.0/24 *[Static/5] 00:06:33
Reject
172.16.1.0/24 *[BGP/170] 00:01:03, 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:25:21
> 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:25:21
MultiRecv
lab@vMX-2> 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 5 5 0 0 1:13 Establ
inet.0: 1/1/1/0
lab@vMX-2> show route logical-system LS-D
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:25:32
> via ge-0/0/2.100
10.0.1.2/32 *[Local/0] 00:25:32
Local via ge-0/0/2.100
172.16.0.0/24 *[BGP/170] 00:01:14, localpref 100
AS path: 65100 I, validation-state: unverified
> to 10.0.1.1 via ge-0/0/2.100
172.16.1.0/24 *[Static/5] 00:01:25
Reject
192.168.0.4/32 *[Direct/0] 00:25:32
> via lo0.4
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 00:25:32
MultiRecv
lab@vMX-2> And now for a gotcha that can catch people out. When I configured the BGP settings for LS-D, I combined several statements into one line. I added the ‘neighbor’ statement last. Below I’ll configure two additional BGP peers, one like I did for LS-D, and one with the neighbor statement second, as it didn’t like it being first and followed by ‘type external’.
After a show | compare to show the difference in config, I use a rollback 0 to get rid of the uncommitted change.
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# edit logical-systems LS-D protocols bgp
[edit logical-systems LS-D protocols bgp]
lab@vMX-2# edit group test-group-1
[edit logical-systems LS-D protocols bgp group test-group-1]
lab@vMX-2# set type external export export-static peer-as 65300 neighbor 10.10.10.10
[edit logical-systems LS-D protocols bgp group test-group-1]
lab@vMX-2# up
[edit logical-systems LS-D protocols bgp]
lab@vMX-2# edit group test-group-2
[edit logical-systems LS-D protocols bgp group test-group-2]
lab@vMX-2# set neighbor 10.10.10.10 type external export export-static peer-as 65300
^
syntax error.
[edit logical-systems LS-D protocols bgp group test-group-2]
lab@vMX-2# set type external neighbor 10.10.10.10 export export-static peer-as 65300
[edit logical-systems LS-D protocols bgp group test-group-2]
lab@vMX-2# up
[edit logical-systems LS-D protocols bgp]
lab@vMX-2# show
group LS-C {
type external;
export export-static;
peer-as 65100;
neighbor 10.0.1.1;
}
group test-group-1 {
type external;
export export-static;
peer-as 65300;
neighbor 10.10.10.10;
}
group test-group-2 {
type external;
neighbor 10.10.10.10 {
export export-static;
peer-as 65300;
}
}
[edit logical-systems LS-D protocols bgp]
lab@vMX-2# top
[edit]
lab@vMX-2# rollback 0
load complete
[edit]
lab@vMX-2# show | compare
[edit]
lab@vMX-2# Notice how test-group-1 and test-group-2 are different. Under test-group-1 all of the statements are at the same level, just sitting under the group. For test-group-2 however, the peer-as and export policy is configured under the neighbor statement. Depending on your configuration, this can result in two different outcomes.
This is because the export and peer-as statements can occur at several levels of the configuration, they may be placed at the bgp group level and at the neighbor level. If you are trying to put all of those statements in as one line of config, you need to be careful about the ordering of them.
Review
So what have we managed to achieve with this walk-through? We have:
- Configured two pairs of logical systems, not that you have to deploy them in pairs
- Connected one pair using logical tunnel interfaces, and the other pair using physical interfaces
- Setup OSPF on one pair
- Setup BGP, a static route and policy on the second pair
- Explored working from the top of the configuration, or editing our way down to lower portions of the config to shorten our commands
- Observed how the order is important when combining multiple configuration statements onto one line
For more information, have a look at the post on logical systems.