Junos Fusion – Part III – Satellite commands and traffic forwarding
This is the third part of the series covering Junos Fusion.
The first and second parts covered the basics and how to bring up and verify that Junos Fusion is working properly.
This part is a long one and it will cover:
Traffic forwarding and verification
This is the diagram:
The EX4300 is an MC-LAG downstream switch and LACP_SW is a switch that has a LAG interface towards one of the satellites of the JFE.
Keep in mind that in case of Junos Fusion Enterprise, the LAG members must be on the same satellite.
In case of Junos Fusion Datacenter and Provider Edge, the LAG members can be distributed among satellites.
The EX9200 are running VRRP and EX9200-1 is the master:
[edit]
root@EX9200-1# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
irb.1016 up 16 master Active A 0.609 lcl 192.168.16.2
vip 192.168.16.1
irb.1024 up 24 master Active A 0.880 lcl 192.168.24.2
vip 192.168.24.1
[edit]
root@EX9200-1#
[edit]
root@EX9200-2# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
irb.1016 up 16 backup Active D 2.686 lcl 192.168.16.3
vip 192.168.16.1
mas 192.168.16.2
irb.1024 up 24 backup Active D 2.846 lcl 192.168.24.3
vip 192.168.24.1
mas 192.168.24.2
[edit]
root@EX9200-2#
ICCP is configured between the two EX9200. This is from EX9200-1 and the configuration is similar on EX9200-2:
[edit]
root@EX9200-1# show protocols iccp
local-ip-addr 192.168.0.33;
peer 192.168.0.34 {
session-establishment-hold-time 50;
redundancy-group-id-list 1;
backup-liveness-detection {
backup-peer-ip 10.16.192.156;
}
liveness-detection {
minimum-interval 2000;
multiplier 4;
}
}
[edit]
root@EX9200-1# run show iccp
Redundancy Group Information for peer 192.168.0.34
TCP Connection : Established
Liveliness Detection : Up
Backup liveness peer status: Up
Redundancy Group ID Status
1 Up
Client Application: lacpd
Redundancy Group IDs Joined: 1
Client Application: l2ald_iccpd_client
Redundancy Group IDs Joined: 1
Client Application: DOT1XD
Redundancy Group IDs Joined: None
[edit]
root@EX9200-1#
The MC-AE interface is configured like show below. Again this is from EX9200-1 and the second AD must be configured in an identical way. The operational output is identical on the second AD(except the interface number as you can see on the diagram):
[edit]
root@EX9200-1# show interfaces ae1
aggregated-ether-options {
lacp {
active;
system-id 00:00:00:00:00:01;
admin-key 1;
}
mc-ae {
mc-ae-id 1;
redundancy-group 1;
chassis-id 0;
mode active-active;
status-control active;
init-delay-time 240;
events {
iccp-peer-down {
prefer-status-control-active;
}
}
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members all;
}
}
}
[edit]
root@EX9200-1# run show lacp interfaces ae1
Aggregated interface: ae1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
xe-0/0/6 Actor No No Yes Yes Yes Yes Fast Active
xe-0/0/6 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
xe-0/0/6 Current Fast periodic Collecting distributing
[edit]
root@EX9200-1#
This is how the LAG is configured and there is nothing special about it. You just need to use the right extended ports from the satellite. Exactly the same configuration must be used on the second AD:
[edit]
root@EX9200-1# show interfaces ge-75/0/0
ether-options {
802.3ad ae2;
}
[edit]
root@EX9200-1# show interfaces ge-75/0/6
ether-options {
802.3ad ae2;
}
[edit]
root@EX9200-1# show interfaces ae2
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members all;
}
}
}
[edit]
root@EX9200-1# run show lacp interfaces ae2
Aggregated interface: ae2
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-75/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-75/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-75/0/6 Actor No No Yes Yes Yes Yes Fast Active
ge-75/0/6 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-75/0/0 Current Fast periodic Collecting distributing
ge-75/0/6 Current Fast periodic Collecting distributing
[edit]
root@EX9200-1#
On the JFE external devices(except the OSPF speaking devices), there are two routing-instances, each containing an interface that has an IP address from one of the subnets(shown on the diagram) and a default route pointing to the VRRP VIP. This is from the EX4300:
{master:0}[edit]
root@EX4300# show routing-instances
v1016 {
##
## Warning: requires 'virtual-router' license
##
instance-type virtual-router;
interface irb.1016;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.16.1;
}
}
}
v1024 {
##
## Warning: requires 'virtual-router' license
##
instance-type virtual-router;
interface irb.1024;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.24.1;
}
}
}
{master:0}[edit]
root@EX4300#
This section will cover some commands that are used to get some information from the satellites or to perform some actions with the satellites.
This is how you can reboot a satellite:
[edit] root@EX9200-1# run request chassis satellite reboot fpc-slot 65 Do you want to continue? [yes,no] (no) yes slot-id 65: Reboot command sent [edit] root@EX9200-1#
This is how you can connect to the satellite:
[edit] root@EX9200-1# run request chassis satellite login fpc-slot 66 Warning: Permanently added '172.16.0.66' (ECDSA) to the list of known hosts. root@sd66:~#
This is how you can retrieve files from the satellite:
[edit] root@EX9200-1# run request chassis satellite file-copy sd66:/root/test.file /root Warning: Permanently added '172.16.0.66' (ECDSA) to the list of known hosts. test.file 100% 0 0.0KB/s 00:00 [edit] root@EX9200-1# run file list /root/: .cshrc@ -> /packages/mnt/os-runtime/root/.cshrc .history .login@ -> /packages/mnt/os-runtime/root/.login .profile@ -> /packages/mnt/os-runtime/root/.profile .ssh/ test.file [edit] root@EX9200-1#
This is how you can run shell commands on a satellite. Normally, you would need to login to the satellite and then execute the command. You can execute the command directly from the AD:
[edit] root@EX9200-1# run request chassis satellite login fpc-slot 66 Warning: Permanently added '172.16.0.66' (ECDSA) to the list of known hosts. root@sd66:~# uname -a Linux sd66 3.10.62-ltsi-WR6.0.0.21_standard #1 SMP PREEMPT Tue Aug 29 03:43:53 PDT 2017 armv7l armv7l armv7l GNU/Linux root@sd66:~# exit logout Connection to 172.16.0.66 closed. Invalid argument [edit] root@EX9200-1# run request chassis satellite shell-command fpc-slot 66 "uname -a" Command send to FPC. Waiting for response. 215 Data follows, terminated by "." Slot-ID: 66 Linux sd66 3.10.62-ltsi-WR6.0.0.21_standard #1 SMP PREEMPT Tue Aug 29 03:43:53 PDT 2017 armv7l armv7l armv7l GNU/Linux [edit] root@EX9200-1#
Finally, this is how you can check the cpu/memory usage and other parameters of the satellite:
[edit]
root@EX9200-1# run show chassis routing-engine satellite fpc-slot 65
Routing Engine status:
Slot 65:
Temperature 38 degrees C / 100 degrees F
CPU temperature 38 degrees C / 100 degrees F
DRAM 2002 MB
Memory utilization 10 percent
5 sec CPU utilization:
User 10 percent
Background 0 percent
Kernel 1 percent
Interrupt 0 percent
Idle 89 percent
Model EX3400-24T
Serial ID NV0217470048
Start time 2018-07-18 21:40:17 CEST
Uptime 3 hours, 24 minutes, 13 seconds
Last reboot reason Voltage Sag
Load averages: 1 minute 5 minute 15 minute
0.52 0.42 0.39
[edit]
root@EX9200-1#
Traffic forwarding and verification
This is the status of the satellites on EX9200-1:
[edit]
root@EX9200-1# run show chassis satellite
Device Cascade Port Extended Ports
Alias Slot State Ports State Total/Up
_sd65 65 Online xe-0/0/3 online 26/3
xe-66/2/2 present
ae0* backup
_sd66 66 Online xe-65/2/2 present 26/3
ae0* backup
_sd67 67 Online xe-68/2/2 present 50/3
ae0* backup
_sd68 68 Online xe-0/2/3 online 26/4
xe-67/2/2 present
ae0* backup
_sd75 75 Online et-4/2/1 online 50/4
ae0* backup
[edit]
root@EX9200-1#
And on EX9200-2:
[edit]
root@EX9200-2# run show chassis satellite
Device Cascade Port Extended Ports
Alias Slot State Ports State Total/Up
_sd65 65 Online xe-66/2/2 present 26/3
ae0* backup
_sd66 66 Online xe-1/0/3 online 26/3
xe-65/2/2 present
ae0* backup
_sd67 67 Online xe-1/2/3 online 50/3
xe-68/2/2 present
ae0* backup
_sd68 68 Online xe-67/2/2 present 26/4
ae0* backup
_sd75 75 Online et-2/3/1 online 50/4
ae0* backup
[edit]
root@EX9200-2#
As it can be seen, there is redundancy for the standalone satellite, as well for the satellite cluster.
A ping started from EX4300 to each IP address from the diagram in each routing instance should be successful. Similar ping commands were executed for all the host from 192.168.16/24 and 192.168.24/24:
{master:0}[edit]
root@EX4300# run ping routing-instance v1016 count 1 192.168.16.1
PING 192.168.16.1 (192.168.16.1): 56 data bytes
64 bytes from 192.168.16.1: icmp_seq=0 ttl=64 time=1.788 ms
--- 192.168.16.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.788/1.788/1.788/0.000 ms
{master:0}[edit]
root@EX4300# run ping routing-instance v1024 count 1 192.168.24.1
PING 192.168.24.1 (192.168.24.1): 56 data bytes
64 bytes from 192.168.24.1: icmp_seq=0 ttl=64 time=1.649 ms
--- 192.168.24.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.649/1.649/1.649/0.000 ms
{master:0}[edit]
root@EX4300#
The above output tests that layer 2 traffic is fine through JFE and that MC-LAG is working properly.
The following output confirms that layer 3 traffic is fine as the traffic on EX4300 leaves routing instance v1016 and ends up in routing instance v1024. The traffic is routed by the master VRRP:
{master:0}[edit]
root@EX4300# run ping routing-instance v1016 192.168.24.103 count 1
PING 192.168.24.103 (192.168.24.103): 56 data bytes
64 bytes from 192.168.24.103: icmp_seq=0 ttl=63 time=1.496 ms
--- 192.168.24.103 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.496/1.496/1.496/0.000 ms
{master:0}[edit]
root@EX4300# run traceroute routing-instance v1016 192.168.24.103
traceroute to 192.168.24.103 (192.168.24.103), 30 hops max, 40 byte packets
1 192.168.16.2 (192.168.16.2) 1.708 ms 2.631 ms 1.231 ms
2 192.168.24.103 (192.168.24.103) 2.065 ms 2.298 ms 2.841 ms
{master:0}[edit]
root@EX4300#
Now let’s check the ARP and MAC table on EX4300. There is nothing special. Everything points to ae1 interface and we should have information about all the hosts:
{master:0}[edit]
root@EX4300# run show arp no-resolve
MAC Address Address Interface Flags
5c:5e:ab:64:25:81 172.30.158.1 me0.0 none
00:0c:29:1b:27:27 172.30.158.253 me0.0 none
00:00:5e:00:01:10 192.168.16.1 irb.1016 [ae1.0] none
08:81:f4:97:07:f0 192.168.16.2 irb.1016 [ae1.0] none
dc:38:e1:15:5c:30 192.168.16.3 irb.1016 [ae1.0] none
00:1f:12:37:66:44 192.168.16.101 irb.1016 [ae1.0] none
5c:5e:ab:61:18:81 192.168.16.102 irb.1016 [ae1.0] none
00:00:5e:00:01:18 192.168.24.1 irb.1024 [ae1.0] none
08:81:f4:97:07:f0 192.168.24.2 irb.1024 [ae1.0] none
dc:38:e1:15:5c:30 192.168.24.3 irb.1024 [ae1.0] none
00:1f:12:37:66:45 192.168.24.101 irb.1024 [ae1.0] none
5c:5e:ab:61:18:81 192.168.24.102 irb.1024 [ae1.0] none
Total entries: 12
{master:0}[edit]
root@EX4300# run show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 5 entries, 5 learned
Routing instance : default-switch
Vlan MAC MAC Age Logical
name address flags interface
v1016 00:00:5e:00:01:10 D - ae1.0
v1016 00:1f:12:37:66:44 D - ae1.0
v1016 08:81:f4:97:07:f0 D - ae1.0
v1016 5c:5e:ab:61:18:81 D - ae1.0
v1016 dc:38:e1:15:5c:30 D - ae1.0
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 5 entries, 5 learned
Routing instance : default-switch
Vlan MAC MAC Age Logical
name address flags interface
v1024 00:00:5e:00:01:18 D - ae1.0
v1024 00:1f:12:37:66:45 D - ae1.0
v1024 08:81:f4:97:07:f0 D - ae1.0
v1024 5c:5e:ab:61:18:81 D - ae1.0
v1024 dc:38:e1:15:5c:30 D - ae1.0
{master:0}[edit]
root@EX4300#
Now, let’s check the ARP/MAC tables on EX9200-1:
[edit]
root@EX9200-1# run show arp no-resolve | match 192.168
dc:38:e1:15:5b:59 192.168.0.34 et-4/2/0.0 none
dc:38:e1:15:5b:59 192.168.0.34 et-4/2/0.1300 none
dc:38:e1:15:5c:30 192.168.16.3 irb.1016 [ae0.0] permanent remote
00:1f:12:37:66:44 192.168.16.101 irb.1016 [ge-65/0/0.0] none
5c:5e:ab:61:18:81 192.168.16.102 irb.1016 [ae2.0] none
5c:45:27:ef:c8:41 192.168.16.103 irb.1016 [ae1.0] none
dc:38:e1:15:5c:30 192.168.24.3 irb.1024 [ae0.0] permanent remote
00:1f:12:37:66:45 192.168.24.101 irb.1024 [ge-66/0/2.0] none
5c:5e:ab:61:18:81 192.168.24.102 irb.1024 [ae2.0] none
5c:45:27:ef:c8:41 192.168.24.103 irb.1024 [ae1.0] none
[edit]
root@EX9200-1# run show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 6 entries, 6 learned
Routing instance : default-switch
Vlan MAC MAC Age Logical NH RTR
name address flags interface Index ID
v1016 00:1f:12:37:66:44 DL - ge-65/0/0.0 0 0
v1016 5c:45:27:ef:c8:41 DLR - ae1.0 0 0
v1016 5c:5e:ab:61:18:81 DR - ae2.0 0 0
v1024 00:1f:12:37:66:45 DR - ge-66/0/2.0 0 0
v1024 5c:45:27:ef:c8:41 DLR - ae1.0 0 0
v1024 5c:5e:ab:61:18:81 DR - ae2.0 0 0
[edit]
root@EX9200-1#
And on EX9200-2:
[edit]
root@EX9200-2# run show arp no-resolve | match 192.168
08:81:f4:97:05:cc 192.168.0.33 et-2/3/0.0 none
08:81:f4:97:05:cc 192.168.0.33 et-2/3/0.1300 none
08:81:f4:97:07:f0 192.168.16.2 irb.1016 [ae0.0] permanent remote
00:1f:12:37:66:44 192.168.16.101 irb.1016 [ge-65/0/0.0] none
5c:5e:ab:61:18:81 192.168.16.102 irb.1016 [ae2.0] none
5c:45:27:ef:c8:41 192.168.16.103 irb.1016 [ae1.0] none
08:81:f4:97:07:f0 192.168.24.2 irb.1024 [ae0.0] permanent remote
00:1f:12:37:66:45 192.168.24.101 irb.1024 [ge-66/0/2.0] none
5c:5e:ab:61:18:81 192.168.24.102 irb.1024 [ae2.0] none
5c:45:27:ef:c8:41 192.168.24.103 irb.1024 [ae1.0] none
[edit]
root@EX9200-2# run show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 6 entries, 6 learned
Routing instance : default-switch
Vlan MAC MAC Age Logical NH RTR
name address flags interface Index ID
v1016 00:1f:12:37:66:44 DR - ge-65/0/0.0 0 0
v1016 5c:45:27:ef:c8:41 DLR - ae1.0 0 0
v1016 5c:5e:ab:61:18:81 DL - ae2.0 0 0
v1024 00:1f:12:37:66:45 DL - ge-66/0/2.0 0 0
v1024 5c:45:27:ef:c8:41 DLR - ae1.0 0 0
v1024 5c:5e:ab:61:18:81 DL - ae2.0 0 0
[edit]
root@EX9200-2#
There is a difference regarding how some of the MAC addresses were learned(locally or remotely). For instance, the MAC address from ge-65/0/0 is locally learned on AD1 and remotely learned on AD2 because AD1 has a direct link to FPC65. The same logic applies to the MAC from ge-66/0/2 interface.
With regards to external routing, let’s check the OSPF routes on both ADs:
[edit]
root@EX9200-1# run show route protocol ospf 1.1.1.0/30
VR.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[OSPF/10] 00:02:24, metric 1
> to 10.10.86.2 via xe-0/1/1.0
1.1.1.2/32 *[OSPF/10] 00:00:23, metric 2
> to 192.168.0.34 via et-4/2/0.1300
[edit]
root@EX9200-1#
[edit]
root@EX9200-2# run show route protocol ospf 1.1.1.0/30
VR.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[OSPF/10] 00:01:29, metric 2
> to 192.168.0.33 via et-2/3/0.1300
1.1.1.2/32 *[OSPF/10] 00:00:57, metric 1
> to 10.10.87.2 via xe-1/1/1.0
[edit]
root@EX9200-2#
The traffic between the two OSPF routers goes through just fine:
{master:0}[edit]
root@R_OSPF_1# run ping count 1 source 1.1.1.1 1.1.1.2
PING 1.1.1.2 (1.1.1.2): 56 data bytes
64 bytes from 1.1.1.2: icmp_seq=0 ttl=62 time=1.436 ms
--- 1.1.1.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.436/1.436/1.436/0.000 ms
{master:0}[edit]
root@R_OSPF_1#
Also, the traffic can be sent to the devices attached to JFE. This is only for the 192.168.16/0 subnet, but the output is similar for the other subnet:
{master:0}[edit]
root@R_OSPF_1# run ping count 1 source 1.1.1.1 192.168.16.101
PING 192.168.16.101 (192.168.16.101): 56 data bytes
64 bytes from 192.168.16.101: icmp_seq=0 ttl=63 time=1.389 ms
--- 192.168.16.101 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.389/1.389/1.389/0.000 ms
{master:0}[edit]
root@R_OSPF_1# run ping count 1 source 1.1.1.1 192.168.16.102
PING 192.168.16.102 (192.168.16.102): 56 data bytes
64 bytes from 192.168.16.102: icmp_seq=0 ttl=62 time=2.074 ms
--- 192.168.16.102 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.074/2.074/2.074/0.000 ms
{master:0}[edit]
root@R_OSPF_1# run ping count 1 source 1.1.1.1 192.168.16.103
PING 192.168.16.103 (192.168.16.103): 56 data bytes
64 bytes from 192.168.16.103: icmp_seq=0 ttl=63 time=4.121 ms
--- 192.168.16.103 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.121/4.121/4.121/0.000 ms
{master:0}[edit]
root@R_OSPF_1#
Let’s test the resiliency of the setup and bring down the cascade port from EX9200-1 towards LEFT cluster and the MC-AE interface:
[edit] root@EX9200-1# set interfaces xe-0/0/3 disable [edit] root@EX9200-1# set interfaces xe-0/0/6 disable [edit] root@EX9200-1# commit commit complete [edit] root@EX9200-1#
This will cause our setup to look like this:
This is the status of the cluster:
[edit]
root@EX9200-1# run show chassis satellite cluster LEFT
Device Cascade Port Extended Ports
Alias Slot State Ports State Total/Up
_sd65 65 Online xe-66/2/2 present 26/2
ae0* online
_sd66 66 Online xe-65/2/2 present 26/3
ae0* online
[edit]
root@EX9200-1#
[edit]
root@EX9200-2# run show chassis satellite cluster LEFT
Device Cascade Port Extended Ports
Alias Slot State Ports State Total/Up
_sd65 65 Online xe-66/2/2 present 26/2
_sd66 66 Online xe-1/0/3 online 26/3
xe-65/2/2 present
[edit]
root@EX9200-2#
The same reachability tests from EX4300 towards all the hosts are successful and these are the ARP/MAC tables on the two ADs. On EX9200-1:
[edit]
root@EX9200-1# run show arp no-resolve | match 192.168
dc:38:e1:15:5b:59 192.168.0.34 et-4/2/0.0 none
dc:38:e1:15:5b:59 192.168.0.34 et-4/2/0.1300 none
dc:38:e1:15:5c:30 192.168.16.3 irb.1016 [ae0.0] permanent remote
00:1f:12:37:66:44 192.168.16.101 irb.1016 [ge-65/0/0.0] none
5c:5e:ab:61:18:81 192.168.16.102 irb.1016 [ae2.0] none
5c:45:27:ef:c8:41 192.168.16.103 irb.1016 [ae0.0] none
dc:38:e1:15:5c:30 192.168.24.3 irb.1024 [ae0.0] permanent remote
00:1f:12:37:66:45 192.168.24.101 irb.1024 [ge-66/0/2.0] none
5c:5e:ab:61:18:81 192.168.24.102 irb.1024 [ae2.0] none
5c:45:27:ef:c8:41 192.168.24.103 irb.1024 [ae0.0] none
[edit]
root@EX9200-1# run show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 6 entries, 6 learned
Routing instance : default-switch
Vlan MAC MAC Age Logical NH RTR
name address flags interface Index ID
v1016 00:1f:12:37:66:44 DLR - ge-65/0/0.0 0 0
v1016 5c:45:27:ef:c8:41 DR - ae0.0 0 0
v1016 5c:5e:ab:61:18:81 DLR - ae2.0 0 0
v1024 00:1f:12:37:66:45 DR - ge-66/0/2.0 0 0
v1024 5c:45:27:ef:c8:41 DR - ae0.0 0 0
v1024 5c:5e:ab:61:18:81 DLR - ae2.0 0 0
[edit]
root@EX9200-1#
And on EX9200-2:
[edit]
root@EX9200-2# run show arp no-resolve | match 192.168
08:81:f4:97:05:cc 192.168.0.33 et-2/3/0.0 none
08:81:f4:97:05:cc 192.168.0.33 et-2/3/0.1300 none
08:81:f4:97:07:f0 192.168.16.2 irb.1016 [ae0.0] permanent remote
00:1f:12:37:66:44 192.168.16.101 irb.1016 [ge-65/0/0.0] none
5c:45:27:ef:c8:41 192.168.16.103 irb.1016 [ae1.0] none
08:81:f4:97:07:f0 192.168.24.2 irb.1024 [ae0.0] permanent remote
00:1f:12:37:66:45 192.168.24.101 irb.1024 [ge-66/0/2.0] none
5c:5e:ab:61:18:81 192.168.24.102 irb.1024 [ae2.0] none
5c:45:27:ef:c8:41 192.168.24.103 irb.1024 [ae1.0] none
[edit]
root@EX9200-2# run show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 6 entries, 6 learned
Routing instance : default-switch
Vlan MAC MAC Age Logical NH RTR
name address flags interface Index ID
v1016 00:1f:12:37:66:44 DLR - ge-65/0/0.0 0 0
v1016 5c:45:27:ef:c8:41 DL - ae1.0 0 0
v1016 5c:5e:ab:61:18:81 DLR - ae2.0 0 0
v1024 00:1f:12:37:66:45 DL - ge-66/0/2.0 0 0
v1024 5c:45:27:ef:c8:41 DL - ae1.0 0 0
v1024 5c:5e:ab:61:18:81 DLR - ae2.0 0 0
[edit]
root@EX9200-2#
Observe that because EX9200-1 does not have a direct link to the EX4300 or to the left cluster, the MAC address are learned via ae0(the ICL link).
Now, let’s assume that AD1(VRRP master) has a failure, which causes the setup to look like this:
EX9200-2 took over as VRRP master:
[edit]
root@EX9200-2# run show vrrp
Interface State Group VR state VR Mode Timer Type Address
irb.1016 up 16 master Active A 0.899 lcl 192.168.16.3
vip 192.168.16.1
irb.1024 up 24 master Active A 0.831 lcl 192.168.24.3
vip 192.168.24.1
[edit]
root@EX9200-2#
This is the status of the satellites:
[edit]
root@EX9200-2# run show chassis satellite
Device Cascade Port Extended Ports
Alias Slot State Ports State Total/Up
_sd65 65 Online xe-66/2/2 present 26/3
_sd66 66 Online xe-1/0/3 online 26/3
xe-65/2/2 present
_sd67 67 Online xe-1/2/3 online 50/3
xe-68/2/2 present
_sd68 68 Online xe-67/2/2 present 26/4
_sd75 75 Online et-2/3/1 online 50/4
[edit]
root@EX9200-2#
As it can be seen below, the MC-AE interface is still and also the LAG that uses extended ports is up. The ICL link is down as AD1 is not functional:
[edit]
root@EX9200-2# run show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
et-2/2/0 Actor No Yes No No No Yes Fast Active
et-2/2/0 Partner No Yes No No No Yes Fast Passive
et-2/2/1 Actor No Yes No No No Yes Fast Active
et-2/2/1 Partner No Yes No No No Yes Fast Passive
LACP protocol: Receive State Transmit State Mux State
et-2/2/0 Port disabled No periodic Detached
et-2/2/1 Port disabled No periodic Detached
Aggregated interface: ae1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
xe-1/0/6 Actor No No Yes Yes Yes Yes Fast Active
xe-1/0/6 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
xe-1/0/6 Current Fast periodic Collecting distributing
Aggregated interface: ae2
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-75/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-75/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-75/0/6 Actor No No Yes Yes Yes Yes Fast Active
ge-75/0/6 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-75/0/0 Current Fast periodic Collecting distributing
ge-75/0/6 Current Fast periodic Collecting distributing
[edit]
root@EX9200-2#
With regards to the ARP table, not that much changed. This is the MAC table and you can see that every MAC was locally learned:
[edit]
root@EX9200-2# run show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 7 entries, 7 learned
Routing instance : default-switch
Vlan MAC MAC Age Logical NH RTR
name address flags interface Index ID
default 5c:45:27:ef:c8:44 DL - ae1.0 0 0
v1016 00:1f:12:37:66:44 DL - ge-65/0/0.0 0 0
v1016 5c:45:27:ef:c8:41 DL - ae1.0 0 0
v1016 5c:5e:ab:61:18:81 DL - ae2.0 0 0
v1024 00:1f:12:37:66:45 DL - ge-66/0/2.0 0 0
v1024 5c:45:27:ef:c8:41 DL - ae1.0 0 0
v1024 5c:5e:ab:61:18:81 DL - ae2.0 0 0
[edit]
root@EX9200-2#
Even with this device failure, the traffic still passes through the JFE:
{master:0}[edit]
root@EX4300# run ping routing-instance v1016 count 1 192.168.16.101
PING 192.168.16.101 (192.168.16.101): 56 data bytes
64 bytes from 192.168.16.101: icmp_seq=0 ttl=64 time=3.062 ms
--- 192.168.16.101 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.062/3.062/3.062/0.000 ms
{master:0}[edit]
root@EX4300# run ping routing-instance v1024 count 1 192.168.24.101
PING 192.168.24.101 (192.168.24.101): 56 data bytes
64 bytes from 192.168.24.101: icmp_seq=0 ttl=64 time=3.089 ms
--- 192.168.24.101 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.089/3.089/3.089/0.000 ms
{master:0}[edit]
root@EX4300# run ping routing-instance v1024 count 1 1.1.1.2
PING 1.1.1.2 (1.1.1.2): 56 data bytes
64 bytes from 1.1.1.2: icmp_seq=0 ttl=63 time=2.406 ms
--- 1.1.1.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.406/2.406/2.406/0.000 ms
{master:0}[edit]
root@EX4300# run ping routing-instance v1016 count 1 1.1.1.2
PING 1.1.1.2 (1.1.1.2): 56 data bytes
64 bytes from 1.1.1.2: icmp_seq=0 ttl=63 time=3.086 ms
--- 1.1.1.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.086/3.086/3.086/0.000 ms
{master:0}[edit]
root@EX4300#
This would be pretty much for this part.
I know it was a long post but it contained a lot of outputs that helped to show better how Junos Fusion Enterprise handles traffic and how deals with link or device failures.
JFE is an option for increased uptime in enterprise environments.
In a future part of the series, we will cover some features like loop detection, port policies.
I hope you found this post interesting.
The following two tabs change content below.
Paris ARAU
Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
[…] This is the Junos Fusion setup. It is the same used in Part 3: […]