Juniper Pseudowire Redundancy hot-standby Explained with Examples

Pseudowire redundancy is key when it comes to eliminating a single point of failure, such as PW, AC and PE, in certain network designs as far as MPLS L2VPN services (e.g., VPWS and VPLS). When configuring pseudowire redundancy on Junos, you can either leave the backup PW in standby or in hot-standby mode. In this article, I’m going to compare both modes and point out some major benefits and drawbacks that you might want to take into account if you ever need to use PW redundancy in your network.

Overview

Preferential Forwarding Status Bit

According to RFC 6870 1, new status bit values were defined in order to allow more granular control, specifically to coordinate a switchover to backup PWs. In this RFC, these new PW status TLVs were introduced 0x00000020 (PW forwarding standby) and 0x00000040 (Request switchover to this PW). On Junos 15.1, the following PW status codes are available:

Flag (TLV) Code
L2CKT_PW_STATUS_PW_FWD 0x00000000
L2CKT_PW_STATUS_PW_NOT_FWD 0x00000001
L2CKT_PW_STATUS_AC_RX_FAULT 0x00000002
L2CKT_PW_STATUS_AC_TX_FAULT 0x00000004
L2CKT_PW_STATUS_PSN_RX_FAULT 0x00000008
L2CKT_PW_STATUS_PSN_TX_FAULT 0x00000010
L2CKT_PW_STATUS_PW_FWD_STDBY 0x00000020
L2CKT_PW_STATUS_SWITCH_OVER 0x00000040

Table 1 - PW Status code for the PW Status TLV 2

As you can see, on Junos 15.1 it’s possible to make use of the PW_STATUS_PW_FWD_STDBY in order to signal a standby PW status. However, by default, Junos doesn’t signal the status TLV and if you’re going to use it you have to enable the pseudowire-status-tlv command on both PEs. In addition to this, Juniper implements two standby modes, standby and hot-standby which I’ll explain briefly in the next section.

Standby PW configuration modes on Junos

There are two modes you can configure on Junos 15.1, either you set standby or hot-standby mode. The former is the default one when you configure a secondary PW by setting the backup-neighbor command and the later, as the name implies, allows you to keep the backup PW in a ready to forwarding state in order to achieve a faster switchover time when the active PW fails. Therefore, whenever hot-standby is in place, you’ll see that both PEs will have their L2CKT label ready to go in both software and hardware tables. As a trade-off though, this mode has the drawback of replicating BUM traffic. On the other hand, the standby mode has to exchange L2CKT labels as soon as the switchover operation takes place. To show these differences, I’ll use the topology illustrated in Figure 1.

Topology

Figure 1

In this topology, there is a CE2 device, which is connected to the AC on VLAN 1024, multi-homed to PE2 and PE4 to increase high availability. PE1 has two PWs, connecting the CE1 to the AC on VLAN 1024, an active one PW_VCID_12 between PE1 and PE2 and a backup one PW_VCID_14 between PE1 and PE4. Consequently, whenever PW_VCID_12 fails, PW_VCID_14 is supposed to take over. Now, we’ll analyze the switchover time and see the difference between the two standby modes in practice.

Configuration

For readability’s sake, the configuration presented in the following subsections are only related to L2VPN Martini and pseudowire redundancy.

Standby Configuration

1
2
3
4
5
6
7
8
9
10
11
12
[edit protocols]
root@PE1# show l2circuit
neighbor 2.2.2.2 {
interface ge-0/0/3.1024 {
virtual-circuit-id 12;
pseudowire-status-tlv;
revert-time 30;
backup-neighbor 4.4.4.4 {
virtual-circuit-id 14;
}
}
}
1
2
3
4
5
6
7
8
[edit protocols]
root@PE2# show l2circuit
neighbor 1.1.1.1 {
interface ge-0/0/3.1024 {
virtual-circuit-id 12;
pseudowire-status-tlv;
}
}
1
2
3
4
5
6
7
8
[edit protocols]
root@PE4# show l2circuit
neighbor 1.1.1.1 {
interface ge-0/0/3.1024 {
virtual-circuit-id 14;
pseudowire-status-tlv;
}
}

Hot-standby Configuration

When configuring the hot-standby mode, you have to set the pseudowire-status-tlv hot-standby-vc-on which enables the remote standby PE (PE4, in this case) to process the hot-standby TLV (i.e. code 0x00000020) properly when received from PE1. In addition to this, you also have to set the hot-standby on PE1, which is the PE with redundant PWs. Check out the snippet code bellow.

