pseudowire ਅੰਤ ਬਿੰਦੂਆਂ 'ਤੇ VLAN ਟੈਗ ਸਧਾਰਨ ਕਰਨਾ: ਇੱਕ ਰਨਬੁੱਕ

pseudowire ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਹਰ ਗਾਹਕ ਕਿਨਾਰੇ ਨੂੰ ਕਿਹੜਾ ਫਰੇਮ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਧਾਰਨ ਸਥਿਤੀ ਵਿੱਚ CE A ਸੇਵਾ ਸੀਮਿਤ ਕਰਨ ਵਾਲਾ ਇੱਕ ਟੈਗ ਭੇਜਦਾ ਹੈ ਅਤੇ CE B ਬਿਨਾਂ ਟੈਗ ਵਾਲੇ ਫਰੇਮਾਂ ਦੀ ਆਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਫਰਕ ਪ੍ਰੋਵਾਈਡਰ ਕਿਨਾਰੇ 'ਤੇ ਹੀ ਹੱਲ ਹੁੰਦਾ ਹੈ। ਟੈਗ ਸਥਾਨਕ ਨੀਤੀ ਹੈ, ਗਾਹਕ ਦੇ Ethernet ਸਮਝੌਤੇ ਦਾ ਹਿੱਸਾ ਨਹੀਂ, ਅਤੇ pseudowire ਮੂਲ ਫਰੇਮ ਦੀ ਥਾਂ ਸਹਿਮਤ ਫਰੇਮ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਕਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਲਿਖੋ।

ਪਹਿਲਾਂ ਫਰੇਮ ਸਮਝੌਤਾ ਲਿਖੋ

ਅੱਗੇ ਵਾਲੀ ਦਿਸ਼ਾ ਇੱਕ ਟੈਗ ਹਟਾਉਂਦੀ ਹੈ ਅਤੇ ਵਾਪਸੀ ਦਿਸ਼ਾ ਉਹ ਦੁਬਾਰਾ ਜੋੜਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਲਿਖੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਾਹ ਪਰਖੋਗੇ ਅਤੇ ਸਰਕਟ ਨੂੰ ਸਿਹਤਮੰਦ ਐਲਾਨ ਦਿਓਗੇ।

ਸਮਝੌਤੇ ਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਤਬਦੀਲੀ ਟਿਕਟ ਵਿੱਚ ਚਿਪਕਾਇਆ ਜਾ ਸਕੇ: ਕਿਹੜਾ ਕਿਨਾਰਾ ਟੈਗ ਨਾਲ ਭੇਜਦਾ ਹੈ, ਕਿਹੜਾ ਟੈਗ ਤੋਂ ਬਿਨਾਂ ਆਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਟੈਗ ਮੁੱਲ ਸੇਵਾ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।

pseudowire ਮੋਡ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ

RFC 4448 raw ਅਤੇ tagged pseudowire ਮੋਡ ਵਿੱਚ ਫਰਕ ਕਰਦਾ ਹੈ ਅਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਸੇਵਾ ਸੀਮਿਤ ਕਰਨ ਵਾਲੇ ਟੈਗ ਕਿਵੇਂ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ। raw ਮੋਡ ਅਜੇ ਵੀ ਗਾਹਕ ਫਰੇਮ ਨਾਲ ਸੰਬੰਧਿਤ ਟੈਗ ਲੈ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਫਰਕ ਟੈਗ ਦੀ ਸੇਵਾ-ਭੂਮਿਕਾ ਬਾਰੇ ਹੈ, ਸਿਰਫ਼ 802.1Q ਹੈਡਰ ਦੀ ਮੌਜੂਦਗੀ ਬਾਰੇ ਨਹੀਂ। ਮੋਡ ਨੂੰ tagged ਬਨਾਮ untagged ਪੜ੍ਹਨਾ ਇਸ ਕੰਮ ਦੀ ਸੀਮਾ ਗਲਤ ਤੈਅ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ। ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਲੋੜੀਂਦੀਆਂ ਹਨ ਇਹ ਤੈਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਥੀ ਨਾਲ ਮੋਡ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ।

