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:

Diagram and initial state

Satellite management

Traffic forwarding and verification

Resiliency

Conclusion

 

Diagram and initial state

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#

 

Satellite management

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#

 

Resiliency

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#

 

Conclusion

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.

Comments

This post currently has one response

Leave a Reply to Junos Fusion – Part IV – Satellite policies and uplink failure detection | Cancel reply

Your email address will not be published. Required fields are marked *

Sidebar



%d bloggers like this: