Junos ਡਿਊਲ-WAN IPsec VPN: ਸਰੋਤ ਰਾਹ ਨੂੰ ਸਹੀ ਗੇਟਵੇ ਨਾਲ ਮਿਲਾਉਣਾ
ਡਿਊਲ-WAN IPsec ਲਈ Junos SRX ਵਾਕਥਰੂ: ਹਰ ਸਥਾਨਕ ਸਰੋਤ ਨੂੰ ਉਸ ਦੇ ਉਮੀਦਵਾਰ ਗੇਟਵੇ ਨਾਲ ਜੋੜੋ, ਫਿਰ ਸਿੱਧ ਕਰੋ ਕਿ ਕਿਹੜੀ ਐਸੋਸੀਏਸ਼ਨ ਨੇ ਅਸਲ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਚੁੱਕਿਆ।
ਹਰ ਸਾਈਟ ਉੱਤੇ ਦੋ WAN ਲਿੰਕ ਬੇਲੋੜੀ ਦੁਹਰਾਈ ਵਰਗੇ ਲੱਗਦੇ ਹਨ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਹ ਸਿੱਧ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਕਿ ਕਿਸੇ ਦਿੱਤੇ ਫਲੋ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਪਤਾ ਜੋੜੀ ਵਰਤੀ। SRX ਉੱਤੇ ਇੱਕ IKE ਗੇਟਵੇ ਇੱਕ ਬਾਹਰੀ ਇੰਟਰਫੇਸ ਅਤੇ ਇੱਕ ਸਥਾਨਕ ਪਤਾ ਚੁੱਕਦਾ ਹੈ; ਦੂਰਲੇ ਉਮੀਦਵਾਰਾਂ ਦੀ ਸੂਚੀ ਦੂਜਾ ਸਥਾਨਕ ਸਰੋਤ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਇਸ ਲਈ ਇਹ ਵਾਕਥਰੂ ਕਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਨਹੀਂ, ਜੋੜੀਆਂ ਦੇ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ Junos ਤੁਹਾਡੇ ਇਰਾਦੇ ਦੇ ਅੱਧੇ ਹੀ ਸੰਜੋਗ ਢੱਕਣ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਵੀ ਸੌਖਿਆਂ commit ਕਰ ਲੈਂਦਾ ਹੈ। ਮੈਨੂੰ ਇਹ ਦੋ SRX345s ਉੱਤੇ ਮਿਲਿਆ: ਬੈਕਅੱਪ ਟਨਲ ਸਾਫ਼ ਉੱਪਰ ਆਈ ਅਤੇ ਫਿਰ ਵੀ ਵਾਪਸੀ ਵੇਲੇ ਸੈਸ਼ਨ ਹੇਠਾਂ ਸੁੱਟ ਦਿੱਤਾ।
ਕਦਮ ਕ੍ਰਮ ਨਾਲ ਪੂਰੇ ਕਰੋ: ਜਿਨ੍ਹਾਂ ਜੋੜੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਹੈ ਉਨ੍ਹਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਹਰ ਸਥਾਨਕ ਸਰੋਤ ਲਈ ਇੱਕ ਗੇਟਵੇ ਬਣਾਓ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜੀ ਐਸੋਸੀਏਸ਼ਨ ਨੇ ਟ੍ਰੈਫਿਕ ਚੁੱਕਿਆ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੈਅ ਕਰੋ ਕਿ ਹਰ ਕਿਸਮ ਦੀ ਨਾਕਾਮੀ ਕੀ ਬਦਲ ਸਕਦੀ ਹੈ।
CLI ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜੀਆਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ
ਜੇ ਸਾਈਟ A, A1 ਜਾਂ A2 ਤੋਂ ਸਰੋਤ ਲੈ ਸਕਦੀ ਹੈ ਅਤੇ ਸਾਈਟ B, B1 ਜਾਂ B2 ਉੱਤੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਚਾਰ ਬਾਹਰੀ ਪਤਾ ਜੋੜੀਆਂ ਹਨ। ਬਹੁਤੀਆਂ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਦੋ ਲਗਾਤਾਰ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਬਾਕੀ ਦੋ ਚੋਣਵੀਆਂ ਮੰਨੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਮੈਟ੍ਰਿਕਸ ਲਿਖੋ ਅਤੇ ਹਰ ਕਤਾਰ ਨੂੰ ਨਿਸ਼ਾਨ ਲਗਾਓ, ਕਿਉਂਕਿ ਹਰ ਵਾਅਦਾ ਕੀਤੀ ਕਤਾਰ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਨੂੰ ਇੱਕ ਗੇਟਵੇ, ਇੱਕ ਟਨਲ ਇੰਟਰਫੇਸ ਅਤੇ ਇੱਕ ਰਾਊਟਿੰਗ ਫੈਸਲੇ ਦੀ ਕੀਮਤ ਪਵਾਉਂਦੀ ਹੈ।
| Local source | Remote candidate | Required? |
|---|---|---|
| A1, ISP1 address | B1 | steady state |
| A1, ISP1 address | B2 | decide explicitly |
| A2, ISP2 address | B1 | decide explicitly |
| A2, ISP2 address | B2 | backup path |
ਹਰ ਲੋੜੀਂਦੀ ਜੋੜੀ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਠੀਕ ਉਨ੍ਹਾਂ ਪਤਿਆਂ ਵਿਚਕਾਰ ਪਹੁੰਚਯੋਗ underlay, ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ਸਾਥੀ ਦੀ ਪਛਾਣ ਅਤੇ ਸਰੋਤ ਪਤੇ ਦੀ ਆਪਸੀ ਸਵੀਕ੍ਰਿਤੀ, ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਾਪਸੀ ਰਾਹ। ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀ ਜੋੜੀ ਫਿਰ ਵੀ ਟਨਲ ਦਿਖਾਉਂਦੀ ਹੈ, ਅਤੇ ਨਾਕਾਮੀ ਬਾਅਦ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇੱਕਤਰਫ਼ਾ ਟ੍ਰੈਫਿਕ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ।
ਹਰ ਸਥਾਨਕ ਸਰੋਤ ਲਈ ਇੱਕ ਗੇਟਵੇ, ਦੂਰਲੀ ਸਾਈਟ ਲਈ ਨਹੀਂ
ਦੂਰਲੇ ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਇੱਕ ਗੇਟਵੇ ਦੀ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਸਰੋਤ ਵੀ। IKE ਗੇਟਵੇ ਹਵਾਲਾ ਦੂਰਲੇ ਪਤੇ, ਬਾਹਰੀ ਇੰਟਰਫੇਸ, ਸਥਾਨਕ ਪਤਾ ਅਤੇ ਮ੍ਰਿਤ ਸਾਥੀ ਦੀ ਪਛਾਣ ਨੂੰ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਵਜੋਂ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਗੱਲ ਇਹੀ ਹੈ: ਦੋ ਸਥਾਨਕ ਸਰੋਤ ਭਾਵ ਦੋ st0 ਇਕਾਈਆਂ ਉੱਤੇ ਦੋ ਗੇਟਵੇ। ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ IKE ਨੀਤੀ ਸਾਂਝੀ ਕਰਨਾ ਠੀਕ ਹੈ; ਇੱਕ ਹੀ ਗੇਟਵੇ ਰੱਖ ਕੇ ਇਹ ਆਸ ਕਰਨਾ ਕਿ ਉਹ ਆਪਣੇ ਆਪ ਦੂਜਾ ਸਰੋਤ ਚੁਣ ਲਵੇਗਾ, ਠੀਕ ਨਹੀਂ।
set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-onlyਫਿਰ ਟਨਲ ਜੋੜੋ ਅਤੇ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਦੋ next hop ਦਿਓ, ਹਰ ਟਨਲ ਲਈ ਇੱਕ:
set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20ਕੀ ਇੱਕ ਗੇਟਵੇ address ਕਿਸਮ ਦੀਆਂ ਦੋ ਹਦਾਇਤਾਂ ਰੱਖ ਸਕਦਾ ਹੈ, ਇਹ ਰਿਲੀਜ਼ ਅਤੇ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਡਿਵਾਈਸ ਕਿਹੜੀ IKE ਪ੍ਰਕਿਰਿਆ ਚਲਾ ਰਹੀ ਹੈ। kmd ਅਧਾਰਿਤ ਪੁਰਾਣਾ Junos ਪ੍ਰਤੀ ਗੇਟਵੇ ਇੱਕ ਹੀ ਦੂਰਲਾ ਪਤਾ ਲੈਂਦਾ ਹੈ; ਨਵੇਂ ਬਿਲਡ ਕਈ ਉਮੀਦਵਾਰ ਸੰਭਾਲਦੇ ਹਨ ਪਰ ਆਪਣੀਆਂ ਸੀਮਾਵਾਂ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਉੱਚ ਉਪਲਬਧਤਾ ਕਲਸਟਰ ਆਮ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਇਹ ਸਮਰਥਨ ਤੰਗ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਪੁਰਾਣੇ ਚੈਸਿਸ ਤੋਂ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਸਹੀ ਬਿਲਡ ਦੇ ਰਿਲੀਜ਼ ਨੋਟ ਵੇਖੋ।
ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜੀ ਐਸੋਸੀਏਸ਼ਨ ਨੇ ਪੈਕਟ ਚੁੱਕਿਆ
ਦੋ SA ਅਤੇ ਦੋ ਟਨਲ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਸੈਸ਼ਨ ਕਿਸ ਨੇ ਅੱਗੇ ਭੇਜਿਆ। ਡਿਵਾਈਸ ਨੂੰ ਸਿੱਧਾ ਪੁੱਛੋ ਅਤੇ ਖੇਤਰਾਂ ਦੀ ਤੁਲਨਾ ਉਸ ਜੋੜੀ ਨਾਲ ਕਰੋ ਜੋ ਤੁਹਾਡਾ ਇਰਾਦਾ ਸੀ:
show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packetsਵਿਸਥਾਰ ਵਾਲਾ ਆਉਟਪੁੱਟ ਹਰ ਐਸੋਸੀਏਸ਼ਨ ਲਈ ਸਥਾਨਕ ਅਤੇ ਦੂਰਲਾ ਗੇਟਵੇ ਦੱਸਦਾ ਹੈ, ਜੋ ਅਣਕਿਆਸੇ ਸਰੋਤ ਤੋਂ ਤੈਅ ਹੋਈ ਟਨਲ ਪਛਾਣਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ। ਫਿਰ ਟ੍ਰੈਫਿਕ ਲੰਘਾਉਂਦੇ ਸਮੇਂ st0.1 ਅਤੇ st0.2 ਉੱਤੇ ਪ੍ਰਤੀ ਇਕਾਈ ਪੈਕਟ ਕਾਊਂਟਰ ਵੇਖੋ; ਜੋ ਟਨਲ ਕੁਝ ਨਹੀਂ ਚੁੱਕਦੀ ਉਹ ਆਪਣਾ SA ਰੱਖਦੀ ਹੈ ਅਤੇ ਸਾਰਾਂਸ਼ ਵਿੱਚ ਸਿਹਤਮੰਦ ਦਿਖਦੀ ਹੈ।
ਹਰ ਨਾਕਾਮੀ ਨੂੰ ਉਸ ਦਾ ਆਪਣਾ ਡਿਟੈਕਟਰ ਦਿਓ
ਸਾਥੀ ਦੀ ਜੀਵਨਸ਼ੀਲਤਾ, ਸਥਾਨਕ ਅੱਪਲਿੰਕ ਦਾ ਨੁਕਸਾਨ, ਸੁਰੱਖਿਅਤ ਰਾਊਟ ਦੀ ਵਾਪਸੀ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਟੁੱਟਣਾ ਚਾਰ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਹਨ। DPD ਸਿਰਫ਼ ਪਹਿਲੀ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਅਜਿਹੇ ਅੰਤਰਾਲ ਅਤੇ ਹੱਦ ਨਾਲ ਸੰਰਚਿਤ ਕਰੋ ਜਿਸ ਦਾ ਤੁਸੀਂ ਤਰਕ ਕਰ ਸਕੋ, ਡਿਫਾਲਟ ਛੱਡ ਕੇ ਬਾਕੀ ਸਭ ਢੱਕਦਾ ਹੈ ਮੰਨਣ ਦੀ ਥਾਂ:
set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1ਦੂਰਲੇ ਸਬਨੈੱਟ ਦੇ ਅੰਦਰ ਕਿਸੇ ਮੰਜ਼ਿਲ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲੀ ਟਨਲ ਮੌਨੀਟਰਿੰਗ DPD ਜੋ ਨਹੀਂ ਵੇਖ ਸਕਦਾ ਉਹ ਹਾਲਤ ਢੱਕਦੀ ਹੈ: IKE ਜੀਵਤ ਹੈ, ਗੇਟਵੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਪ੍ਰੀਫਿਕਸ ਫਿਰ ਵੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸ ਨੂੰ ਤਰਜੀਹ ਖਿੱਚਣੀ ਚਾਹੀਦੀ ਹੈ ਚੁਣੋ, ਕਿਉਂਕਿ ਜੇ ਦੋਵੇਂ ਇਕੱਠੇ ਸਰਗਰਮ ਹੋਣ ਤਾਂ ਸਾਫ਼ ਫੇਲਓਵਰ ਦੀ ਥਾਂ ਬਦਲਾਵਾਂ ਦਾ ਤੂਫ਼ਾਨ ਆਉਂਦਾ ਹੈ।
ਦੂਰਲਾ ਸਿਰਾ ਨਾ ਭੁੱਲੋ। ਦੂਰਲੀ ਸਾਈਟ ਉੱਤੇ ਲੱਗਾ ਤਰਜੀਹੀ ਰਾਊਟ ਉਸੇ ਟਨਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਛੱਡ ਚੁੱਕੇ ਹੋ, ਅਤੇ ਕੋਈ ਸਥਾਨਕ ਟਾਈਮਰ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। ਉਹੀ ਤਰਜੀਹ ਤਰਕ ਦੋਵਾਂ ਸਾਥੀਆਂ ਉੱਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਬਹਾਲ ਹੋਈ ਲਿੰਕ ਟ੍ਰੈਫਿਕ ਆਪਣੇ ਆਪ ਵਾਪਸ ਲੈ ਸਕਦੀ ਹੈ ਜਾਂ ਹੱਥ ਨਾਲ ਬਦਲਣੀ ਪਵੇਗੀ।
ਦੂਜੇ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਇੱਕ ਲਿੰਕ ਨੂੰ ਦੁਬਾਰਾ ਪਤਾ ਦਿਓ
ਜਦੋਂ ISP ਤੁਹਾਨੂੰ ਨਵਾਂ ਬਲਾਕ ਦੇਵੇ, ਹਰ ਵਾਰ ਇੱਕ ਸੰਬੰਧ ਬਦਲੋ। ਉਸ ਜੋੜੀ ਲਈ ਦੋਵਾਂ ਸਾਥੀਆਂ ਉੱਤੇ address ਜਾਂ local-address ਅੱਪਡੇਟ ਕਰੋ, commit ਕਰੋ, ਅਤੇ ਡਿਵਾਈਸ ਉੱਤੇ ਸਾਰੇ SA ਸਾਫ਼ ਕਰਨ ਦੀ ਥਾਂ ਸਿਰਫ਼ ਪ੍ਰਭਾਵਿਤ ਐਸੋਸੀਏਸ਼ਨਾਂ ਨੂੰ ਇੰਡੈਕਸ ਨਾਲ ਸਾਫ਼ ਕਰੋ। ਵਿਸ਼ਵਵਿਆਪੀ ਸਫ਼ਾਈ ਸਿਹਤਮੰਦ ਟਨਲ ਵੀ ਲੈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਨੂੰ ਰੁਕਾਵਟ ਬਣਾ ਦਿੰਦੀ ਹੈ।
ਕੁਝ ਵੀ ਸਾਫ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਅਸਫਲ ਫਲੋ ਅਤੇ ਉਸ ਦੇ ਸੈਸ਼ਨ ਦੇ ਵੇਰਵੇ ਸਬੂਤ ਵਜੋਂ ਰੱਖੋ, ਫਿਰ ਉੱਪਰ ਦੀਆਂ ਜਾਂਚਾਂ ਨਵੀਂ ਪਤਾ ਜੋੜੀ ਉੱਤੇ ਦੁਬਾਰਾ ਚਲਾਓ। ਲਿੰਕ ਬਹਾਲ ਕਰਨਾ ਇੱਕ ਰਾਊਟਿੰਗ ਫੈਸਲਾ ਹੈ, ਇਸ ਲਈ ਵਾਪਸੀ ਨੂੰ ਵੱਖਰਾ ਪਰਖਿਆ ਕਦਮ ਮੰਨੋ, ਪੁਰਾਣੀ ਤਰਜੀਹ ਆਪਣੇ ਆਪ ਮੁੜ ਆਵੇਗੀ ਮੰਨਣ ਦੀ ਥਾਂ।
ਬਦਲਾਅ ਨੂੰ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਨਾਲ ਬੰਦ ਕਰੋ
ਡਿਊਲ-WAN ਟਨਲ ਡਿਜ਼ਾਈਨ ਤਦ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਹਰ ਸੈਸ਼ਨ ਪਿੱਛੇ ਦੀ ਜੋੜੀ ਨਾਮ ਲੈ ਸਕਦੇ ਹੋ, ਤਦ ਨਹੀਂ ਜਦੋਂ ਦੋਵੇਂ SA ਉੱਪਰ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੀ ਸੂਚੀ ਉਸ ਡਿਵਾਈਸ ਉੱਤੇ ਵੇਖੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਬਦਲੀ:
- ਹਰ ਵਾਅਦਾ ਕੀਤੀ ਜੋੜੀ ਕੋਲ ਇੱਕ ਗੇਟਵੇ, ਇੱਕ st0 ਇਕਾਈ ਅਤੇ ਇੱਕ ਰਾਊਟ ਐਂਟਰੀ ਹੈ।
- ਹਰ ਟਨਲ ਨੂੰ ਪੈਕਟ ਚੁੱਕਦੇ ਵੇਖਿਆ ਗਿਆ, ਸਿਰਫ਼ SA ਰੱਖਦੇ ਨਹੀਂ।
- ਦੋਵੇਂ ਸਿਰੇ ਪਛਾਣ ਅਤੇ ਇਸ ਉੱਤੇ ਸਹਿਮਤ ਹਨ ਕਿ ਕਿਹੜਾ ਪਾਸਾ ਤਰਜੀਹ ਬਹਾਲ ਕਰਦਾ ਹੈ।
- ਹਰ ਜੋੜੀ ਦਾ ਵਾਪਸੀ ਰਾਹ ਉਸ ਦੇ ਜਾਣ ਵਾਲੇ ਰਾਹ ਦੇ ਕੋਲ ਲਿਖਿਆ ਹੈ।
ਜੇ ਕੋਈ ਕਤਾਰ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਅਗਲੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਜੋੜੀ ਠੀਕ ਕਰੋ; ਦੋ ਅੱਧੀਆਂ ਚੱਲਣ ਵਾਲੀਆਂ ਟਨਲਾਂ ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਰੱਖਣਾ ਕਾਊਂਟਰਾਂ ਨੂੰ ਅਰਥਹੀਣ ਅਤੇ failover ਵਿਵਹਾਰ ਨੂੰ ਅਨੁਮਾਨ ਤੋਂ ਬਾਹਰ ਕਰ ਦਿੰਦਾ ਹੈ।