ਫਿਰ ਅਸਲ pseudowire ਕਿਸਮ ਅਤੇ ਸਾਥੀ ਦੇ ਪੈਰਾਮੀਟਰ ਜਾਂਚੋ। ਸਥਾਨਕ VLAN ਅਟੈਚਮੈਂਟ ਅਤੇ ਦੂਰ ਪੋਰਟ ਅਟੈਚਮੈਂਟ ਲਈ ਸਮਰਥਿਤ interworking ਪ੍ਰਬੰਧ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦੋ ਸਥਾਨਕ ਰੀਰਾਈਟ ਬਿਆਨ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ ਕਿ ਐਲਾਨੀ ਸਰਕਟ ਕਿਸਮਾਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ।

ਜੇ control word ਅਤੇ MTU ਦੀਆਂ ਆਸਾਂ ਵੱਖਰੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਗੱਲਬਾਤ ਦੀ ਸਮੱਸਿਆ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਰੀਰਾਈਟ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। ਦੋਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਦੀ ਥਾਂ ਸਾਥੀ ਦੀ ਚੱਲ ਰਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਕਰੋ।

ਸਥਾਨਕ ਟੈਗ ਕਾਰਵਾਈਆਂ ਲਾਗੂ ਕਰੋ

Juniper ਦੀ VLAN CCC ਰੀਰਾਈਟ ਗਾਈਡ pop, push ਅਤੇ swap ਕਾਰਵਾਈਆਂ ਨੂੰ ਪਲੇਟਫਾਰਮ-ਖਾਸ ਪਾਬੰਦੀਆਂ ਨਾਲ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਕਨਫਿਗਰ ਕੀਤੀ ਅਨੁਕੂਲ tagged ਯੂਨਿਟ ਲਈ ਉਦਾਹਰਨ ਦਿਸ਼ਾ ingress 'ਤੇ input-vlan-map pop ਅਤੇ egress 'ਤੇ output-vlan-map push ਹੈ। ਉਹ ਸਤਰਾਂ ਕਾਰਵਾਈਆਂ ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਪੂਰੀ ਇੰਟਰਫੇਸ ਜਾਂ ਸਰਕਟ ਕਨਫਿਗਰੇਸ਼ਨ ਨਹੀਂ। ਇੱਕ ਹੀ ਡਿਵਾਈਸ ਪਰਿਵਾਰ ਦੀ ਉਦਾਹਰਨ ਹਰ ਥਾਂ ਲਾਗੂ ਕਰਨ ਦੀ ਥਾਂ ਸਹੀ ਪਲੇਟਫਾਰਮ ਅਤੇ ਰਿਲੀਜ਼ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਯੂਨਿਟ ਦੀਆਂ ਸਮਰਥਿਤ VLAN ਅਤੇ encapsulation ਸੈਟਿੰਗਾਂ ਨੂੰ ਅਜੇ ਵੀ ਲੋੜੀਂਦਾ ਟੈਗ ਅਤੇ ਵਰਗੀਕਰਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਹੋਵੇਗਾ। ਗਲਤ ਫਰੇਮ ਵਰਗੀਕ੍ਰਿਤ ਕਰਨ ਵਾਲੀ ਯੂਨਿਟ 'ਤੇ ਰੀਰਾਈਟ ਬਿਆਨ ਸਮੱਸਿਆ ਠੀਕ ਨਹੀਂ ਕਰਦਾ, ਉਹਨੂੰ ਹਿਲਾਉਂਦਾ ਹੈ।

ਸੇਵਾ ਲਈ ਲੋੜੀਂਦੇ ਕੋਈ ਵੀ ਅੰਦਰੂਨੀ ਗਾਹਕ ਟੈਗ ਬਚਾਓ। ਸਟੈਕ ਕੀਤੇ ਟੈਗਾਂ ਵਿੱਚ, ਕੁਝ ਵੀ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਬਾਹਰੀ ਟੈਗ ਬਦਲ ਰਹੇ ਹੋ।

ਆਕਾਰ ਦਾ ਬਜਟ ਬਣਾਓ, ਸਿਰਫ਼ ਟੈਗਾਂ ਦਾ ਨਹੀਂ