1
2
3
4
5
6
7
8
9
10
11
12
13
[edit protocols l2circuit]
root@PE1# show l2circuit
neighbor 2.2.2.2 {
interface ge-0/0/3.1024 {
virtual-circuit-id 12;
pseudowire-status-tlv;
revert-time 30;
backup-neighbor 4.4.4.4 {
virtual-circuit-id 14;
hot-standby;
}
}
}
1
2
3
4
5
6
7
8
[edit protocols l2circuit]
root@PE2# show
neighbor 1.1.1.1 {
interface ge-0/0/3.1024 {
virtual-circuit-id 12;
pseudowire-status-tlv;
}
}
1
2
3
4
5
6
7
8
[edit protocols l2circuit]
root@PE4# show l2circuit
neighbor 1.1.1.1 {
interface ge-0/0/3.1024 {
virtual-circuit-id 14;
pseudowire-status-tlv hot-standby-vc-on;
}
}

Verification

Standby Configuration Verification

First, let’s see from PE1’s perspective the signaling state of both active and standby PW. As you can see in the output of the terminal bellow, when the default standby mode is configured, the backup-neighbor (PE4) PW connection status is BK which stands for Backup Connection. Also, note that the local PE1 is signaling the TLV as 0x00000001 (not forwarding). As a consequence, PE1 doesn’t have an outgoing label in software (LDP database) for the L2CKT of this PW_VCID_14. Lastly, the only outgoing L2CKT entry in hardware is the one which leads to the active PW (PE2).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
root@PE1> show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down HS -- Hot-standby Connection
XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 2.2.2.2
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 12) rmt Up May 29 16:25:39 2016 1
Remote PE: 2.2.2.2, Negotiated control-word: Yes (Null)
Incoming label: 299776, Outgoing label: 299776
Negotiated PW status TLV: Yes
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
Local interface: ge-0/0/3.1024, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No
Neighbor: 4.4.4.4
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 14) rmt BK
local PW status code: 0x00000001, Neighbor PW status code: 0x00000000
root@PE1> show route forwarding-table family mpls
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 50 1
0 user 0 rtbl 1 2
0(S=0) user 0 rtbl 3 3
1 user 0 recv 49 2
2 user 0 rtbl 2 2
2(S=0) user 0 rtbl 3 3
13 user 0 recv 49 2
299776 user 0 Pop 569 2 ge-0/0/3.1024
299808 user 0 10.1.3.3 Pop 564 2 ge-0/0/1.0
299808(S=0) user 0 10.1.3.3 Pop 565 2 ge-0/0/1.0
299824 user 0 10.1.2.2 Pop 567 2 ge-0/0/0.0
299824(S=0) user 0 10.1.2.2 Pop 568 2 ge-0/0/0.0
299840 user 0 ulst 1048576 2
10.1.2.2 Swap 299824 573 1 ge-0/0/0.0
10.1.3.3 Swap 299808 571 1 ge-0/0/1.0
ge-0/0/3.1024 (CCC) user 0 indr 1048574 2
10.1.2.2 Push 299776 570 2 ge-0/0/0.0
Routing table: __mpls-oam__.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 529 1
root@PE1>

From PE4’s perspective, the PW connection status is OL which stands for No outgoing label. Plus, as expected, there isn’t any L2CKT entry installed in hardware.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
root@PE4> show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down HS -- Hot-standby Connection
XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 1.1.1.1
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 14) rmt OL
root@PE4> show route forwarding-table family mpls
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 50 1
0 user 0 rtbl 1 2
0(S=0) user 0 rtbl 3 3
1 user 0 recv 49 2
2 user 0 rtbl 2 2
2(S=0) user 0 rtbl 3 3
13 user 0 recv 49 2
299792 user 0 10.3.4.3 Pop 564 2 ge-0/0/0.0
299792(S=0) user 0 10.3.4.3 Pop 565 2 ge-0/0/0.0
299808 user 0 10.2.4.2 Pop 567 2 ge-0/0/1.0
299808(S=0) user 0 10.2.4.2 Pop 568 2 ge-0/0/1.0
299824 user 0 ulst 1048575 2
10.3.4.3 Swap 299776 571 1 ge-0/0/0.0
10.2.4.2 Swap 299792 569 1 ge-0/0/1.0
Routing table: __mpls-oam__.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 529 1
root@PE4>

PW Swichover Testing

I’ll keep an ICMP traffic flowing from CE1 to CE2 and then I’ll request a reboot on PE2 to simulate as if PE2 failed. This reboot will trigger the PW switchover to PE4. Let’s see how many ICMP packets will be lost over this process.

1
2
3
4
5
root@CEs:CE1> ping 192.168.0.2 rapid count 4000
PING 192.168.0.2 (192.168.0.2): 56 data bytes
--- 192.168.0.2 ping statistics ---
4000 packets transmitted, 3984 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.641/4.881/963.664/17.085 ms

Out of 4000 packets, 16 packets were lost.

