QFX ਦਾ MAC EVPN ਵਿੱਚ ਕਿਉਂ ਦਿਸਦਾ ਹੈ ਪਰ ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਵਿੱਚ ਨਹੀਂ
EVPN ਡੇਟਾਬੇਸ ਵਿੱਚਲਾ MAC ਕੰਟਰੋਲ ਪਲੇਨ ਦਾ ਤੱਥ ਹੈ, ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਦੇ ਪ੍ਰੋਗਰਾਮ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ। BGP ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਪੜਾਅ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ।
EVPN ਡੇਟਾਬੇਸ ਵਿੱਚ MAC ਲੱਭਣਾ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਰੂਟ ਵਜੋਂ ਐਲਾਨਿਆ ਜਾਂ ਪ੍ਰਾਪਤ ਹੋਇਆ ਸੀ, ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ। ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਇੱਕ ਵੱਖਰੀ ਬਣਤਰ ਹੈ, ਜੋ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਉਹੀ MAC ਇੱਕ ਵਿੱਚ ਦਿਸ ਸਕਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਨਹੀਂ, ਜਦੋਂ ਕਿ ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਸਹੀ ਵਿਵਹਾਰ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇਹਨਾਂ ਦੋਵਾਂ ਆਉਟਪੁੱਟਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਦੀਆਂ ਨਕਲਾਂ ਮੰਨਣਾ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ BGP ਖਰਾਬੀ ਪਿੱਛੇ ਭੇਜਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਅਸਲ ਖਾਲੀ ਥਾਂ ਇੰਪੋਰਟ ਨੀਤੀ ਜਾਂ ਅਣਸੁਲਝਿਆ ਅਗਲਾ ਹੌਪ ਹੈ। ਪੁੱਛਣ ਯੋਗ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਫੈਬਰਿਕ ਨੂੰ MAC ਪਤਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਕਿਸ ਪੜਾਅ 'ਤੇ ਇਸਨੇ ਇਸਨੂੰ ਅੱਗੇ ਭੇਜਣਾ ਬੰਦ ਕੀਤਾ।
ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਾਲੀਆਂ ਦੋ ਟੇਬਲਾਂ
Junos EVPN ਵਿੱਚ ਡੇਟਾਬੇਸ ਹਰ ਇੰਸਟੈਂਸ ਲਈ MAC ਪਤੇ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਵੀ ਕਿ ਹਰ ਇੱਕ ਕਿਵੇਂ ਆਇਆ: ਐਕਸੈਸ ਪੋਰਟ ਤੋਂ ਸਿੱਖਿਆ, Type 2 ਰੂਟ ਵਿੱਚ ਪ੍ਰਾਪਤ, ਜਾਂ ਮਲਟੀਹੋਮਿੰਗ ਗਰੁੱਪ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਨਿਸ਼ਾਨਿਤ। Juniper ਦਾ show evpn database ਹਵਾਲਾ ਦ੍ਰਿਸ਼ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਣ ਵਾਲੇ ਪ੍ਰਤੀ-MAC ਅਤੇ ਪ੍ਰਤੀ-ਇੰਸਟੈਂਸ ਫਿਲਟਰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਇਹ ਇੰਸਟੈਂਸ ਅਤੇ MAC ਨਾਲ ਕੁੰਜੀਬੱਧ ਕੰਟਰੋਲ ਪਲੇਨ ਸਾਰ ਹੈ, ਹਾਰਡਵੇਅਰ ਜਿਸ ਟੇਬਲ ਨਾਲ ਫਰੇਮ ਸਵਿੱਚ ਕਰਦਾ ਹੈ ਉਹ ਨਹੀਂ।
ਸਵਿੱਚਿੰਗ ਟੇਬਲ ਉਹੀ ਫਾਰਵਰਡਿੰਗ ਸਥਿਤੀ ਹੈ। ਦੋਵੇਂ ਆਉਟਪੁੱਟ MAC ਨੂੰ VLAN ਜਾਂ VNI ਸੰਦਰਭ ਦੇ ਕੋਲ ਸੂਚੀਬੱਧ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਉਹਨਾਂ ਦੀ ਲਾਈਨ-ਦਰ-ਲਾਈਨ ਤੁਲਨਾ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਤੁਲਨਾ ਭਰਮਾਉਂਦੀ ਹੈ। ਡੇਟਾਬੇਸ ਵਿੱਚਲੀ ਐਂਟਰੀ ਕਹਿੰਦੀ ਹੈ ਕਿ ਰੂਟ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇੰਸਟੈਂਸ ਵਿੱਚ ਸਵੀਕਾਰਿਆ ਗਿਆ; ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਪਲੇਟਫਾਰਮ ਨੇ ਇਸਨੂੰ ਫਾਰਵਰਡਿੰਗ ਲਈ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ ਜਾਂ ਨਹੀਂ।
Type 2 ਰੂਟ MAC, ਇੱਕ ਚੋਣਵਾਂ IP, ਲੇਬਲ ਜਾਂ VNI, ਰੂਟ ਭੇਦਕ ਅਤੇ ਦੂਰ ਦੇ VTEP ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਅਗਲਾ ਹੌਪ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। ਤਾਰ ਅਤੇ ਉਸ ਰੂਟ ਵਿਚਕਾਰ ਚਾਰ ਚੀਜ਼ਾਂ ਟੁੱਟ ਸਕਦੀਆਂ ਹਨ: ਹੋਸਟ ਕਦੇ ਨਹੀਂ ਸਿੱਖਿਆ ਜਾਂਦਾ, ਰੂਟ ਕਦੇ ਨਹੀਂ ਐਲਾਨਿਆ ਜਾਂਦਾ, ਇੰਪੋਰਟ ਵੇਲੇ ਇਹ ਰੱਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਇਸਦਾ ਅਗਲਾ ਹੌਪ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ। ਹਰ ਅਸਫਲਤਾ ਵੱਖਰਾ ਟੇਬਲ-ਸਮੂਹ ਭਰਿਆ ਛੱਡਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਇਸ ਕ੍ਰਮ ਦਾ ਨਿਦਾਨ ਸੰਭਵ ਹੈ।
ਸਥਾਨਕ ਸਿੱਖਿਆ ਅਜੇ ਵੀ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ
ਆਮ ਧਾਰਨਾ ਹੈ ਕਿ EVPN MAC ਸਿੱਖਿਆ ਆਪਣੇ ਹੱਥ ਲੈ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਖਾਲੀ ਡੇਟਾਬੇਸ ਦਾ ਮਤਲਬ ਓਵਰਲੇ ਸਮੱਸਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਥਾਨਕ ਸਿੱਖਿਆ ਅਜੇ ਵੀ ਐਕਸੈਸ ਪਾਸੇ ਚੱਲਦੀ ਹੈ, VXLAN ਤੋਂ ਪਹਿਲਾਂ ਵਾਂਗ: ਸਵਿੱਚ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫਰੇਮ ਦਾ ਸਰੋਤ MAC ਸਹੀ VLAN ਅਤੇ ਸੇਵਾ ਵਿੱਚ ਸਿੱਖਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਇਸ ਲਈ Type 2 ਬਣਾਉਂਦਾ ਹੈ। ਜਿਸ ਹੋਸਟ ਨੇ ਕੋਈ ਸੰਬੰਧਿਤ ਫਰੇਮ ਨਹੀਂ ਭੇਜਿਆ, ਉਸ ਕੋਲ ਐਲਾਨਣ ਲਈ ਕੁਝ ਨਹੀਂ। ਜਿਸ ਹੋਸਟ ਦੇ ਫਰੇਮ VLAN ਮੈਂਬਰਸ਼ਿਪ, ਫਿਲਟਰ ਜਾਂ ਐਗਰੀਗੇਟ ਦੇ ਡਾਊਨ ਮੈਂਬਰ ਵੱਲੋਂ ਸੁੱਟੇ ਜਾਂਦੇ ਹਨ, ਉਹ ਓਵਰਲੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਇੱਕੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ।
ਅਟੈਚਮੈਂਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੇ ਕਮਾਂਡਾਂ ਨਾਲ ਅੱਗੇ ਵਧੋ। ਟੀਚਾ ਇਹ ਸਾਬਤ ਕਰਨਾ ਹੈ ਕਿ ਹੋਸਟ ਦਾ ਫਰੇਮ ਲੋੜੀਂਦੀ ਸੇਵਾ ਵਿੱਚੋਂ ਲੰਘਿਆ, ਕਿਉਂਕਿ ਕਦੇ ਨਾ ਪਹੁੰਚੇ ਫਰੇਮ ਦੀ ਭਰਪਾਈ ਹੇਠਾਂ ਕੋਈ ਨਹੀਂ ਕਰਦਾ।
show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0
ਬੰਡਲ ਦੇ ਉੱਪਰ ਹੋਣ ਨਾਲੋਂ ਚੁਣੇ ਗਏ LACP ਮੈਂਬਰ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਕਿਉਂਕਿ ਐਗਰੀਗੇਟ ਇੱਕ ਮੈਂਬਰ 'ਤੇ ਉੱਪਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਹੋਸਟ ਦਾ ਟ੍ਰੈਫਿਕ ਡਾਊਨ ਜਾਂ ਬਲੌਕ ਕੀਤੇ ਲਿੰਕ 'ਤੇ ਹੈਸ਼ ਹੁੰਦਾ ਹੈ। ਇੰਟਰਫੇਸ ਕਾਊਂਟਰ ਸ਼ਾਂਤ ਹੋਸਟ ਨੂੰ ਸੁੱਟਣ ਵਾਲੇ ਹੋਸਟ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਕਦੇ ਨਾ ਭੇਜਣ ਵਾਲਾ ਹੋਸਟ ਅਤੇ ਜਿਸ ਹੋਸਟ ਦੇ ਫਰੇਮ ਵਰਗੀਕਰਨ ਨਾਲ ਸੁੱਟੇ ਜਾਂਦੇ ਹਨ, ਦੋਵੇਂ ਉਹੀ ਖਾਲੀ ਟੇਬਲ ਛੱਡਦੇ ਹਨ।
ਦੂਰ ਦਾ MAC ਕਿੱਥੇ ਗੁੰਮ ਹੁੰਦਾ ਹੈ
ਦੂਰ ਦਾ MAC ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਚੁੱਪਚਾਪ। Type 2 ਰੂਟ ਆਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਇੰਸਟੈਂਸ ਵਿੱਚ ਤਦੋਂ ਹੀ ਦਾਖਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਸਦਾ ਰੂਟ ਟਾਰਗੇਟ ਅਤੇ VNI ਸਥਾਨਕ ਸੰਰਚਨਾ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਅਤੇ ਤਦੋਂ ਹੀ ਵਰਤੋਂਯੋਗ ਬਣਦਾ ਹੈ ਜਦੋਂ ਇਸਦਾ ਅਗਲਾ ਹੌਪ ਪਹੁੰਚਯੋਗ VTEP ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਹੈ। ਰੂਟ ਟਾਰਗੇਟ ਦਾ ਅਮੇਲ BGP ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਵੈਧ ਰੂਟ ਛੱਡਦਾ ਹੈ ਜਿਸਦੀ ਕੋਈ ਇੰਸਟੈਂਸ ਕਦੇ ਨਹੀਂ ਮੰਗਦੀ।
ਤਿੰਨ ਦ੍ਰਿਸ਼ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ: ਰੂਟ ਦੀ ਮੌਜੂਦਗੀ, ਡੇਟਾਬੇਸ ਐਂਟਰੀ, ਫਾਰਵਰਡਿੰਗ ਐਂਟਰੀ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਕਮਾਂਡਾਂ ਹਰ ਪੜਾਅ 'ਤੇ ਉਹੀ MAC ਪੁੱਛਦੀਆਂ ਹਨ, ਅਤੇ ਨਮੂਨਾ ਪਤਾ ਆਉਟਪੁੱਟਾਂ ਨੂੰ ਤੁਲਨਾਯੋਗ ਰੱਖਦਾ ਹੈ।
show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive
ਉਹ ਆਉਟਪੁੱਟ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। bgp.evpn.0 ਵਿੱਚ ਰੂਟ ਹੋਵੇ ਪਰ ਡੇਟਾਬੇਸ ਐਂਟਰੀ ਨਾ ਹੋਵੇ ਤਾਂ ਇਹ ਇੰਪੋਰਟ ਨੀਤੀ, ਰੂਟ ਟਾਰਗੇਟ ਜਾਂ ਇੰਸਟੈਂਸ ਸੰਰਚਨਾ ਵੱਲ ਸੰਕੇਤ ਕਰਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਐਂਟਰੀ ਹੋਵੇ ਪਰ ਫਾਰਵਰਡਿੰਗ ਐਂਟਰੀ ਨਾ ਹੋਵੇ ਤਾਂ ਇਹ ਪਲੇਟਫਾਰਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵੱਲ ਸੰਕੇਤ ਕਰਦਾ ਹੈ, ਜੋ ਦੂਜੇ ਐਸਕਲੇਸ਼ਨ ਮਾਰਗ ਦਾ ਹੈ। ਜਿਸ ਸਰਗਰਮ ਰੂਟ ਦਾ ਅਗਲਾ ਹੌਪ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ ਉਹ ਆਵਾਜਾਈ ਜਾਂ ਲੇਬਲ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ MAC ਡੀਬੱਗਿੰਗ ਦੀ ਕੋਈ ਮਾਤਰਾ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀ।
ਜਿਸ ਰੀਬੂਟ ਨੇ ਇਸਨੂੰ ਠੀਕ ਕੀਤਾ ਉਹ ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ
ਜਦੋਂ ਰੀਸਟਾਰਟ ਲੱਛਣ ਨੂੰ ਗਾਇਬ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਲੁਭਾਉਣ ਵਾਲਾ ਸਿੱਟਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਸੰਰਚਨਾ ਠੀਕ ਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਰੀਬੂਟ ਹਰ ਟੇਬਲ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਮੁੜ ਪ੍ਰੋਗਰਾਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਉਹ ਕੇਸ ਵੀ ਲੁਕਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਪੁਰਾਣੀ ਐਂਟਰੀ ਨੀਤੀ ਦੀ ਗਲਤੀ ਨੂੰ ਢੱਕ ਰਹੀ ਸੀ; ਖਰਾਬੀ ਆਮ ਤੌਰ 'ਤੇ ਅਗਲੀ ਤਬਦੀਲੀ, ਲਿੰਕ ਫਲੈਪ ਜਾਂ ਰੂਟ ਵਾਪਸ ਲੈਣ 'ਤੇ ਮੁੜ ਆਉਂਦੀ ਹੈ।
ਕਿਸੇ ਵੀ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਤੋਂ ਪਹਿਲਾਂ, ਰੀਬੂਟ ਕੀ ਮਿਟਾਏਗਾ ਇਹ ਕੈਪਚਰ ਕਰੋ। ਇਹ ਤਿੰਨ ਕਮਾਂਡਾਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੀ ਤੁਲਨਾ ਲਈ ਕਾਫ਼ੀ ਹਨ, ਅਤੇ ਡਿਵਾਈਸ 'ਤੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦੀਆਂ।
show evpn database instance blue
show route table bgp.evpn.0
show version
ਉਹ ਆਉਟਪੁੱਟ ਤਾਰੀਖ਼ ਅਤੇ ਸੌਫਟਵੇਅਰ ਬਿਲਡ ਨਾਲ ਸੰਭਾਲੋ। ਬਾਅਦ ਦੀ ਰਿਪੋਰਟ ਕਿ ਉਹੀ ਰੀਬੂਟ ਪਹਿਲਾਂ ਵੀ ਕੰਮ ਕਰਦਾ ਸੀ, ਸੁਰਾਗ ਹੈ, ਸਬੂਤ ਨਹੀਂ, ਅਤੇ ਫ਼ਰਕ ਤਦੋਂ ਹੀ ਦਿਸਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਨੇ ਪਹਿਲਾਂ ਦਾ ਆਉਟਪੁੱਟ ਰੱਖਿਆ ਹੋਵੇ।
ਚਾਰ ਨਿਰੀਖਣ ਜੋ ਜ਼ਿਆਦਾਤਰ ਕੇਸ ਨਿਪਟਾਉਂਦੇ ਹਨ
ਚਾਰ ਨਿਰੀਖਣ ਲਗਭਗ ਹਰ ਕੇਸ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ: ਅਟੈਚਮੈਂਟ ਅਤੇ ਇਸਦੀ ਸੇਵਾ, ਨਮੂਨਾ ਮੁੱਲ ਵਜੋਂ MAC, ਰੂਟ ਅਤੇ ਡੇਟਾਬੇਸ ਦੀ ਸਥਿਤੀ, ਅਤੇ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਬਿਲਡ। ਅਜਿਹਾ MAC ਚੁਣੋ ਜੋ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਮੂਨਾ ਹੋਵੇ ਤਾਂ ਜੋ ਕੋਈ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਪਤਾ ਨਾ ਸਮਝੇ: ਪਹਿਲਾ ਆਕਟੈਟ 02 ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਯੂਨੀਕਾਸਟ ਪਤਾ ਦਰਸਾਉਂਦਾ ਹੈ, ਬਾਕੀ ਆਕਟੈਟ ਖੁੱਲ੍ਹੇ ਹਨ, ਅਤੇ ਇਸ ਲਈ 02:00:00:00:00:5c ਸੁਰੱਖਿਅਤ ਪਲੇਸਹੋਲਡਰ ਹੈ।
ਫਿਰ ਜਵਾਬਾਂ ਨੂੰ ਅਸਫਲ ਹੋਏ ਪੜਾਅ ਵੱਲ ਸੰਕੇਤ ਕਰਨ ਦਿਓ। ਅਟੈਚਮੈਂਟ 'ਤੇ ਸਿੱਖਿਆ ਨਾ ਹੋਣਾ ਐਕਸੈਸ ਪਾਸਾ ਹੈ; ਡੇਟਾਬੇਸ ਐਂਟਰੀ ਤੋਂ ਬਿਨਾਂ ਰੂਟ ਇੰਪੋਰਟ ਹੈ; ਫਾਰਵਰਡਿੰਗ ਸਥਿਤੀ ਤੋਂ ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਐਂਟਰੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਹੈ। ਜੋ ਵੀ ਹੋਵੇ, ਇਕੱਠੇ ਕੀਤੇ ਆਉਟਪੁੱਟ ਹੋਸਟ, ਇੰਟਰਫੇਸ, ਸੇਵਾ ਅਤੇ ਬਿਲਡ ਨਾਲ ਸੌਂਪੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਸਵਾਲ ਦੁਹਰਾਉਣ ਦੀ ਬਜਾਏ ਮਾਰਗ ਮੁੜ ਬਣਾ ਸਕੇ।