ਆਕਾਰ ਬਜਟ ਵਿੱਚ ਰੱਖੇ ਗਏ ਟੈਗ, ਅਸਲ MPLS ਸਟੈਕ ਅਤੇ control word ਸ਼ਾਮਲ ਕਰੋ। RFC 8469 Ethernet pseudowire ਲਈ control word ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਿਫ਼ਾਰਸ਼ ਫਰੇਮ ਬਜਟ ਬਦਲ ਦਿੰਦੀ ਹੈ, ਭਾਵੇਂ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਇਸਨੂੰ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਕਰੇ ਜਾਂ ਨਾ। MTU ਬੇਮੇਲ ਨੂੰ ਮਿਲਾਓ, ਇਸਦੀ ਚੇਤਾਵਨੀ ਨੂੰ ਮੁਰੰਮਤ ਵਜੋਂ ਦਬਾਉਣ ਦੀ ਥਾਂ। ਦਬਾਈ ਚੇਤਾਵਨੀ ਤਾਰੀਖ਼ ਮਿਟਾ ਕੇ ਰੱਖੀ ਨਿਯਤ ਰੁਕਾਵਟ ਹੈ।

ਦੋਵੇਂ ਪ੍ਰੋਵਾਈਡਰ ਕਿਨਾਰਿਆਂ 'ਤੇ ਉਹੀ ਬਜਟ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਇੱਕ ਪਾਸੇ ਟੈਗ ਅਤੇ ਦੂਜੇ ਪਾਸੇ control word ਜੋੜਨਾ ਪਹਿਲਾਂ ਠੀਕ ਰਹੇ ਪੇਲੋਡ ਨੂੰ ਤੋੜਨ ਲਈ ਕਾਫ਼ੀ ਹੈ।

ਜੇ ਸੰਖਿਆਵਾਂ ਨਹੀਂ ਮਿਲਦੀਆਂ, ਯੋਜਨਾ ਬਦਲੋ, ਲੌਗਿੰਗ ਪੱਧਰ ਨਹੀਂ।

ਇਸਨੂੰ ਫਰੇਮ ਦਰ ਫਰੇਮ ਸਵੀਕਾਰ ਕਰੋ

ਸਵੀਕ੍ਰਿਤੀ ਲਈ, ਹਰ ਗਾਹਕ ਅਟੈਚਮੈਂਟ 'ਤੇ ਆਸ ਕੀਤਾ ਫਰੇਮ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਵੇਖੋ। ਫਿਰ ਸੇਵਾ ਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦੀ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਨਿਯੰਤਰਣ ਟ੍ਰੈਫਿਕ ਨੂੰ ਮਨਜ਼ੂਰ ਟੈਸਟ ਯੋਜਨਾ ਅਨੁਸਾਰ ਚਲਾਓ, ਕਿਉਂਕਿ ping ਸਹੀ ਸਲਾਮਤ ਪਹੁੰਚਣ ਵਾਲੇ tagged ਫਰੇਮ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ। ingress ਅਤੇ egress ਦਾ ਫਰੇਮ ਸਮਝੌਤਾ ਸਰਕਟ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਦਰਜ ਕਰੋ। ਇਹੀ ਰਿਕਾਰਡ ਅਗਲੀ ਤਬਦੀਲੀ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਮੋਡ, ਟੈਗ ਕਾਰਵਾਈਆਂ, MTU ਬਜਟ ਅਤੇ ਟੈਸਟ ਨਤੀਜਾ ਇੱਕੋ ਥਾਂ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਦਾ ਅਰਥ ਸਿਰਫ਼ ਇਕੱਠੇ ਹੀ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਤਿੰਨ ਟਿਕਟਾਂ ਵਿੱਚ ਵੰਡਣਾ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਉਹੀ ਰੁਕਾਵਟ ਦੁਬਾਰਾ ਲੱਭੇਗਾ।

ਸਰਕਟ ਉਦੋਂ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਉਸ ਸਮਝੌਤੇ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਲਿਖਿਆ ਸੀ, ਉਦੋਂ ਨਹੀਂ ਜਦੋਂ ਪਹਿਲੀ ਦਿਸ਼ਾ ਪਾਸ ਹੋ ਜਾਵੇ।