BUM Traffic Testing

The active PW is still between PE1 and PE2 (by now PE2 has already recovered completely) and I’ll do a broadcast ping from CE2 to CE1. We can verify bellow that on all MPLS uplinks there was only one packet sent as expected. In other words, even though both PE2 and PE4 received this broadcast ping on VLAN 1024, PE2 was the only one who encapsulated this traffic over the MPLS backbone as depicted in Figure 2. Cool!

1
2
3
4
5
6
7
root@CEs:CE2> ping 255.255.255.255 count 1
PING 255.255.255.255 (255.255.255.255): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=5.488 ms
--- 255.255.255.255 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.488/5.488/5.488/0.000 ms

Figure 2

Hot-standby Configuration Verification

Now, let’s compare with the hot-standby mode. Once again, we’ll start the verification on PE1. The major difference is the fact that the PW connection status is HS now which means Hot-standby Connection and the local PW status code is 0x00000020. Also, both incoming and outgoing label for the backup PW (PW_VCID_14) is installed both in software and hardware.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
root@PE1> show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down HS -- Hot-standby Connection
XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 2.2.2.2
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 12) rmt Up May 29 17:54:42 2016 1
Remote PE: 2.2.2.2, Negotiated control-word: Yes (Null)
Incoming label: 299872, Outgoing label: 299776
Negotiated PW status TLV: Yes
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
Local interface: ge-0/0/3.1024, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No
Neighbor: 4.4.4.4
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 14) rmt HS ----- ----
Remote PE: 4.4.4.4, Negotiated control-word: Yes (Null)
Incoming label: 299888, Outgoing label: 299776
Negotiated PW status TLV: Yes
local PW status code: 0x00000020, Neighbor PW status code: 0x00000000
Local interface: ge-0/0/3.1024, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No
root@PE1> show route forwarding-table family mpls
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 50 1
0 user 0 rtbl 1 2
0(S=0) user 0 rtbl 3 3
1 user 0 recv 49 2
2 user 0 rtbl 2 2
2(S=0) user 0 rtbl 3 3
13 user 0 recv 49 2
299808 user 0 10.1.3.3 Pop 564 2 ge-0/0/1.0
299808(S=0) user 0 10.1.3.3 Pop 565 2 ge-0/0/1.0
299840 user 0 ulst 1048576 2
10.1.2.2 Swap 299792 573 1 ge-0/0/0.0
10.1.3.3 Swap 299808 571 1 ge-0/0/1.0
299856 user 0 10.1.2.2 Pop 572 2 ge-0/0/0.0
299856(S=0) user 0 10.1.2.2 Pop 568 2 ge-0/0/0.0
299872 user 0 Pop 569 3 ge-0/0/3.1024
299888 user 0 Pop 569 3 ge-0/0/3.1024
ge-0/0/3.1024 (CCC) user 0 ulst 1048579 1
indr 1048574 2
10.1.2.2 Push 299776 567 2 ge-0/0/0.0
indr 1048578 2
ulst 1048577 2
10.1.2.2 Push 299776, Push 299792(top) 570 1 ge-0/0/0.0 -
10.1.3.3 Push 299776, Push 299808(top) 574 1 ge-0/0/1.0
Routing table: __mpls-oam__.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 529 1
root@PE1> show route table inet.3
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2.2.2.2/32 *[LDP/9] 00:46:55, metric 1
> to 10.1.2.2 via ge-0/0/0.0
3.3.3.3/32 *[LDP/9] 00:50:16, metric 1
> to 10.1.3.3 via ge-0/0/1.0
4.4.4.4/32 *[LDP/9] 00:46:55, metric 1
to 10.1.2.2 via ge-0/0/0.0, Push 299792
> to 10.1.3.3 via ge-0/0/1.0, Push 299808

From PE4’s point of view, the greatest difference when compared to the previous output is that now the status is Up and the remote TLV PW status code is 0x00000020. Plus, both incoming and outgoing label are installed in software and hardware to speed up the switchover operation. Although all labels are installed, this PE won’t encapsulate traffic over the MPLS backbone except for BUM traffic as you’ll see shortly.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
root@PE4> show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down HS -- Hot-standby Connection
XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 1.1.1.1
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 14) rmt Up May 29 18:16:52 2016 1
Remote PE: 1.1.1.1, Negotiated control-word: Yes (Null)
Incoming label: 299776, Outgoing label: 299888
Negotiated PW status TLV: Yes
local PW status code: 0x00000000, Neighbor PW status code: 0x00000020
Local interface: ge-0/0/3.1024, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No
root@PE4> show route forwarding-table family mpls
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 50 1
0 user 0 rtbl 1 2
0(S=0) user 0 rtbl 3 3
1 user 0 recv 49 2
2 user 0 rtbl 2 2
2(S=0) user 0 rtbl 3 3
13 user 0 recv 49 2
299776 user 0 Pop 570 2 ge-0/0/3.1024
299792 user 0 10.3.4.3 Pop 564 2 ge-0/0/0.0
299792(S=0) user 0 10.3.4.3 Pop 565 2 ge-0/0/0.0
299824 user 0 ulst 1048576 2
10.3.4.3 Swap 299776 571 1 ge-0/0/0.0
10.2.4.2 Swap 299808 572 1 ge-0/0/1.0
299840 user 0 10.2.4.2 Pop 567 2 ge-0/0/1.0
299840(S=0) user 0 10.2.4.2 Pop 568 2 ge-0/0/1.0
ge-0/0/3.1024 (CCC) user 0 indr 1048577 2
ulst 1048575 2
10.3.4.3 Push 299888, Push 299776(top) 569 1 ge-0/0/0.0
10.2.4.2 Push 299888, Push 299808(top) 573 1 ge-0/0/1.0
Routing table: __mpls-oam__.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 529 1
root@PE4> show route table inet.3
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[LDP/9] 00:55:15, metric 1
> to 10.3.4.3 via ge-0/0/0.0, Push 299776
to 10.2.4.2 via ge-0/0/1.0, Push 299808
2.2.2.2/32 *[LDP/9] 00:55:40, metric 1
> to 10.2.4.2 via ge-0/0/1.0
3.3.3.3/32 *[LDP/9] 00:58:36, metric 1
> to 10.3.4.3 via ge-0/0/0.0

PW Switchover Testing

I’ll run the same ping test again. Let’s compare how many packets will be lost.

1
2
3
4
5
root@CEs:CE1> ping 192.168.0.2 rapid count 4000
PING 192.168.0.2 (192.168.0.2): 56 data bytes
--- 192.168.0.2 ping statistics ---
4000 packets transmitted, 3998 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.741/4.805/122.674/3.458 ms

How cool is that, huh? Now only 2 packets were lost as opposed to 16 packets when I ran the same test with the previous configuration. In fact, it was 8 times faster. So, if you’re looking for optimizing the switchover time, the hot-standby mode is definitely a great solution.

BUM Traffic Testing

I’ll run the same test again to verify whether PE4 (which is now in the hot-standby state) is going to encapsulate this broadcast packet over the MPLS core. By now, PE2 has completely recovered from the reboot. As a result, the PW between PE1 and PE2 is the active one.

1
2
3
4
5
6
7
root@CEs:CE2> ping 255.255.255.255 count 1
PING 255.255.255.255 (255.255.255.255): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=5.549 ms
--- 255.255.255.255 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.549/5.549/5.549/0.000 ms

As illustrated in Figure 3, the broadcast packet was duplicated in the MPLS backbone. One packet came from PE2 and the other one from PE4, which is the evidence that BUM traffic will be encapsulated even if the PW is in the hot-standby state. You can check this by looking at the label values in the MPLS header of this capture. For example, in Figure 3, the VC label is 299872 (which is the outgoing VC-label from PE2’s perspective, as you can see in the PE2 output bellow). Similarly, in Figure 4, the label stacking 299808/299888 came from PE4, you can check these labels in the previous sections of this article.

Figure 3

Figure 4

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
root@PE2> show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down HS -- Hot-standby Connection
XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 1.1.1.1
Interface Type St Time last up # Up trans
ge-0/0/3.1024(vc 12) rmt Up May 29 19:00:08 2016 1
Remote PE: 1.1.1.1, Negotiated control-word: Yes (Null)
Incoming label: 299776, Outgoing label: 299872
Negotiated PW status TLV: Yes
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
Local interface: ge-0/0/3.1024, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No
root@PE2> show route table inet.3
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[LDP/9] 00:17:29, metric 1
> to 10.1.2.1 via ge-0/0/0.0
3.3.3.3/32 *[LDP/9] 00:17:29, metric 1
> to 10.1.2.1 via ge-0/0/0.0, Push 299808
to 10.2.4.4 via ge-0/0/1.0, Push 299792
4.4.4.4/32 *[LDP/9] 00:17:53, metric 1
> to 10.2.4.4 via ge-0/0/1.0

Summary

To sum up, redundant pseudowire is key to increase high availability and eliminate single point of failures in your network. Plus, the hot-standby mode on Junos is an excellent option if your goal is to minimize the time it takes to switchover from the primary to the backup PW. Nevertheless, this optimization comes at the expense of replicating BUM traffic. Therefore, weigh your options and if you decide to stick with this mode, make sure you can keep this type of traffic under control to avoid wasting bandwidth in your MPLS backbone.

References