From 4307b5cf1dde0c8b68f7160c0c20c0b758878a04 Mon Sep 17 00:00:00 2001 From: Jagadish Chatrasi Date: Tue, 13 Oct 2020 04:40:49 -0700 Subject: [PATCH 1/8] Adding test plan for LACP helper --- .../switching/lacp_helper/LACP_Helper.png | Bin 0 -> 11026 bytes ...SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md | 97 ++++++++++++++++++ 2 files changed, 97 insertions(+) create mode 100644 TestPlans/switching/lacp_helper/LACP_Helper.png create mode 100644 TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md diff --git a/TestPlans/switching/lacp_helper/LACP_Helper.png b/TestPlans/switching/lacp_helper/LACP_Helper.png new file mode 100644 index 0000000000000000000000000000000000000000..0148e215afd774c2cd1934fd3d72ea50b9c5b558 GIT binary patch literal 11026 zcmeHNX;hO}w+^Dxib7i}v4YT6#Ufy=ei}eRtP`RFbpnwgPKb(tOp-uItXw~8BSuk7 zEl9MW(K3X=6eJ;GFor=u6CuhJ2!s$2G7&N-H$YpX()+7-t$V-457xWhto5F=_da_+ z=h@HZ()T`|3+64E2LJ#Tcc0fo&r0>jJf zu5^Mc_P(1I&0q6TKX_SLW~?qKZ}IYAaXf3^9{^_2JOV6YusiYGa;DC zg6RsO2&bpniZZ zPx)wn+gv2(@>0O{k{9bTvS2-y^I?eYIn5 zUiz$w^^I1{_4X2XF0c24#GH?)sj* z+z(f}mtGUO_H@SQ5AxG?&aAypAmUB7f(+KWxJ7 zoJX#IaA5D9k`1dI&MZ$k;AQgjjkN5C{hGaAN5Ef@cFx=1wtdCLwBtpq9R74|mBSnR z96zrg8rmP^7G0a~w_?uWy&Dqmr%QLOxY%|4d2h(|ZYxLS1ge!t?{RAQ$iU zfN5Pugfk+K3iwdHRxTvkDOtQlVLbgPYR!+M&k(Mk@X3tZ)k7y?!4wC5;k3(;vYNTf;{ky4z!#1(G;VHVsd zyBYbbkN49sy{@j+Y$c&3THgWOZjoJYI2PiefGb6DzvPt~r4xnJs>Tz?fJ(OaC|b_# z5!G#;jDeu~Au!0rsidWCAdN0vZzFVE_PtRSAj0$HP@)`22+Wm9xV6327bh)drhte| z_xemNf%d|_V-`36O6Pm&lD0M>x{#HJwX(C(D+CZ`Z*)&+fUB82d>!r0=c%bNO(W<) zIlQ-ZAHx6EWusJV2;3O|i8;agjx>$QwH4f_l~ZwU733p3EhzSm{2nSzQ8cawDive= zMmw}-a9(BL&lK#lP4DI3dG>LhO>X9ceIFOM!5(G1pwCvERL)-Tv_l1#;f&0jsFkYl zk{FA^ic6{(bhLVY_cI2DcH`YTGYz?(5i3$_=?C&@@F+WwZtt{3W$CBJWR87@E>_H$ zFQaFwKiq1nEECV>FT3fp;>p9Sin9+^+KvIWJzEjt=C!kD%6kT@{v(0+AH79Hw+tx$ ztYH$xiLQT(;;?B^T-pkjoSh!V<)kSX4~nnok5i`1?fVNHf$ouutL^8DPE20mxSb8^ z3Yyf*`qK#*Bi8C|Iu|Wsn2!NPfrbn8RF)OH=E&{Jwl&?519Wk=MB;A*7TxTj+b!)~ zdpta}%8K908*k!AM9-%n_!Nb*8S1>Ut<71;6}5wwzr9d-$+t(tn|Q7l&b!V^(kC7I|&Ye2l)A9wY9xIbuIbSMO29!!aS9Y{_0d` zQ)4woyR8CaDxI@tJ{Z1xg=d-}V27YThY6xUHE1rx(i0aCRX=P|5aIpzzHa6LYUVo=Ky@NzmM(xRKff0Dzil z?S4PT1@5%`EmQfIUlb^cnTIX(_#P%|I3Jv4&zD`;jW$_hLx{L9iGFs_h$5Zp>t;CS1oo+|V6w4YfU_9z4D~(S z^**;cm5=|XaG!Qg73Yc91!0`~VyC4#B_m9~y#J|y>Fe`ZsweP$ZpSl)RA13-PuVxA_o`avtw>fODZ`6 z9*0&p5kXX_G_F8*;m9=nE@3Bl55e|m0qx|L=s@@&Xz}h3sV0)p;l|y8u7){%$Q-HH zbr)X0yROaB=I1c+wuXS zj>+K@J91dOv+**umEIQJbu@Z0SyMx2EaOXmo@J^)P0-zhmqv*pfDKeb?^4xE)k$_> z)MLe+vJ^)v@I|%{?3kG1tBY2WkR)^q+D=)`h!_-?20cbL@N!zH&w1@^nsS8aC{}V4 zpTn~B#Z3QSe%!_v!|#}!<34KIFS&BaC|9&(ck(qf5|}`R1|P*&zV*M1j?3o;Iql zF=0tN%*H87K04Y0l+lUUK&3|cB7#$EZi^DbD`^T&3(Rs90>n8<2ps9_D74hNE{rdw zx8eqe4xEJBX3@~en>;!(9SJurl1!oF)cilz(KDypo46(QZ z22DbWZ&~6MF-mS@5Nxk6weKQFHvqos3-fyX0ykJa94j3f8`?&($x06KI*)rbNPD5m zWJn;rLvrUxon)ksg$25++!K6om8F_5=Q4r9VkxYcS_E%PS=htZJkRC~< zWM9El%S3A|p&d*pEiP;W;)Og6V>DmGC|XVJhB^JZ+!2RVya`NH*vIo(Q7BX8+Ke04 z$(Q`FA1Tu~^c!}%+ii{J^7>)2P6-%4mZRUE7i9~9BYW>lq~N>Z1V@e^YMyC;&8$%v zEpM45=4-2##5LdGQQellmgSoJn*ENGUFn!GhUCg2cN_q1lr(L@pBccUjwb&erT0Nc zBbWk*a9mLGE?*0qsQ}!Y?3J|OA+@^o+n&`F$ed2QC4Nv#PXhi~0P_c@kZuxNICK^H z_^>$N%&dAP-XC3@`F1DC9U6QLA52ZQgC&##IYKU*#@36R^<^r|w#1L{L6UlZsB&b& z)z7ASAKD%chuF=q&h}l3*;n;K8+}|RJsYR0&swpxPWzScDfdF-F4~e1#5h6*Ose-K zO{p3B)r~r?GEjIFs(UFrL8-uiXri1-HCT;llzL>7Q1zwYo0!S8Cr)*>I%}CWSqq3x zav5xuN2&7gsW~j)0VlzxY+Ey&8CALn69#da?V+Z;7rBy(Z=ofxuHXYug=S=hq_hAn zAatmC`#O;qJVbqL9(0?krtA^7jHX=BFP-9j`t8ZfXsCryynAHxQe5ms9XEa|cJ40y z&iTQ`bz{I3BS&BYQ1++VDo=8cjt-(a%t4Fdhbyp2XcLz`_045%gu^>0tcm5O)wo6@w*B)MS+v#o$; zm7$va?B_5f@z0EXUwt!GKBASY!h-$R*K$vVYoA;o)cj)sfI z*lk0go^V4eCIBM4oh73_vGF(G>Nz(O643fsUGh&kwObw!uzS%K&GhZ<7?|D$|10f0 zaY8tY4ocVsQ+7Sb3#A+^rew@F7MFNk1>O4mu4TMF7GC;XT!Dq+3)!$L_VI}QOgJK< zTMoo1PSYhPEQs38#(iIxV07S3T%+_ggxPfah1l0XOsn`MG2GK#OK)2pT59Otz%*-8 z&{Z(zR#}YAPZ(p(j;v0~wKROdfOc|L2P3yu4I4h>k#1pq(H@YO8uk#gKiG!Q^RPZ1@}$Gp}sOQ>aAj2JVDpx-t^v-(E8$#)e>8e5Y;^+m*1-1PX)l0R#Xvr z47Q*cr&**NnTkr3D+U6c2Ndia7+Yjne~d)W|Du zC#{B0Gj!#$W$22aQYNg^U5?alvwb+laQ(HYvbs!{rq%#s0Bj%9witAtj5aQ}Pkir> z@j)g^w5yBTS_%!$*}Zy;acLvM<#H&&I@itpMmS3L?+0aD7(r+gy`^EQGQKlT8QOwU{?iu4H48iOW< zv`v?TbE*;umSsCtDpYq4tq3DojXRamtL;?D`D^aN=BLGzx#q3>PS@ zzS#KT{Kk0rZ8T`^2|WG=@ZOXe065chD)V8#eaRm>3jpxymkF`Qd%5PTFSY^zhr=ht zEATZ@>hVuZ0Ot!_Bi3bfZmqFP|86z_@cV#4DvMe8F?z?`PpA9P@DDFlgJZy%$4m%j uvS6kVX0Tue4rgwJ|K;28l};_x1KvbL-W4I5$_$$UyteslE!=$g!hZvsr{aeI literal 0 HcmV?d00001 diff --git a/TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md b/TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md new file mode 100644 index 000000000000..eb26cee80c31 --- /dev/null +++ b/TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md @@ -0,0 +1,97 @@ +# SQA Test Plan +# LACP Helper +# SONiC 3.1.1 Project and Buzznik Plus MR Release +[TOC] +# Test Plan Revision History +|Rev | Date | Author | Change Description | +|:---:|:----------:|:----------------------:|:-----------------------:| +| 0.1 | 13/10/2020 | Jagadish Ch | Initial version | + + +# List of Reviewers +| Function | Name | +| :------: | :------------------: | +| Dev | Daniel Varagunasingh | +| Dev | Madhukar Kamarapu | +| QA | Anil Kumar Kolkaleti | +| QA | Giri Babu Sajja | + +# List of Approvers +| Function | Name | Date Approved | +| :------: | :------------------: | :-----------: | +| Dev | Daniel Varagunasingh | | +| Dev | Madhukar Kamarapu | | +| QA | Anil Kumar Kolkaleti | | +| QA | Giri Babu Sajja | | + +# Definition/Abbreviation +| Term | Meaning | +|--------|----------------------------------------| +| LAG | Link Aggregation Group | +| LACP | Link Aggregation Control Protocol | +| LACPDU | LACP Data Unit | + + +# Feature Overview +As mentioned in the previous section, there might be a delay for the portchannel member port netdevice to become operational (netdevice creation and link UP in the kernel) post warm boot. If the time gap between the moment last LACPDU is transmitted before system going down (due to warm boot) and the 1st LACPDU transmitted after the system is ready is larger than the LACP timeout (90 seconds), the partner LACP device resets the LACP states and the portchannel on the partner would go DOWN operationally. This results in traffic forwarding failure through the portchannel during warm boot operation. + +To handle this issue, starting SONiC 3.1.1, post warm boot the LACP helper script reads the saved tx LACPDU on a given port and transmit an LACPDU using KNET transmit path per each member port of the portchannel. Only one LACPDU is transmitted using the KNET transmit path. The LACPDU transmitted from the LACP helper resets the LACP timeout to 90-seconds on the partner LAG device. Once the system is ready (post warm boot) and the portchannel member port netdevices become operational (member port netdevice is created and link UP in the kernel), the teamd process transmits the LACPDUs as part of its regular LACP state machine operations; the LACPDU transmission happens using a raw socket per the portchannel member port netdevice. + +Note: Even though LACP helper script transmits an LACPDU before the member port netdevice is operational (in the kernel), if there is a delay in the member port netdevice to become operational in the kernel (link UP), the portchannel on the partner device will become operationally down (due to LACP timeout) and traffic on that portchannel is dropped. + +# Test Approach +- Module prolog constitutes required TG streams creation, LAG creation and adding members to it. +- Test function specific configurations will be handled in the test function itself. +- Functionality tests are covered. + +# 1 Test Focus Areas +## 1.1 Functional Testing + - LACPDU transmission using KNET after warm-boot. + +# 2 Topologies +## 2.1 Topology 1 +![Topology:1](LACP_Helper.png "Figure: LAG ") + + +# 3 Test Case and Objectives + +## 3.1 Functional + +### 3.1.47 Verify that LACP PDUs are sent from a warm-boot device after warm-boot triggered within 90 seconds. +| **Test ID** | **FtOpSoSwLagFn047** | +| -------------- | :--------------------------------------------------------------------------------------------------- | +| **Test Name** | **Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds.**| +| **Test Setup** | **Topology** | +| **Type** | **Functional** | +| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add interconnected ports as members of that LAG in both devices.
3) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up with all the member ports as selected.
3) Verify that LACPDU packet is transmitted from DUT once the warm-boot is triggered after 90 seconds.** | + + +### 3.1.48 Verify that LACP PDUs are sent from only selected members of LAG after warm-boot triggered within 90 seconds. +| **Test ID** | **FtOpSoSwLagFn048** | +| -------------- | :---------------------------------------------------------------------------------------------------------------- | +| **Test Name** | **Verify that LACP PDUs are sent from only selected members of LAG after warm-boot triggered within 90 seconds.** | +| **Test Setup** | **Topology** | +| **Type** | **Functional** | +| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add all interconnected ports(Eth2, Eth3, Eth4, Eth5) as members of that LAG in DUT and few ports(Eth6, Eth9) as members of the LAG in partner.
3) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up only with the members ports Eth2, Eth5 as selected in DUT and Eth6, Eth9 as selected in partner.
3) Verify that LACPDU packet is transmitted from DUT only through the ports(Eth2, Eth5) once the warm-boot is triggered after 90 seconds.** | + + +### 3.1.49 Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with MAX VLANs. +| **Test ID** | **FtOpSoSwLagFn049** | +| -------------- | :--------------------------------------------------------------------------------------------------- | +| **Test Name** | **Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with MAX VLANs.** | +| **Test Setup** | **Topology** | +| **Type** | **Functional** | +| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add interconnected ports as members of that LAG in both devices.
3) Configure 2k VLANs in both the devices.
4) Configure TG connected port and the LAG as tagged members of all the VLANs in both the devices.
5) Send continuous hashed bidirectional traffic with all VLANs.
6) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up with all the member ports as selected.
3) Verify that VLANs are created successfully in both the devices.
4) Verify that LAG and TG connected port are added as tagged members of the VLANs successfully.
5) Verify that traffic is hashed as per expectation.
6) Verify that LACPDU packet is transmitted from DUT once the warm-boot is triggered after 90 seconds.** | + + +### 3.1.50 Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with more static routes which causes the warm-boot time more than 90 seconds. +| **Test ID** | **FtOpSoSwLagFn050** | +| -------------- | :--------------------------------------------------------------------------------------------------- | +| **Test Name** | **Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with more static routes which causes the warm-boot time more than 90 seconds.** | +| **Test Setup** | **Topology** | +| **Type** | **Functional** | +| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add interconnected ports as members of that LAG in both devices.
3) Configure number of static routes which will cause delay the warm-boot more than 90 seconds.
4) Do the L3 configuration on the TG connected ports and LAGs.
5) Send continuous hashed bidirectional L3 traffic.
6) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up with all the member ports as selected.
3) Verify that static routes are created successfully in both the devices.
4) Verify that L3 configuration is successful on LAG and TG connected ports.
5) Verify that traffic is hashed as per expectation.
6) Verify that LACPDU packet is transmitted from DUT once the warm-boot is triggered after 90 seconds.** | + + +# 4 Reference Links +SONIC 3.1.1 'LACP Helper' HLD @ https://github.com/BRCM-SONIC/sonic_doc_private/blob/2310484c0674870064d062295dd3912b6b5febd2/L2/PortChannel/Portchannel_Enhancements.md#7-warm-boot-support \ No newline at end of file From 1f9d3d618305ff7c99d6f238b7a6025e93381c57 Mon Sep 17 00:00:00 2001 From: Jagadish Chatrasi Date: Fri, 11 Jun 2021 13:37:42 -0400 Subject: [PATCH 2/8] Adding Interface down reason Testplan --- .../Interface_Down_Reason.png | Bin 0 -> 15558 bytes ...IC_4_0_0_Interface_Down_Reason_Testplan.md | 238 ++++++++++++++++++ 2 files changed, 238 insertions(+) create mode 100644 TestPlans/system/Interface_Down_reasons/Interface_Down_Reason.png create mode 100644 TestPlans/system/Interface_Down_reasons/SONIC_4_0_0_Interface_Down_Reason_Testplan.md diff --git a/TestPlans/system/Interface_Down_reasons/Interface_Down_Reason.png b/TestPlans/system/Interface_Down_reasons/Interface_Down_Reason.png new file mode 100644 index 0000000000000000000000000000000000000000..e227d2b8cceb9e4bd750ac7bfb11b10994a0fb21 GIT binary patch literal 15558 zcmeHu2UL^Wwr=d(%CP`Sb-NV>DMkd8x-Ecg1w}~cpdc-DkN}aUZbfNvi%5;2D3Jt+ z5FkJZpa>`}A|{m36saNf&_cQE59-HP@Wq{O07| zMFZWfn?yFjV6d%vXU|-M!8WMEV5@U~S`U87T4+%LAFF&W>7IgRH;4^_FKZo7>Ys$c za~GEK&_Ijm@l?8#{Nz$EM-fO?#owwRtLhNuJDQPd~ zj>`rUvZ~U5N=2m$~TuYPebH`35H_#53B_P%hY4+ zF9u|C9T51#UxHV`V3&R#SQ{#ANLvL9l=+uc1L}#P;ajD))GtmZnJ9@=`?n77^XU@dt4_TL`5QUA5k6FYliGMGak* z^EmgdJ9+Cli>!U2V4a2gZyLakduB02xl8KINv|nZl=p^m7tpx`n0Wa!^5jxNzRYn~ zEV+6#&%)JFU^rd~+aEB+W@KkMOphjAm@JNTo3Zg@T=$)pSfT|kb4Jduqt>bR34~R4 zS2w;dvq)B8^Sa+nPUjeuWs65>Z!b?Y7x_A_|8u%IZPl1{;2&><^)!inV=2R3Di=1g z8<#GvyBpEf`pXIO{GMgxD1DAM(dYH?t%PFlh>e%uY%1Hp&N6xQ2^s5qX8Z5RpPlzS z+!m2~j50gZU(x>)3|20=Z(waVCZqH1yoM1NV8iUbjgliTH_auUyN`WA;f>GqUAU|N z0)SS}RX}gYeoM*1^w3;`CH0#=xGQ{)*l(s~v;Wh@X;X_w*e8qA64+R*7(k8P^zGMH zd(wjN@dl)^;!;yyN@j@T|Y)3*>A7CBXJ2i+p=AhYUa7N1#LxK z*IkId6pfV9-^=2GQl5j9&+j>AP2s81v!_toi1*0_xL1XX2Woy&PZ>I{g?6=S#pm^~ zUYdV8DvHk$Puq@rC3Q?IPB@bL(N|8Y(Rug|@77R3M?6Mz4GboH1{|de#Sey}{PKj+ zPKl3Psp_R?Ut2JG(gW87>8O<=ngrwAd(zuf5i~6Yyn3mYUizN;kz4SC} z-d5b;y11r+5nO8VA|^9&C)l1tKrOQ4hN2ePiQEE;sH=M(4U5rjE?MKR0hUfb%rpu5 z+vPYnif2xzM0MbGSFzsnZ@B~X+MvmfH)?Du$AnWO*#BZa&P`&{^?t{FA0AKrMWXt$ zX;DuzLhSB%;L@(^Peu@e_fBwV&F-}9ncy9y6+ z7ec^Hg-?Uiqu_wi4n3F=t@hGFkP>-?+$J6~I}-H8$aITpV?w)bYs9;~B2@djfWLL_ zeq#_O;Rb$x!sTJEw%di!OJ6)}AILn+~rY?N=rC3^k_E{Rp3j#>qQ?akkx~hOjq7LOe)TkFnedSPvg@^?k<;!K;~Tnm`14Hh*3Guw zFLm(0T?JeA8f;nNsdN+dV5_+e%jqU-mrCde@tOA%GmG!sJ?hrX@A+a>G97V*D#1}e zgci<J>-c455OPzPSraVe1`#duC8&` z*ISq|2-)?e2Z*rbcgRCIU@F&uVH$q*wPcRA`1YdH*ST%$VIj);E$>&9ZOER(-k8^K zMV$5;*uMKf~%r0iu=8hxt>rO z5;bbj^-KHbAlk8(Y}dp4$ukp@WSoLDf^AEQ4)hw#w^m|)^3AtPn(If@GIAILJmqK0 zL_=4wq6II=`Xvntl7qpLE6EfF5pNd;NW^U#@F3fiG_0i;=_R18Bl6kH`NWDD;7JD07tZ2OTc!0pI zRr*brT>Jgx7+$@3pH4NLGsY&>+djO2s-_G@oPN$K%qTEGjM8frBs)^}H$^&3mzE`` z_-*QGs>XaSZtEEqs~8x0{EOO^CHu^xhmh6Y`*q&fBeZ>EI)ol{whLZWQ*qF>A;+1P z##juDv`xR&QMLx%Hj=WIJAJ&5W!H14EaoA}&1!_Tc{#U~70k%C^ok~gwD!U2>sx~& zI+ipAmLyKB7;XZE2k+FV?o{mrLW(;HPR?kw*Kp4{IYAO!eJ?`w(xr=@rJh_jY%MV>4Zks|of+O(QS0S&U+gp0w4W6^KEtEi4tBUSJ5L z1sdw298c>p8ztI3JR$RPtAdKBhWgB>$?+0{YP86N`hfcErTWEPy&dsFPp+B;op^gr zVX}PUa$;9ZgYOq~7%~lcEd1nzk=zV^i&TKMBslb1+Sb*Elv#MN6UoQACi5pLV+4%eMXG3>_-_^+y$}drx z7^*>iXd5}U)S7U*pmX`)9abipOw+eZ^4>NxujL`cdfiy}%xG~Ni&={SW0te{Q`Mw7 z982ohZ4d{SqzI%x$@{}hWif^-oeIpPUF-zYkPQ5c=VuD1$UH5x zUlya*uhuz@$6D0uG+zI_0QvrPC>D=bagfu7ZwQjO7!4yGDHa0u*d?E$a`PmV&;(K;KinUTq6 z=vcvi6#>(W%N{p*sQ6C)^Gq(Jw4gEZAhc)D_23uq+O^uQoI}cq<8i%;{LWJMLVb~! zr5H@N_K%axf1wCcY)IW;u#}k8o!ytRkZ^YXQ={JG`cD+6xTMBeqGi6K(5+e3M7N3t z#(>L~nhCm-%rbw>?wvqKEgw|w70EaMIKgx}<9JEmoQ12>TI9{wVU|;NyOSFlrj?`I zYEHDXLmrrs#3;;`JI~>R#ykw1h+YMI2|~369#N?+#RhC%C>C0QX}yy&6`m|_r|B+v z{wzJUH@KDHl!ak? zgVflGTJ~x^l?RhLK9jA5L07(@E8tg1BU7*9N}_`f4$FMx@ob(F+wv^LJ(g@1=y^W_ z1zyL8D&;q9QLKh%^UgbPx_Eah07nqFugaOz4Alp6MYKugO=Q=s0TAFR#=3i;3zz!) z`U8huc~N$_V5`{Sz%JrQN0}TJ8chgTGT=}@KoQ+l!^MY->U+-E`Tao;Ol+yzi!Qz@ z1mAOvu-B*SS<~H<48QT~X70O$zG4q)2d(w3d%QblZRLPC`Tif63+tE$1FjvD(EZYs z6{zOuqLN;DEPHZ5>yWc+m1l8XwA?7(f6>@%Yu$a{^ zWPbQ|d0Phs>pSmjk0zW*s_x>f%2j@BJ2Qqbe=LGl42kRO}6hT27 zBQ^lh3jql!MC=z*p_**o@VB6i8`*(sD8ouU0q=)Ag1QN1GjQ%iNvw&Xbp{UAFc54A zSu)ENWLiRW*s|jDkJ=9>B|By^=pjT@0}$MsWUvMHJ0M$G9%HS^ae4AR9AlU#79r|% zXioV$YP`+?gq;T3iaZN{(f5k8w7BhxEO=wZ3PU17Yt-tq>j`!o1;gy$i$I*L#SCwZ zc<>G#D5_jr@0whNj?}rfJ}F<3-n-6D!^eu)I8&ICk5mGiM^uHu%oth>ke&2t=lgCyk=g()o_<6BRLnrG$U=|Va79Z>AEBr!8B6TzcaGyAEXTkJvCnb}yr`;Z-$&zWiLF+-k@mhevSIZ@E&G-hr9EK= zX{e>`gg#(qx`)A3JX2@ymnvoiC!WF2{yJ}p=*gXZkD0vTOH>KpV1-N@Krr;|U9?BL z&m>(;RZ+{l+P094#krMvW#UOh@t!&LDh}pjM9+5a@}iCFQ-jc^7l~TIRx90W0AJZ1 zD|E|X{0X;;PjM7oTDsw9_ct}GqkNJBe>M4<2>ivoe6T`o)a!lgqlR1dRAV}2z*(j#WVrZ&pnEi?f|6Eztv2d9xQW5{nzmY!vS_ z*`r<{A4{9bbozGP-Z{LMTo{( z{KG`To|@RPTOMo08=M}o({Fm<*8db$`fO!b0|1RkAH|k-E~1zI@YQIuA;7%G)xyo| z81z{RA-j$!qaqopq8dZ^ZNj8oJUF})CnR}O(g*M+u@{K53=!}0Y9l4UX~EP1cUI0- zO-7Dm`i(R5>`Ht>WbqZbZ7)nukHlo9Z79(~Oq!L=kP^Wu4Rrx-J=Bj8`6+kdVqh7q zdIPIpoY*;1-IYWi?z$*AKQ_~NOs;ae(YPK`EQsI$CuwdKdQr+fB1(Hpa2a<{uTNYt%PNhHjzS=qF9NIgjv&Vu9u zs|Q(t*hqXF$SGJbW#1N5;mj(_YQC1Qa(1l-PUB_9YSk5DqgS%PZ-f{d&K)3}2L8u& zSLnGkzT~nKz=j<*!Y1V|jPK#hBD2bn#ZgHpwlR09#Il03v_HY&7`4f?f!FHct%=8S z-}*9ma2ta(YRJvuz>awNI5;I#Y)sy`K90Z0a+ith-fCp!djQJ7mQA1mhYxfyAT z3^uLs(ih##ELdep_2s z3g={beKi!_?c)2z<}9@+E{4`z#Tja0BvfKgCU`1`HJKu3s=Zrerz^jd(FJFLE70SE z=ko299}94L+@}4ij9u9RabGOIyXD3TX={_T0rB(eSZc=`9b`H>hdmeR-)UEFvAai` zA*q0^LSYC2KhX;UHt-=TyB;@iexyIZ>il}1QAuCZ8|C#mO$W$#-=!L^OW*-Ez*svr zXOO5;NT;R7z2s>4Yo?6+Qdydz#M3Uux8)P zQ0%<+R|oA;BSuLCK!|Kt+k#$RanMt=EgPv7B^Q(gU77HdEok_x*EN|IcdydS(OW03 zb!jqvni&%P{qpYHV@@6v!JRBXEE!CO34`Irsv#q)y$%0h4J_NrXZFGrD*$GSolY0? z{wE7`1(l{K{kq~V#IhdL_7my(94LSb%G7N~EO#gk25KC2Qvjk!0a&ej$dy^9%0xQ` zQyr-6NCq$uORGca&(u1QS`wtEB~s)824T>P%(GAElB{*!GP#=m7T=&zpd$@+@Mq5y z7)0DRz!t|D$eZCUO_+{;ICv=biS1*0_MVDfgZN^%>h#w^M3qP-o&w>Whn=dsZX>NT zdMPlG^G?pzqxB*Xr`B1%NzCkg+lCPK+~v^7{vzq2oMw?(zs^%taFT8WPswe<2Xz>g z-DBC>ZNCMGfRIT(JitwQjS+GrsM&f8Dy$O~PCG-vUR!Ph`X+Wr^M%6e()RtTl^Z@( zr#oAW1YPbJ5}zCMR0_97JTWdnPHi*D+qfP>u0W-KSDs#=!lS)m@f~G7ESpMs;CJFf zri+d1Y_j$6^D|TrmS^dry~VrZPG736RefF5N@FKWg?f$^*d2SS*pi70kXP8v&SAHW z&@beW8ywNRQ$D-9vX>&R0HHmHh=ap&>v1%JOyQW5$I#~LE*xhx2UYl8jEUGlu|gUQsJTjV#63prVo1&9uhF*W%Ni(GfliJy<^zM zy+_%dkY&W+O`7)gxA5>DI*K-Hd^#2IVHz=jXc#VTgEusPsguC-@ct=X;P`gStyuS= zC@3$`ob%WnwWk;^r}<2)ARY0aeP^ryNO3XZ23h`x`p*2WV%7TYxIKd;!JCeE)O?i2&h!^qn`3&fd z(3!tG;LCw!;=IetS(@Imp)+Z=e7toVOziR0LRgC~!{c*7i|L#0>P*6xnk-x8A#I}X z)vbli7=|gY+1E8HxAzFiq~=&yPF=7vYoF&)!AXlzGdKhYngO(c0D-yJOhw;x+#xn* zg3Fq)%R25WU2sXQ)a~YL*W~&zR=)W!s<-qHye}%boT*~dT+6vFo|t}sC65gc0G$+~ zA-d(fhI`FKwPRk7MgDq=!EcJ;El%OZTup2Q2>!&VW7)g8WKAXuF!t)kbwvImDH-<5 zy1X4_kGBTy2tc&ni4!f9fIOS}a*1{23&x@5H1(%y9cwYbCaA)tr~4*Q?@EqNEKS#c zI@*_X>7AJZ3RmK%lFs(}f;WvapJ^(SsHvzJ+AKk~ma9oJ5J;zMESq9&Ot?MKoD(zd z0)rD!_Ho5qhALi!llZdKd=zfbZ8e8hu{=l*nhjJZ-Kh452=1j_f0d==`zi4B&zZ~r zJHMgW=kvFEqVvtO+QPp9`jn1-C6J#O1t3dO58{TP>(BXRqvqA4HOKrywUnSIp);vZ zq38-+XIJ7Z{#}O4Dr+Y{RcnPO!xJkM!0hq=0x|5BChpEhRURwKY9zElnhWy`0?QkF z^)+@T6Pg6Q%b?$33Q#&qApakU{aH=6FCU6X0_9SFJrzGTQru)pYQFB)o*iwK)8{z| zrBPw9#|H*}zfgDV{soJAOe5iSdv5;IgCBcW@1l3C#KS}5b7P;1>gEdyu%D0~y9A0e z0qN4`RT_{5*!i;Vmvbj1)mXtjrg$4*S%8t7T#FlXPLP<)VArgP({bDpp`8yhm+waH z^S8!%zz5DadN1#_KEJ-PWl`w#lDg9tTl_hx>&XHj*O~t{*GcRD9t70vqt+|Sy5)z% zfFB2j>wfCa>>GpdnR<+&P^=P}>fjh&*L(C)R~`1 zuFmt1Y)G>qq1}}1Ox5qi<#3kR*@QgH%7N=<8m%1(o6rfqt`0n*TavnEYhMN#sQdo` z(eO6S(Unhsx~%_XD>SIsj%%+4smwvR<8o|uVnv8;d#9c$lzg}!xd3lhkf``(jfVFm znJq?!5Ql0?2;P%{(lQAVG>CzJ$H0wf9YiMwW&RSrH*b?(ZR$1Cwa<$x%d{j*`OAWt z=z}d{`{-j&M9B0<&Mw-8L^U84>h8Y_Q_U|u&ydSuW_&U3{ubepB1Fm((oCh=okFxFo1&6g|A z&O4U%RErMb^?CEZevcN==|NUsv!HqJ|DFZyMKIJTkE5Q>yPuve9zXDr3Y;tqMqP{Z z+?vAhYnPeZ=Wt6#2#yj2`zLU)A>OaZ&GFM$AUY7m&*U0`!M-RxB!|w0A_FCzPMqj6| zTk}$6U}D{bSk%b?wr$kK45-KwfD`qT2LsL1s{^P0oC5GGZYP=ZxdE6w(hW!7x}p5t z#HROK{|Bam-|PP;0SB1tkD30E0i?43{(A6{nSc@v-T4ufk2?JN+#zcAU{22UEEs;G z6e8V|WB#g6Aw7GY|IbFv6Y(y%V&){wKfD<#SMH{P)CRQZ6{i3H=uW;4kcsACQch7w zh9=ZiXb^yY-NXM08I;d~urXB8f}b;zCR+9+ z4u>m+otuHC3oH2pz}i{Q%3awj5xDlctA{1z-$6Klu<4z79wyEIy*&t{^3xq#%^RU0 zyr$(JgK&QB6D*Vhk-Ne!kmJvN5nL1ec+1lqYP`LszUy}a5OKfA z45TqWX*GKEOJDg*mJf=t?|IJvPP}d#wQ09-|MdZoT{m3&1aa1U{qu@_hw9~)7Uw(( zmi&1eLVL4#4S)SrXN61+8|g9AGpfI8K*|^@o`)HLLZ?v0*3DCz0aV#~Ks_!#rk~%# zlaV~ZhX!L1aWWQ$Q|7SOaFYt2I zBKNh5(7Pr=bqU-?V4>|$<~Gn={kMb3csg(krE4Wq8lyd$+>OVt^nHslK=4`kKdDRt zDTfyY4Z@FBcV7(t`{%2S2}!N>CJ|LOumFv!2Cbn!>eKmz~U(k(Xxp&}|j zY$fYUz_?}Fek9CKIWS7EvwZS(%;;uQ=mx(MZmx9#f=O)#iISYag^Ev52vevEP8iJk z>bKnQOkQ|nv(7cC2vg(ho91St9=(JjvF;iuRqb!?v%8k7$_%iOw`*~G#1pAqRMIzYIg9uq_kG$Vauq}s#MwK$i8zmS|({u`51U2=UGB)sasX?Rx|z%>E!!r zZrBYwNMxWG$X!i`UMo$g7j7e4yNNnUGz}Z{q ztxHv{3n_6;c|BuSk$_TIZT!puTwDVin%S5&#L17X{+4kr7544}m01dQZT0hD4f0$gF$~ljKh){nI`LFtIa)-zQwjgGX--*yaiydf9J!v zFvTxbk(B3|K)-Fa4f(#{*wQF z5hplckX`LQEoj7gbkD|N2M#sQ3?ozILFqf;R4!DjDRIp#>gi0~v6o31*RGQ*xLW^B zsV1y^Gq8!F5qZ0>Jyk49>G6gCuZkmbR1m}8lEF?wh=x7myy_(pT$Xj6!3jQedI{2~ zW9w&PtrF2zoc%EkOB_%o0hNxl$rbzp`0R8~obK{Tgq`A@%3Y*CXJO87qgL>oFUOfx zI}~_8NtmcQ&chsmzV|`jYcRhPDv-=HLm^Cfc5WAG(KfsplUHWE>hov6UHS3ElyMJ1 zp*}=x(vkeegfm4vkoQIEq47MUs*&S7(=eo;8R?QDPveo=SGEN*hTYl#$d>a43@8k& z_VtU}0op?z z@@;-QBM9V$yx-VVDnZV=ZwXP*=I0bC;jJ%(vzShfU7|EpW(6Bnjn-)o)Ta-%pr$lx z7+OhC^%=B2m;v-p7M<14$X0akCQOp=A&OCfyzTq9*nHcmr&n_UX;bg5_^puLfm7!b z@XGXpWiy&Xk3WMyj*O^EE%D9Kd9h+GS5Tr3x3E=KXYLs~FbSO&E};00uBkq%RlTTp zwB8Ag&q + Link training failed
+ Link training not completed
+ Link training not started
+ Link tuning failed
+ Link tuning not started
+ Link tuning not completed
+ High BER
+ PCS AM lock error
+ PCS sync error
+ Transceiver error disabled
+ + + +## 2 Topologies + + ![Topology](Interface_Down_Reason.png "Figure: Topology 1") + + +#### Topology 1 +Topology Description - +- Configure PortChannel in DUT1 and DUT2 and add inter connected ports as members of that PortChannel.
+**Note:** This configuration is applicable only for the PortChannel test cases. + + +## 3 Test Case and objectives + + +### 3.1 Functional Test Cases + +#### 3.1.1 Validate interface down reason "Admin down" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_001** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Admin down" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Shutdown the Ethernet1 in DUT1 and observe the down reason for that port is updated as "Admin down" in the "show interface status" output.| + +#### 3.1.2 Validate interface down reason "Remote fault" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_002** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Remote fault" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Shutdown the Ethernet2 in DUT2 and observe the down reason for that port is updated as "Admin down" in DUT2 and "Remote fault" in DUT1 for the corresponding port(Ethernet2) in the "show interface status" output.| + +#### 3.1.3 Validate interface down reason "Transceiver not present" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_003** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Transceiver not present" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Don't insert any transceiver in the SFP/SFP+/QSFP/QSFP+ module of DUT1.
2. Observe interface down reason will be shown as "Transceiver not present" for the respective ports in the "show interface status" output.| + +#### 3.1.4 Validate interface down reason "Incompatible transceiver" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_004** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Incompatible transceiver" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Insert unsupported/speed incompatible transceivers in Ethernet3 of DUT1, supported transceiver in DUT2 and observe the interface down reason for Ethernet3 is updated as "Incompatible transceiver" in "show interface status" output of DUT1.| + +#### 3.1.5 Validate link up reason "PHY link up" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_005** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate link up reason "PHY link up" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Make the port as up using PHY loopback and observe the link up reason for the port is updated as "PHY link up" in "show interface status" output.| + +#### 3.1.6 Validate interface down reason "Port breakout in-progress" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_006** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Port breakout in-progress" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Breakout the port supported modes and observe the interface down reason for the port is updated as "Port breakout in-progress" during the breakout process in "show interface status" output.| + +#### 3.1.7 Validate interface down reason "STP error disabled" for physical interface with STP mode as "pvst". + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_007** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "STP error disabled" for physical interface with STP mode as "pvst".** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add Ethernet1 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on Ethernet1 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on Ethernet1 of DUT1 with port shutdown on bpdu guard violation.
9. Observe Ethernet1 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on Ethernet1 of DUT2
11. Observe after the recovery interval(30 seconds) Ethernet1 will come Up in DUT1.| + +#### 3.1.8 Validate interface down reason "STP error disabled" for physical interface with STP mode as "rapid-pvst". + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_008** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "STP error disabled" for physical interface with STP mode as "rapid-pvst".** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add Ethernet1 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "rapid-pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on Ethernet1 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on Ethernet1 of DUT1 with port shutdown on bpdu guard violation.
9. Observe Ethernet1 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on Ethernet1 of DUT2
11. Observe after the recovery interval(30 seconds) Ethernet1 will come Up in DUT1.| + +#### 3.1.9 Validate interface down reason "UDLD error disabled" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_009** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "UDLD error disabled" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Configure errdisable recovery cause udld in DUT1.
2. Configure errdisable recovery interval as 30 seconds in DUT1.
3. Enable UDLD globally in DUT1 and DUT2.
4. Configure message-time and multiplier as 2 and 3 respectively in DUT1 and DUT2.
5. Enable UDLD on Ethernet1 of both DUT1 and DUT2.
6. Enable UDLD packets blocking on Ethernet1 of DUT1
7. Observe Ethernet1 go down and the interface down reason will be updated as "UDLD error disabled" in the "show interface status err-disabled" output in DUT1.
8. Enable UDLD packets blocking on Ethernet1 of DUT1.
9. Observe after the recovery interval(30 seconds) Ethernet1 will come Up in DUT1.| + +#### 3.1.10 Validate interface down reason "Link flap error disabled" for physical interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_010** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Link flap error disabled" for physical interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Enable link flap error disable on Ethenet4 of DUT1 with flap-threshold 2, sampling-time 10, recovery-timeout 15.
2. Do shutdown and no-shutdown Ethernet4 of DUT2 for 3 times within 10 seconds.
3. Observe the interface down reason for Ethernet4 of DUT1 will be updated as "Link flap error disabled" in the "show interface status err-disabled" output.
4. The Link flap error disabled port will come up after 15 seconds of recovery-time.| + +#### 3.1.11 Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "pvst". + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_011** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "pvst".** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add PortChannel7 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on PortChannel7 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on PortChannel7 of DUT1 with port shutdown on bpdu guard violation.
9. Observe PortChannel7 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on PortChannel7 of DUT2
11. Observe after the recovery interval(30 seconds) PortChannel7 will come Up in DUT1.| + +#### 3.1.12 Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "rapid-pvst". + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_012** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "rapid-pvst".** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add PortChannel7 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "rapid-pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on PortChannel7 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on PortChannel7 of DUT1 with port shutdown on bpdu guard violation.
9. Observe PortChannel7 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on PortChannel7 of DUT2
11. Observe after the recovery interval(30 seconds) PortChannel7 will come Up in DUT1.| + + +#### 3.1.13 Validate interface down reason "Min-links-not-met" for PortChannel interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_013** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Min-links-not-met" for PortChannel interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Configure the PortChannels with min-links as 4 in both the DUTs.
2. Remove one of the member ports from PortChannel in DUT1.
3. Observe that interface down reason will be updated as "Min-links-not-met(DM)" in the "show PortChannel summary" output in DUT1.
4. Add the member port back to the PortChannel and observe PortChannel is Up in both the devices.
5. Shutdown one of the member ports of PortChannel in DUT1.
6. Observe that interface down reason will be updated as "Min-links-not-met(DM)" in the "show PortChannel summary" output of DUT1.
7. no shutdown the member port of PortChannel in DUT1 and observe PortChannel is Up in both the devices.
8. Remove one of the member ports from PortChannel in DUT2.
9. Observe that interface down reason will be updated as "Min-links-not-met(DM)" in the "show PortChannel summary" output in DUT1.
10. Add the member port back to the PortChannel and observe PortChannel is Up in both the devices.
| + +#### 3.1.14 Validate interface down reason "Admin-down" for PortChannel interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_014** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "Admin-down" for PortChannel interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Shutdown the PortChannel in DUT1 and observe the down reason for that PortChannel is updated as "Admin down(DA)" in the "show PortChannel summary" output of DUT1.
2. Do no-shutdown the PortChannel in DUT1 and shutdown the PortChannel in DUT2.
3. Observe the interface down reason is shown as "LACP-convergence-failed(DL)" in DUT1 and shown as "Admin-down(DA)" in DUT2.| + +#### 3.1.15 Validate interface down reason "LACP-convergence-failed" for PortChannel interface. + +| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_015** | +| -------------- | :----------------------------------------------------------- | +| **Test Name** | **Validate interface down reason "LACP-convergence-failed" for PortChannel interface.** | +| **Test Setup** | **Topology 1** | +| **Type** | **Functional** | +| **Steps** | 1. Configure PortChannel7 in DUT1 and DUT3, PortChannel7 and PortChannel8 in DUT2.
2. Add Ethernet1, Ethernet2, Ethernet3, Ethernet4, Ethernet5, Ethernet6 as members of PortChannel7 in DUT1.
3. Add Ethernet1, Ethernet2 as members of PortChannel8.
4. Add Ethernet3, Ethernet4 as members of PortChannel7 in DUT2.
5. Add Ethernet5, Ethernet6 as members of PortChannel7 in DUT3.
6. Observe PortChannel7 is Up with Ethernet1 and Ethernet2 as the only active members in DUT1.
7. Observe the interface down reason for PortChannel7 is shown as "LACP-convergence-failed(DL)" in DUT2 and DUT3.
**Note:** Strictly follow the sequence of above steps.| + +
+
+ + + + + + +### 3.4 Management + +#### 3.4.1 REST + +## Reference Links + +https://github.com/BRCM-SONIC/sonic_doc_private/blob/195022db0525816d61edeb31ebc1dee1615398e1/system/Interface_Down_Reason.md \ No newline at end of file From 53d2f83b027aae5a8aec1af4daec155b1e9763cb Mon Sep 17 00:00:00 2001 From: jagadish-chatrasi <56671476+jagadish-chatrasi@users.noreply.github.com> Date: Mon, 14 Jun 2021 12:32:35 +0530 Subject: [PATCH 3/8] Delete SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md Test plan already coved in legacy test suite --- ...SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md | 97 ------------------- 1 file changed, 97 deletions(-) delete mode 100644 TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md diff --git a/TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md b/TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md deleted file mode 100644 index eb26cee80c31..000000000000 --- a/TestPlans/switching/lacp_helper/SQA_Buzznik_3_1_1_LACP_Helper_Test_Plan.md +++ /dev/null @@ -1,97 +0,0 @@ -# SQA Test Plan -# LACP Helper -# SONiC 3.1.1 Project and Buzznik Plus MR Release -[TOC] -# Test Plan Revision History -|Rev | Date | Author | Change Description | -|:---:|:----------:|:----------------------:|:-----------------------:| -| 0.1 | 13/10/2020 | Jagadish Ch | Initial version | - - -# List of Reviewers -| Function | Name | -| :------: | :------------------: | -| Dev | Daniel Varagunasingh | -| Dev | Madhukar Kamarapu | -| QA | Anil Kumar Kolkaleti | -| QA | Giri Babu Sajja | - -# List of Approvers -| Function | Name | Date Approved | -| :------: | :------------------: | :-----------: | -| Dev | Daniel Varagunasingh | | -| Dev | Madhukar Kamarapu | | -| QA | Anil Kumar Kolkaleti | | -| QA | Giri Babu Sajja | | - -# Definition/Abbreviation -| Term | Meaning | -|--------|----------------------------------------| -| LAG | Link Aggregation Group | -| LACP | Link Aggregation Control Protocol | -| LACPDU | LACP Data Unit | - - -# Feature Overview -As mentioned in the previous section, there might be a delay for the portchannel member port netdevice to become operational (netdevice creation and link UP in the kernel) post warm boot. If the time gap between the moment last LACPDU is transmitted before system going down (due to warm boot) and the 1st LACPDU transmitted after the system is ready is larger than the LACP timeout (90 seconds), the partner LACP device resets the LACP states and the portchannel on the partner would go DOWN operationally. This results in traffic forwarding failure through the portchannel during warm boot operation. - -To handle this issue, starting SONiC 3.1.1, post warm boot the LACP helper script reads the saved tx LACPDU on a given port and transmit an LACPDU using KNET transmit path per each member port of the portchannel. Only one LACPDU is transmitted using the KNET transmit path. The LACPDU transmitted from the LACP helper resets the LACP timeout to 90-seconds on the partner LAG device. Once the system is ready (post warm boot) and the portchannel member port netdevices become operational (member port netdevice is created and link UP in the kernel), the teamd process transmits the LACPDUs as part of its regular LACP state machine operations; the LACPDU transmission happens using a raw socket per the portchannel member port netdevice. - -Note: Even though LACP helper script transmits an LACPDU before the member port netdevice is operational (in the kernel), if there is a delay in the member port netdevice to become operational in the kernel (link UP), the portchannel on the partner device will become operationally down (due to LACP timeout) and traffic on that portchannel is dropped. - -# Test Approach -- Module prolog constitutes required TG streams creation, LAG creation and adding members to it. -- Test function specific configurations will be handled in the test function itself. -- Functionality tests are covered. - -# 1 Test Focus Areas -## 1.1 Functional Testing - - LACPDU transmission using KNET after warm-boot. - -# 2 Topologies -## 2.1 Topology 1 -![Topology:1](LACP_Helper.png "Figure: LAG ") - - -# 3 Test Case and Objectives - -## 3.1 Functional - -### 3.1.47 Verify that LACP PDUs are sent from a warm-boot device after warm-boot triggered within 90 seconds. -| **Test ID** | **FtOpSoSwLagFn047** | -| -------------- | :--------------------------------------------------------------------------------------------------- | -| **Test Name** | **Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds.**| -| **Test Setup** | **Topology** | -| **Type** | **Functional** | -| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add interconnected ports as members of that LAG in both devices.
3) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up with all the member ports as selected.
3) Verify that LACPDU packet is transmitted from DUT once the warm-boot is triggered after 90 seconds.** | - - -### 3.1.48 Verify that LACP PDUs are sent from only selected members of LAG after warm-boot triggered within 90 seconds. -| **Test ID** | **FtOpSoSwLagFn048** | -| -------------- | :---------------------------------------------------------------------------------------------------------------- | -| **Test Name** | **Verify that LACP PDUs are sent from only selected members of LAG after warm-boot triggered within 90 seconds.** | -| **Test Setup** | **Topology** | -| **Type** | **Functional** | -| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add all interconnected ports(Eth2, Eth3, Eth4, Eth5) as members of that LAG in DUT and few ports(Eth6, Eth9) as members of the LAG in partner.
3) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up only with the members ports Eth2, Eth5 as selected in DUT and Eth6, Eth9 as selected in partner.
3) Verify that LACPDU packet is transmitted from DUT only through the ports(Eth2, Eth5) once the warm-boot is triggered after 90 seconds.** | - - -### 3.1.49 Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with MAX VLANs. -| **Test ID** | **FtOpSoSwLagFn049** | -| -------------- | :--------------------------------------------------------------------------------------------------- | -| **Test Name** | **Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with MAX VLANs.** | -| **Test Setup** | **Topology** | -| **Type** | **Functional** | -| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add interconnected ports as members of that LAG in both devices.
3) Configure 2k VLANs in both the devices.
4) Configure TG connected port and the LAG as tagged members of all the VLANs in both the devices.
5) Send continuous hashed bidirectional traffic with all VLANs.
6) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up with all the member ports as selected.
3) Verify that VLANs are created successfully in both the devices.
4) Verify that LAG and TG connected port are added as tagged members of the VLANs successfully.
5) Verify that traffic is hashed as per expectation.
6) Verify that LACPDU packet is transmitted from DUT once the warm-boot is triggered after 90 seconds.** | - - -### 3.1.50 Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with more static routes which causes the warm-boot time more than 90 seconds. -| **Test ID** | **FtOpSoSwLagFn050** | -| -------------- | :--------------------------------------------------------------------------------------------------- | -| **Test Name** | **Verify that LACP PDUs are sent from warm-boot device after warm-boot triggered within 90 seconds with bidirectional traffic sent with more static routes which causes the warm-boot time more than 90 seconds.** | -| **Test Setup** | **Topology** | -| **Type** | **Functional** | -| **Steps** | **Procedure:
1) Configure LAG in both DUT and Partner.
2) Add interconnected ports as members of that LAG in both devices.
3) Configure number of static routes which will cause delay the warm-boot more than 90 seconds.
4) Do the L3 configuration on the TG connected ports and LAGs.
5) Send continuous hashed bidirectional L3 traffic.
6) Warm-boot the device.
Expected Result:
1) Verify that LAG is successfully configured in both DUT and partner.
2) Verify that LAG is up with all the member ports as selected.
3) Verify that static routes are created successfully in both the devices.
4) Verify that L3 configuration is successful on LAG and TG connected ports.
5) Verify that traffic is hashed as per expectation.
6) Verify that LACPDU packet is transmitted from DUT once the warm-boot is triggered after 90 seconds.** | - - -# 4 Reference Links -SONIC 3.1.1 'LACP Helper' HLD @ https://github.com/BRCM-SONIC/sonic_doc_private/blob/2310484c0674870064d062295dd3912b6b5febd2/L2/PortChannel/Portchannel_Enhancements.md#7-warm-boot-support \ No newline at end of file From 6cf329b8662b07f621ba63d5cb7509fe651b8686 Mon Sep 17 00:00:00 2001 From: jagadish-chatrasi <56671476+jagadish-chatrasi@users.noreply.github.com> Date: Mon, 14 Jun 2021 14:03:54 +0530 Subject: [PATCH 4/8] Delete SONIC_4_0_0_Interface_Down_Reason_Testplan.md Incorrect Push. Here's the correct push: https://github.com/BRCM-SONIC/sonic_doc_private/pull/223/ --- ...IC_4_0_0_Interface_Down_Reason_Testplan.md | 238 ------------------ 1 file changed, 238 deletions(-) delete mode 100644 TestPlans/system/Interface_Down_reasons/SONIC_4_0_0_Interface_Down_Reason_Testplan.md diff --git a/TestPlans/system/Interface_Down_reasons/SONIC_4_0_0_Interface_Down_Reason_Testplan.md b/TestPlans/system/Interface_Down_reasons/SONIC_4_0_0_Interface_Down_Reason_Testplan.md deleted file mode 100644 index ef67c1e43635..000000000000 --- a/TestPlans/system/Interface_Down_reasons/SONIC_4_0_0_Interface_Down_Reason_Testplan.md +++ /dev/null @@ -1,238 +0,0 @@ -# SQA Test Plan -# SONIC Interface Down Reason -# SONiC 4.0.0 Release - -## Test Plan Revision History - -| Rev | Date | Author | Change Description | -| ---- | ---------- | --------------- | ------------------ | -| 0.1 | 6/11/2021 | Jagadish Ch | Initial Version | -| 0.2 | | | | - -## List of Reviewers - -| Function | Name | -| :------: | :--: | -| QA | Chandra Bhushan Singh | -| DEV | Prasanth K V | - -## List of Approvers - -| Function | Name | Date Approved | -| :------: | :--: | :-----------: | -| | | | -| | | | - -## Definition/Abbreviation - -| **Term** | **Meaning** | -| -------- | -------------------------- | -| | | -| | | - -## Feature Overview - - This feature is to help the user in finding the reason for Physical/PortChannel interfaces down easier. - -## 1 Test Focus Areas - - - This Test plan covers the validation of all the down reasons of Physical/PortChannel interfaces. - -### 1.1 Functional Testing - - - Validate interface down reason "Admin down" for physical interface. - - Validate interface down reason "Remote fault" for physical interface. - - Validate interface down reason "Transceiver not present" for physical interface. - - Validate interface down reason "Incompatible transceiver" for physical interface. - - Validate interface up reason "PHY link up" for physical interface. - - Validate interface down reason "Port breakout in-progress" for physical interface. - - Validate interface down reason "STP error disabled" for physical interface with STP mode as "pvst". - - Validate interface down reason "STP error disabled" for physical interface with STP mode as "rapid-pvst". - - Validate interface down reason "UDLD error disabled" for physical interface. - - Validate interface down reason "Link flap error disabled" for physical interface. - - Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "pvst". - - Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "rapid-pvst". - - Validate interface down reason "Min-links-not-met" for PortChannel interface. - - Validate interface down reason "Admin-down" for PortChannel interface. - - Validate interface down reason "LACP-convergence-failed" for PortChannel interface. - - Below interface down reasons will be added later.
- Link training failed
- Link training not completed
- Link training not started
- Link tuning failed
- Link tuning not started
- Link tuning not completed
- High BER
- PCS AM lock error
- PCS sync error
- Transceiver error disabled
- - - -## 2 Topologies - - ![Topology](Interface_Down_Reason.png "Figure: Topology 1") - - -#### Topology 1 -Topology Description - -- Configure PortChannel in DUT1 and DUT2 and add inter connected ports as members of that PortChannel.
-**Note:** This configuration is applicable only for the PortChannel test cases. - - -## 3 Test Case and objectives - - -### 3.1 Functional Test Cases - -#### 3.1.1 Validate interface down reason "Admin down" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_001** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Admin down" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Shutdown the Ethernet1 in DUT1 and observe the down reason for that port is updated as "Admin down" in the "show interface status" output.| - -#### 3.1.2 Validate interface down reason "Remote fault" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_002** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Remote fault" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Shutdown the Ethernet2 in DUT2 and observe the down reason for that port is updated as "Admin down" in DUT2 and "Remote fault" in DUT1 for the corresponding port(Ethernet2) in the "show interface status" output.| - -#### 3.1.3 Validate interface down reason "Transceiver not present" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_003** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Transceiver not present" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Don't insert any transceiver in the SFP/SFP+/QSFP/QSFP+ module of DUT1.
2. Observe interface down reason will be shown as "Transceiver not present" for the respective ports in the "show interface status" output.| - -#### 3.1.4 Validate interface down reason "Incompatible transceiver" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_004** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Incompatible transceiver" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Insert unsupported/speed incompatible transceivers in Ethernet3 of DUT1, supported transceiver in DUT2 and observe the interface down reason for Ethernet3 is updated as "Incompatible transceiver" in "show interface status" output of DUT1.| - -#### 3.1.5 Validate link up reason "PHY link up" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_005** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate link up reason "PHY link up" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Make the port as up using PHY loopback and observe the link up reason for the port is updated as "PHY link up" in "show interface status" output.| - -#### 3.1.6 Validate interface down reason "Port breakout in-progress" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_006** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Port breakout in-progress" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Breakout the port supported modes and observe the interface down reason for the port is updated as "Port breakout in-progress" during the breakout process in "show interface status" output.| - -#### 3.1.7 Validate interface down reason "STP error disabled" for physical interface with STP mode as "pvst". - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_007** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "STP error disabled" for physical interface with STP mode as "pvst".** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add Ethernet1 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on Ethernet1 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on Ethernet1 of DUT1 with port shutdown on bpdu guard violation.
9. Observe Ethernet1 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on Ethernet1 of DUT2
11. Observe after the recovery interval(30 seconds) Ethernet1 will come Up in DUT1.| - -#### 3.1.8 Validate interface down reason "STP error disabled" for physical interface with STP mode as "rapid-pvst". - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_008** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "STP error disabled" for physical interface with STP mode as "rapid-pvst".** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add Ethernet1 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "rapid-pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on Ethernet1 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on Ethernet1 of DUT1 with port shutdown on bpdu guard violation.
9. Observe Ethernet1 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on Ethernet1 of DUT2
11. Observe after the recovery interval(30 seconds) Ethernet1 will come Up in DUT1.| - -#### 3.1.9 Validate interface down reason "UDLD error disabled" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_009** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "UDLD error disabled" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Configure errdisable recovery cause udld in DUT1.
2. Configure errdisable recovery interval as 30 seconds in DUT1.
3. Enable UDLD globally in DUT1 and DUT2.
4. Configure message-time and multiplier as 2 and 3 respectively in DUT1 and DUT2.
5. Enable UDLD on Ethernet1 of both DUT1 and DUT2.
6. Enable UDLD packets blocking on Ethernet1 of DUT1
7. Observe Ethernet1 go down and the interface down reason will be updated as "UDLD error disabled" in the "show interface status err-disabled" output in DUT1.
8. Enable UDLD packets blocking on Ethernet1 of DUT1.
9. Observe after the recovery interval(30 seconds) Ethernet1 will come Up in DUT1.| - -#### 3.1.10 Validate interface down reason "Link flap error disabled" for physical interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_010** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Link flap error disabled" for physical interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Enable link flap error disable on Ethenet4 of DUT1 with flap-threshold 2, sampling-time 10, recovery-timeout 15.
2. Do shutdown and no-shutdown Ethernet4 of DUT2 for 3 times within 10 seconds.
3. Observe the interface down reason for Ethernet4 of DUT1 will be updated as "Link flap error disabled" in the "show interface status err-disabled" output.
4. The Link flap error disabled port will come up after 15 seconds of recovery-time.| - -#### 3.1.11 Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "pvst". - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_011** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "pvst".** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add PortChannel7 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on PortChannel7 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on PortChannel7 of DUT1 with port shutdown on bpdu guard violation.
9. Observe PortChannel7 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on PortChannel7 of DUT2
11. Observe after the recovery interval(30 seconds) PortChannel7 will come Up in DUT1.| - -#### 3.1.12 Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "rapid-pvst". - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_012** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "STP error disabled" for PortChannel interface with STP mode as "rapid-pvst".** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Configure VLAN-10 in DUT1 and DUT2.
2. Add PortChannel7 as tagged member of VLAN-10 in DUT1 and DUT2.
3. Configure Spanning tree mode as "rapid-pvst" in DUT1 and DUT2.
4. Enable spanning on VLAN-10 in DUT1 and DUT2.
5. Enable spanning tree on PortChannel7 of DUT1 and DUT2.
6. Configure errdisable recovery cause bpduguard in DUT1.
7. Configure errdisable recovery interval as 30 seconds in DUT1.
8. Now enable bpdu guard on PortChannel7 of DUT1 with port shutdown on bpdu guard violation.
9. Observe PortChannel7 will go down and the interface down reason will be updated as "STP error disabled" in the "show interface status err-disabled" output in DUT1.
10. Disable spanning tree on PortChannel7 of DUT2
11. Observe after the recovery interval(30 seconds) PortChannel7 will come Up in DUT1.| - - -#### 3.1.13 Validate interface down reason "Min-links-not-met" for PortChannel interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_013** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Min-links-not-met" for PortChannel interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Configure the PortChannels with min-links as 4 in both the DUTs.
2. Remove one of the member ports from PortChannel in DUT1.
3. Observe that interface down reason will be updated as "Min-links-not-met(DM)" in the "show PortChannel summary" output in DUT1.
4. Add the member port back to the PortChannel and observe PortChannel is Up in both the devices.
5. Shutdown one of the member ports of PortChannel in DUT1.
6. Observe that interface down reason will be updated as "Min-links-not-met(DM)" in the "show PortChannel summary" output of DUT1.
7. no shutdown the member port of PortChannel in DUT1 and observe PortChannel is Up in both the devices.
8. Remove one of the member ports from PortChannel in DUT2.
9. Observe that interface down reason will be updated as "Min-links-not-met(DM)" in the "show PortChannel summary" output in DUT1.
10. Add the member port back to the PortChannel and observe PortChannel is Up in both the devices.
| - -#### 3.1.14 Validate interface down reason "Admin-down" for PortChannel interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_014** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "Admin-down" for PortChannel interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Shutdown the PortChannel in DUT1 and observe the down reason for that PortChannel is updated as "Admin down(DA)" in the "show PortChannel summary" output of DUT1.
2. Do no-shutdown the PortChannel in DUT1 and shutdown the PortChannel in DUT2.
3. Observe the interface down reason is shown as "LACP-convergence-failed(DL)" in DUT1 and shown as "Admin-down(DA)" in DUT2.| - -#### 3.1.15 Validate interface down reason "LACP-convergence-failed" for PortChannel interface. - -| **Test ID** | **INTERFACE_DOWN_REASON_FUNC_015** | -| -------------- | :----------------------------------------------------------- | -| **Test Name** | **Validate interface down reason "LACP-convergence-failed" for PortChannel interface.** | -| **Test Setup** | **Topology 1** | -| **Type** | **Functional** | -| **Steps** | 1. Configure PortChannel7 in DUT1 and DUT3, PortChannel7 and PortChannel8 in DUT2.
2. Add Ethernet1, Ethernet2, Ethernet3, Ethernet4, Ethernet5, Ethernet6 as members of PortChannel7 in DUT1.
3. Add Ethernet1, Ethernet2 as members of PortChannel8.
4. Add Ethernet3, Ethernet4 as members of PortChannel7 in DUT2.
5. Add Ethernet5, Ethernet6 as members of PortChannel7 in DUT3.
6. Observe PortChannel7 is Up with Ethernet1 and Ethernet2 as the only active members in DUT1.
7. Observe the interface down reason for PortChannel7 is shown as "LACP-convergence-failed(DL)" in DUT2 and DUT3.
**Note:** Strictly follow the sequence of above steps.| - -
-
- - - - - - -### 3.4 Management - -#### 3.4.1 REST - -## Reference Links - -https://github.com/BRCM-SONIC/sonic_doc_private/blob/195022db0525816d61edeb31ebc1dee1615398e1/system/Interface_Down_Reason.md \ No newline at end of file From 88e04479bc7599969c873d49d2474da20b3afb08 Mon Sep 17 00:00:00 2001 From: Jagadish Chatrasi Date: Mon, 28 Jun 2021 01:02:30 -0400 Subject: [PATCH 5/8] Adding test plan for yang patch feature --- .../SONIC_4_0_0_Yang_Patch_Testplan.md | 346 ++++++++++++++++++ TestPlans/system/Yang_Patch/Yang_Patch.png | Bin 0 -> 8666 bytes 2 files changed, 346 insertions(+) create mode 100644 TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md create mode 100644 TestPlans/system/Yang_Patch/Yang_Patch.png diff --git a/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md new file mode 100644 index 000000000000..4e9e6aa43f62 --- /dev/null +++ b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md @@ -0,0 +1,346 @@ +#  SQA Test Plan +#  SONIC YANG Patch +#  SONiC 4.0.0 Release + +## Test Plan Revision History + +| Rev  | Date       | Author          | Change Description | +| ---- | ---------- | --------------- | ------------------ | +| 0.1  | 6/28/2021  | Jagadish Ch     | Initial Version    | + +## List of Reviewers + +| Function | Name | +| :------: | :--: | +|    QA      |   Chandra Bhushan Singh   | +|    DEV     |   Mohammed Faraaz    | + +## List of Approvers + +| Function | Name | Date Approved | +| :------: | :--: | :-----------: | +|          |      |               | +|          |      |               | + +## Definition/Abbreviation + +| **Term** | **Meaning**                | +| -------- | -------------------------- | +|          |                            | +|          |                            | + +## Feature Overview + +  A "YANG Patch" is an ordered list of edits that are applied to the target configuration datastore by the RESTCONF server. The YANG Patch operation is invoked by the RESTCONF client by sending a PATCH method request with a representation using "application/yang-patch+json". The message-body representing the YANG Patch input parameters MUST be present. + +## 1 Test Focus Areas + +### 1.1 Functional Testing +  - Verify "patch-id" and "edit-id" accept any combination of characters. +  - Verify that yang patch operations "insert" and "move" are not supported. +  - Verify the yang patch operation "create" is successful for a new data resource. +  - Verify the yang patch operation "delete" is successful for an existing data resource. +  - Verify the yang patch operation "merge" is successful and creates the edit value if data resource doesn't exist. +  - Verify the yang patch operation "merge" is successful and merges the edit value if the data resource exists. +  - Verify the yang patch operation "replace" is successful and replaces the existing data resource with edit value. +  - Verify the yang patch operation "remove" is successful and removes the existing data resource. +  - Verify that yang patch call will not proceed if "edit-id"/"operation"/"target" is missing in edit. +  - Verify that yang patch call will not proceed if "patch-id" is missing. +  - Verify that edits are processed in client specified order. +  - Verify if any of the edit operations fails then the whole configuration won't be applied. +  - Verify that there is no relation between "patch-id" and "edit-id" of two consecutive yang patch calls. +  - Verify that yang patch operation will be successful even if the "patch-id" and "edit-id" are the same. +  - Verify the yang patch operation with target sub-resource as "/". +  - Verify yang patch operation calls with different target sub-resources(including "/"). +  - Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list. +  - Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list). +  - Verify yang patch with all supported edit operations(single yang patch call). + +### 1.2 Negative Testing +  - Verify the yang patch operation "create" returns error for an existing data resource. +  - Verify the yang patch operation "delete" returns an error for a non-existing data resource. +  - Verify the yang patch operation "replace" fails if the data resource doesn't exist. +  - Verify the yang patch operation "remove" doesn't report any error for non-existing data resources. +  - Verify that yang patch operation fails, with invalid edit "operation" e.g "operation" : "config". +  - Verify yang patch fails with duplicate "edit-id" for different edits. +  - Verify the error message while trying with invalid "value"(JSON). +  - Verify that target resource will not accept "/". +  - Verify that yang patch call will fail if we try edit operations delete/remove with value resource. + +### 1.3 Scalability Testing +  - Verify that yang patch is successful with max number of characters for "patch-id" and "edit-id". +  - Verify yang patch with max number of edit operations. + +## 2 Topologies + ![Topology](Yang_Patch.png "Figure: Topology 1") + +#### Topology 1 +######Topology Description - +- Make sure management port of DUT(eth0) is connected to network. + +## 3 Test Case and objectives + +### 3.1 Functional Test Cases + +#### 3.1.1 Verify "patch-id" and "edit-id" accept any combination of characters. +| **Test ID**    |**YANG_PATCH_FUNC_001**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify "patch-id" and "edit-id" accept any combination of characters.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with "patch-id" and "edit-id" as any combination of characters.
2. Observe that yang patch call doesn't fail because we don't have any restriction for "patch-id" and "edit-id" names.| + +#### 3.1.2 Verify that yang patch operations "insert" and "move" are not supported. +| **Test ID**    |**YANG_PATCH_FUNC_002**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that yang patch operations "insert" and "move" are not supported.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with "operation" as "insert".
2. Observe that yang patch call fails because the insert operation is not supported.
3. Execute yang patch call with "operation" as "move".
4. Observe the yang patch call fail because the move operation is not supported.| + +#### 3.1.3 Verify the yang patch operation "create" is successful for a new data resource. +| **Test ID**    |**YANG_PATCH_FUNC_003**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "create" is successful for a new data resource.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with "operation" as "create" to configure a new PortChannel which doesn't exist before.
2. Observe that yang patch call is successful.
3. Verify that PortChannel is created.| + +#### 3.1.4 Verify the yang patch operation "delete" is successful for an existing data resource. +| **Test ID**    |**YANG_PATCH_FUNC_004**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "delete" is successful for an existing data resource.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure a classifier.
2. Execute yang patch call with "operation" as "delete" to delete the classifier.
3. Observe that yang patch call is successful.
4. Verify that classifier is deleted.| + +#### 3.1.5 Verify the yang patch operation "merge" is successful and creates the edit value if data resource doesn't exist. +| **Test ID**    |**YANG_PATCH_FUNC_005**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "merge" is successful and creates the edit value if data resource doesn't exist.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure ACL table.
2. Assume there is a rule in the ACL table with "sequence-id" as "1".
4. Now execute a yang patch call with "operation" as "merge" with value resource as for ACL rule of "sequence-id" as "1" with "l4_src_port" and "l4_dst_port" as 20 and 30 respectively.
4. Observe that yang patch call is successful.
5. Verify that ACL rule with sequence-id "1" is created.| + +#### 3.1.6 Verify the yang patch operation "merge" is successful and merges the edit value if the data resource exists. +| **Test ID**    |**YANG_PATCH_FUNC_006**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "merge" is successful and merges the edit value if the data resource exists.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure ACL table with ACL rule of sequence-id, l4_src_port, l4_dst_port as 1, 20 and 30 respectively.
2. Now execute a yang patch call with "operation" as "merge" with value resource as ACL rule of "sequence-id", "l4_src_port" and "l4_dst_port" as 1, 30 and 20 respectively.
4. Observe the yang patch call successful.
5. Verify that ACL rule with sequence-id "1" is modified with "l4_src_port" and "l4_dst_port" as 30 and 20 respectively.| + +#### 3.1.7 Verify the yang patch operation "replace" is successful and replaces the existing data resource with edit value. +| **Test ID**    |**YANG_PATCH_FUNC_007**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "replace" is successful and replaces the existing data resource with edit value.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure ACL table with ACL rule of sequence-id, l4_src_port, l4_dst_port as 1, 20 and 30 respectively.
2. Now execute a yang patch call with "operation" as "replace" with value resource as ACL rule of "sequence-id", "l4_src_port" and "l4_dst_port" as 1, 30 and 20 respectively.
4. Observe the yang patch call successful.
5. Verify that ACL rule with sequence-id "1" is modified with "l4_src_port" and "l4_dst_port" as 30 and 20 respectively.| + +#### 3.1.8 Verify the yang patch operation "remove" is successful and removes the existing data resource. +| **Test ID**    |**YANG_PATCH_FUNC_008**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "remove" is successful and removes the existing data resource.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure ACL table with ACL rule of sequence-id, l4_src_port, l4_dst_port as 1, 20 and 30 respectively.
2. Now execute patch call to remove the acl rule which is having the sequence-id as "1" with "operation" as "remove".
4. Observe that yang patch call is successful.
5. Verify that ACL rule with sequence-id "1" is removed.| + +#### 3.1.9 Verify that yang patch call will not proceed if "edit-id"/"operation"/"target" is missing in edit. +| **Test ID**    |**YANG_PATCH_FUNC_009**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that yang patch call will not proceed if "edit-id"/"operation"/"target" is missing in edit.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute the yang patch call without the "edit-id" field in the edit.
2. Verify the yang patch will fail because the "edit-id" field is missing in the edit.
3. Execute the yang patch call without "operation" filed in the edit.
4. Verify the yang patch will fail because the "operation" field is missing in the edit.
5. Execute the yang patch call without "target" filed in the edit.
6. Verify the yang patch will fail because the "target" field is missing in the edit.
7. Execute the yang patch call without "edit-id", "operation", "target" fields in the edit.
8. Verify the yang patch will fail because the "edit-id", "operation", "target" fields are missing in the edit.| + +#### 3.1.10 Verify that yang patch call will not proceed if "patch-id" is missing. +| **Test ID**    |**YANG_PATCH_FUNC_010**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that yang patch call will not proceed if "patch-id" is missing.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute the yang patch call without the "patch-id" field.
2. Verify the yang patch will fail because the "patch-id" field is missing.| + +#### 3.1.11 Verify that edits are processed in client specified order. +| **Test ID**    |**YANG_PATCH_FUNC_011**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that edits are processed in client specified order.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure two VLANs. i.e. VLAN-10, VLAN-20.
2. Execute a patch call with two edits. In the first edit make a port as tagged member of VLAN-10, in second edit make the same port as tagged member of VLAN-20.
3. Observe that patch call will return an error with message "The port is already part of VLAN-10".| + +#### 3.1.12 Verify if any of the edit operations fails then the whole configuration won't be applied. +| **Test ID**    |**YANG_PATCH_FUNC_012**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify if any of the edit operations fails then the whole configuration won't be applied.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute a patch call with two edits. In first edit configure ip address 10.10.10.1/24 on an interface, in second edit configure ip address in the same subnet i.e.10.10.10.2/24 on another interface.
2. Observe that patch call will fail because both the ip addresses are in the same subnet.
3. Verify there is no ip address configuration done as in the edits.| + +#### 3.1.13 Verify that there is no relation between "patch-id" and "edit-id" of two consecutive yang patch calls. +| **Test ID**    |**YANG_PATCH_FUNC_013**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that there is no relation between "patch-id" and "edit-id" of two consecutive yang patch calls.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute a yang patch call to configure a mirror-session with "patch-id" and "edit-id" as "config_mirror_session" and "edit1".
2. Verify the yang patch call is successful and the mirror-session is configured successfully.
3. Now try to delete the mirror-session using a yang patch call with "patch-id" and "edit-id" as "delete_mirror_session" and "edit2".
4. Verify the yang patch call is successful and the mirror-session is deleted successfully.
| + +#### 3.1.14 Verify that yang patch operation will be successful even if the "patch-id" and "edit-id" are the same. +| **Test ID**    |**YANG_PATCH_FUNC_014**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that yang patch operation will be successful even if the "patch-id" and "edit-id" are the same.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure a policy-map using yang patch call with "patch-id" and "edit-id" as the same.
2. Verify the yang patch call is successful and the policy-map is configured.| + +#### 3.1.15 Verify the yang patch operation with target sub-resource as "/". +| **Test ID**    |**YANG_PATCH_FUNC_015**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation with target sub-resource as "/".** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Enable UDLD globally using yang patch call with target sub-resource as "/".
2. Verify the yang patch call is successful and UDLD is enabled globally as configured.| + +#### 3.1.16 Verify yang patch operation calls with different target sub-resources(including "/"). +| **Test ID**    |**YANG_PATCH_FUNC_016**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify yang patch operation calls with different target sub-resources(including "/").** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure mtu and description for an interface within the same yang patch call with two edits. In one of the edits use sub-resources as "/".
2. Verify the yang patch call is successful and mtu, description values are reflected as configured.| + +#### 3.1.17 Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list. +| **Test ID**    |**YANG_PATCH_FUNC_017**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch with sub-resource not as list but actually target sub-resource points to list.
2. Verify that yang patch will fail due to invalid sub-resource value.| + +#### 3.1.18 Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list). +| **Test ID**    |**YANG_PATCH_FUNC_018**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list).** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list).
2. Verify that yang patch call is successful.| + +#### 3.1.19 Verify yang patch with all supported edit operations(single yang patch call). +| **Test ID**    |**YANG_PATCH_FUNC_019**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify yang patch with all supported edit operations(single yang patch call).** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with all supported edit operations.
2. Verify that yang patch call is successfully executed.| + + +### 3.2 Negative Test Cases + +#### 3.2.1 Verify the yang patch operation "create" returns error for an existing data resource. +| **Test ID**    |**YANG_PATCH_NEG_001**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "create" returns error for an existing data resource.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure a VRF, let's say Vrf-101.
2. Try to configure the same VRF using yang-patch with edit operation as "create".
3. Observe yang-patch call fails because the entry already exists.
4. Verify that error message **"Data already exists; cannot be created"** in the RESTCONF server the response.| + +#### 3.2.2 Verify the yang patch operation "delete" returns an error for a non-existing data resource. +| **Test ID**    |**YANG_PATCH_NEG_002**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "delete" returns an error for a non-existing data resource.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Try to delete a PortChannel which is not created in DUT using yang-patch with edit operation as "delete".
3. Observe yang-patch call fails because the entry does not exist.
4. Verify that error message **"Data doesn't exist; cannot be deleted"** in the RESTCONF server the response.| + +#### 3.2.3 Verify the yang patch operation "replace" fails if the data resource doesn't exist. +| **Test ID**    |**YANG_PATCH_NEG_003**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "replace" fails if the data resource doesn't exist.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure ACL table.
2. Assume there is a rule in the ACL table with "sequence-id" as "1".
4. Now execute a patch call with "operation" as "replace" with value resource as for ACL rule of "sequence-id" as "1" with "l4_src_port" and "l4_dst_port" as 20 and 30 respectively.
4. Observe that yang patch call fails.
5. Verify that error message **"Data doesn't exist; cannot be replaced"** in the RESTCONF server the response.| + +#### 3.2.4 Verify the yang patch operation "remove" doesn't report any error for non-existing data resources. +| **Test ID**    |**YANG_PATCH_NEG_004**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the yang patch operation "remove" doesn't report any error for non-existing data resources.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Try to delete a PortChannel which is not created in DUT using yang-patch with edit operation as "remove".
3. Observe that yang-patch call doesn't fail even if the entry does not exist.
4. Verify that there is no error message found in the RESTCONF server response.| + +#### 3.2.5 Verify that yang patch operation fails, with invalid edit "operation" e.g "operation" : "config". +| **Test ID**    |**YANG_PATCH_NEG_005**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that yang patch operation fails, with invalid edit "operation" e.g "operation" : "config".** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with invalid edit "operation", let's say "config".
2. Observe yang-patch call fails because the operation is invalid.| + +#### 3.2.6 Verify yang patch fails with duplicate "edit-id" for different edits. +| **Test ID**    |**YANG_PATCH_NEG_006**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify yang patch fails with duplicate "edit-id" for different edits.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with at least two edits in the edit list with the same "edit-id" for all edits.
2. Observe yang-patch call fails because the same "edit-id" is used across the edits.| + +#### 3.2.7 Verify the error message while trying with invalid "value"(JSON). +| **Test ID**    |**YANG_PATCH_NEG_007**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify the error message while trying with invalid "value"(JSON).** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute yang patch call with invalid value resource.
2. Observe yang-patch call fails because the value resource is invalid.| + +#### 3.2.8 Verify that target resource will not accept "/". +| **Test ID**    |**YANG_PATCH_NEG_008**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that target resource will not accept "/".** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute a yang patch call with target resource as "/" and mention the respective URI in the sub target resource of an edit.
2. Verify the yang patch call fails because sonic won't support root as target resource.| + +#### 3.2.9 Verify that yang patch call will fail if we try edit operations delete/remove with value resource. +| **Test ID**    |**YANG_PATCH_NEG_009**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that yang patch call will fail if we try edit operations delete/remove with value resource.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure a VLAN i.e. VLAN-10.
2. Try to delete that VLAN using yang patch call with value resource using edit operation "delete".
3. Verify that yang patch call will fail as value resource is not allowed for the edit operation "edit".
4. Repeat the above steps with the edit operation as "remove".| + +### 3.3 Scaling Test Cases + +#### 3.3.1 Verify that yang patch is successful with max number of characters for "patch-id" and "edit-id".   + +| **Test ID**    |**YANG_PATCH_SCAL_001**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that yang patch is successful with max number of characters for "patch-id" and "edit-id".** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure a PortChannel using yang-patch with "patch-id", "edit-id" of maximum characters and edit operation as "create".
2. Verify yang-patch operation is successful and PortChannel is created without any issues.| + +#### 3.3.2 Verify yang patch with max number of edit operations.   + +| **Test ID**    |**YANG_PATCH_SCAL_002**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify yang patch with max number of edit operations.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Configure maximum number of VLANs using yang patch operation "create". For each VLAN configuration use a different edit within the same yang patch call.
2. Verify yang-patch operation is successful and VLANs are created without any issues.
**Note:** The maximum number of edits allowed within a patch call is not specified in HLD.| + +
+
+ + + + + + +### 3.4 Management + +#### 3.4.1 REST + +## Reference Links + +https://github.com/BRC/M-SONIC/sonic_doc_private/blob/fe5895f60dcae312db6ed9d7909c846d418f2d6c/manageability/mgmt-framework/Yang_Patch_HLD.md \ No newline at end of file diff --git a/TestPlans/system/Yang_Patch/Yang_Patch.png b/TestPlans/system/Yang_Patch/Yang_Patch.png new file mode 100644 index 0000000000000000000000000000000000000000..16b9bc810c615fb144c6b7e50b56413c3d7b950d GIT binary patch literal 8666 zcmeHMdsLF?y2oiIXQtFZm>FkfrR6lHBqnaB)I6n5OJGc4OBq1n#q|l z?aY{Y(v-GVUIPmi6A?Y8WC~PH#eEieE?j4lyodK6#}t-27WDyoUEY`$QRgvqduoIqEuow{!`-)&Ny5i zcJ;?TryQqa@%8bldz1X*G-SP}r8u)zp)? zAkF!_d;>`TvW0H}($9ZdAHJ@-b+-Zc!upnhK-R+r1oFoSm6o>0RjH6MTg0J5mnasq zPD{Zs2&6r?=y&2d^!j@p*c6e~k(K7n4KQ;42aqxU(9HE5@y9Uwzgcoms`AYzTH=zD zzGKZ*h(R1?+63U7q2lhAjS2B+Z-UzvF#u!6Zhlq1p(E{OkJ=|t6evx|yb*;tgP||V zi$cq+JVPD{q-!A5~~pbeC93y^$|KSj7G@!@5JN zx^i;wKxc|*F4Q;>YR@o^MmQtUYLRGX75q;^d~vtjFho71VSCne3Fuu2f@iH-u^gIp z3ItSRH@__3FsqO4c|3FZ){FRz2oB2npeHm0^K$##vQSs6RSar*ir$fNI^h)(#EfQV zz@*tVy4^*7*#~KPg55=VCBcR|!C2|Zz5Z2ws?z1X0$Oh@TZ;&Ffw3#XD+5yR_9Z*( zWFnbDTV$)7=`jwrlZ@?WY(V8ifs<7^Rh}*>nk-FrDx1K&XJ*xCriaC^auFV}FP6^P zvqm<%u7+uKuE6_aE)Ia+B%}84(4$RX*#mbnego8NP7&|m3LV0!-ic7|{IN2*D&GgA z(QNrYv6rl|8}9dhTIX z6AGBsbH;JP(Gz+ct8o^@q~_ggB3BYT!)TT?`h=pz#Sg#_rlt0%h2@;r#VT{(504|@lQB_G0%?Qn> zbrt1Jd^}G1v~^`i;3SUl#=IF+&jIWGC7m=#hl{ZOhhTE}#vvPa&wG&B%KG2I#-m?< zHs;u(+7;cfiM?;bOfC>Z|7X;Y>o~~J7~k>#qH1DH`QC=Q>9MnJiajuv&u;jJBCM81VkuTi?$Uu}Q*{u{~>Ku!h5+sXw%t{8XksMYgSMHf|gASI?r9ofXPQcwFT)wAKqZPmi z;umYe($C?ntrhn&(-1h)pmqFou%fG1hM4avv~e3*)J~{~2vG{Mwb>gOaTC=4;XPsn z-so1+uQV;}_G_>k>|Ji#wIV~RZWkpo43&U`1mB1UR5Mfvlu?Tw9a#FG^n*^0Oous) zX1kjj7vf;wTA5iEUSzm<(CK=i^tQ!f7ws`9fD`{5fBQhP6@jHgv(R1y0W^a50NlNh za^#%dV)fI`aCrt0aPW&WFY04399@j5_?>q8-pY|HU_fH`YYywF<{$VU0wX%EJxd)b zo<2*w#!v*ul9L}B>N;(;y7(|~x-tG2#d<$|-$VHfnT#7rSeq zC*ab!Wv|2tS)j+DHn`x%1gPmjWib~D(~AvtnkS?Bg=%riWyGN< z@-Gi2u>p4}5$1g#ffjBCte?9qjMYxAJfsZ1dh$^d7G4=?t(TO+9s_ z%+8ItUr!WVA08G$F9fN@Sm?z%-t{v4495poz#rkSJZN{bz|SQt*MCCMEVLzFZV;*n z1tMzactFHq_gaw$6Is)H%%yg}#I&p!t1yz4qLR~Ts zx4M%t=7c`BArN1DxMV*vntvm@DDN=v1bfX|h7Av`F+ z2B9U2LWQjYRdB3ClB}ItsF>s;>nLG;@C8RLLK?luaj-AHDSa@3z2FBlY}tDwE7GA}?GZy1wpl{|(JM zf=#2Ok6_}wCz$r`aJxwRBvu88F>;hZ8ot5;)3C|v`a4E+&dO|@GX&!O;>CIkYrTE9 z-iHCh$Upip<74M*vaA6#W@%}ua)ppTSe@Pg>CiXKgShj5U;EeUHL2^nwdWs(0Kf?N z{Qqh9#s^vg1z`he^FtMgU9$^;{h>k0bn$H1HK@FwbM~oi zes@~LwJ2ibGZFx>Y`5|)amw1_qOs;h>Px;o=7*v2zfX71eIk+}BEnjc{90{Wq#t>4`bC7^H_O~Y z4%X}Xyr}b*0FXZbusW+Lv8qeO;TE#$x@{?O;tZqP9h!fAKit)~pfNBS=JZ(VM(cJ6bf^-hw2`VJdUs0ptW$ivi(KU>npngbls&>YJ%g3?u(-iLx> zbeBb=aE%f`N3Vf{iPOc1TP;WS$?aC!aZf;m@=pQHETzk=j%YSX za$S_V+G7+!GKO`EH9&o?W*b5oOQe(h#T~b@-(}derE`?2jgREqUvLiLfcsP(2TGrz z-nPMsex|Bc?Z+?_W;SgNCtr2ZsT7Bbx*4+DusH_~af;;`MX5xIwkcuW*^+k7bHMk; zYCZug)PnhtZXy$<@(TGb@X$_b4A1*gNtGO&cpco?W0{zN1J^#=ht|ES@#wR?@lP_`x z%w49V`+Fc*)yvh{`@TV?du^1FvM?{>S}Ozc4aLNCV_^yUPVqd8!;Gy0#RzHEzJmHS z1Fjl8(CMp9kF|ib2-A`p!V<(sr?r8%qE5ukPPXu3`c##<4h!aev7_NMp4m&zUSJ6^ z^ws$vOQh+QA%IDw&j1*ZqxqVNxP6~)-4(4{7z`3(4p3L!FQ8K{0%dZ?RZ<^O?HOST9>y54-mHk0_ z-~ZH_0JGaalI6c Date: Mon, 28 Jun 2021 01:21:50 -0400 Subject: [PATCH 6/8] Fixed alignment issues --- .../SONIC_4_0_0_Yang_Patch_Testplan.md | 61 ++++++++++--------- 1 file changed, 31 insertions(+), 30 deletions(-) diff --git a/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md index 4e9e6aa43f62..83f5e1ca9f30 100644 --- a/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md +++ b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md @@ -7,6 +7,7 @@ | Rev  | Date       | Author          | Change Description | | ---- | ---------- | --------------- | ------------------ | | 0.1  | 6/28/2021  | Jagadish Ch     | Initial Version    | +| 0.2  | 6/28/2021  | Jagadish Ch     | Fixed alignment issues    | ## List of Reviewers @@ -36,40 +37,40 @@ ## 1 Test Focus Areas ### 1.1 Functional Testing -  - Verify "patch-id" and "edit-id" accept any combination of characters. -  - Verify that yang patch operations "insert" and "move" are not supported. -  - Verify the yang patch operation "create" is successful for a new data resource. -  - Verify the yang patch operation "delete" is successful for an existing data resource. -  - Verify the yang patch operation "merge" is successful and creates the edit value if data resource doesn't exist. -  - Verify the yang patch operation "merge" is successful and merges the edit value if the data resource exists. -  - Verify the yang patch operation "replace" is successful and replaces the existing data resource with edit value. -  - Verify the yang patch operation "remove" is successful and removes the existing data resource. -  - Verify that yang patch call will not proceed if "edit-id"/"operation"/"target" is missing in edit. -  - Verify that yang patch call will not proceed if "patch-id" is missing. -  - Verify that edits are processed in client specified order. -  - Verify if any of the edit operations fails then the whole configuration won't be applied. -  - Verify that there is no relation between "patch-id" and "edit-id" of two consecutive yang patch calls. -  - Verify that yang patch operation will be successful even if the "patch-id" and "edit-id" are the same. -  - Verify the yang patch operation with target sub-resource as "/". -  - Verify yang patch operation calls with different target sub-resources(including "/"). -  - Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list. -  - Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list). -  - Verify yang patch with all supported edit operations(single yang patch call). + - Verify "patch-id" and "edit-id" accept any combination of characters. + - Verify that yang patch operations "insert" and "move" are not supported. + - Verify the yang patch operation "create" is successful for a new data resource. + - Verify the yang patch operation "delete" is successful for an existing data resource. + - Verify the yang patch operation "merge" is successful and creates the edit value if data resource doesn't exist. + - Verify the yang patch operation "merge" is successful and merges the edit value if the data resource exists. + - Verify the yang patch operation "replace" is successful and replaces the existing data resource with edit value. + - Verify the yang patch operation "remove" is successful and removes the existing data resource. + - Verify that yang patch call will not proceed if "edit-id"/"operation"/"target" is missing in edit. + - Verify that yang patch call will not proceed if "patch-id" is missing. + - Verify that edits are processed in client specified order. + - Verify if any of the edit operations fails then the whole configuration won't be applied. + - Verify that there is no relation between "patch-id" and "edit-id" of two consecutive yang patch calls. + - Verify that yang patch operation will be successful even if the "patch-id" and "edit-id" are the same. + - Verify the yang patch operation with target sub-resource as "/". + - Verify yang patch operation calls with different target sub-resources(including "/"). + - Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list. + - Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list). + - Verify yang patch with all supported edit operations(single yang patch call). ### 1.2 Negative Testing -  - Verify the yang patch operation "create" returns error for an existing data resource. -  - Verify the yang patch operation "delete" returns an error for a non-existing data resource. -  - Verify the yang patch operation "replace" fails if the data resource doesn't exist. -  - Verify the yang patch operation "remove" doesn't report any error for non-existing data resources. -  - Verify that yang patch operation fails, with invalid edit "operation" e.g "operation" : "config". -  - Verify yang patch fails with duplicate "edit-id" for different edits. -  - Verify the error message while trying with invalid "value"(JSON). -  - Verify that target resource will not accept "/". -  - Verify that yang patch call will fail if we try edit operations delete/remove with value resource. + - Verify the yang patch operation "create" returns error for an existing data resource. + - Verify the yang patch operation "delete" returns an error for a non-existing data resource. + - Verify the yang patch operation "replace" fails if the data resource doesn't exist. + - Verify the yang patch operation "remove" doesn't report any error for non-existing data resources. + - Verify that yang patch operation fails, with invalid edit "operation" e.g "operation" : "config". + - Verify yang patch fails with duplicate "edit-id" for different edits. + - Verify the error message while trying with invalid "value"(JSON). + - Verify that target resource will not accept "/". + - Verify that yang patch call will fail if we try edit operations delete/remove with value resource. ### 1.3 Scalability Testing -  - Verify that yang patch is successful with max number of characters for "patch-id" and "edit-id". -  - Verify yang patch with max number of edit operations. + - Verify that yang patch is successful with max number of characters for "patch-id" and "edit-id". + - Verify yang patch with max number of edit operations. ## 2 Topologies ![Topology](Yang_Patch.png "Figure: Topology 1") From 22bc20f57d612367815918ee201114e74338eaf4 Mon Sep 17 00:00:00 2001 From: Jagadish Chatrasi Date: Mon, 28 Jun 2021 01:27:42 -0400 Subject: [PATCH 7/8] Fixed typo --- TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md index 83f5e1ca9f30..6cf6464ec6a7 100644 --- a/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md +++ b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md @@ -76,7 +76,7 @@ ![Topology](Yang_Patch.png "Figure: Topology 1") #### Topology 1 -######Topology Description - +Topology Description - - Make sure management port of DUT(eth0) is connected to network. ## 3 Test Case and objectives From fca7f9b7b7e5da9f6089b595db3436212d5b9e2b Mon Sep 17 00:00:00 2001 From: Jagadish Chatrasi Date: Wed, 14 Jul 2021 02:32:32 -0400 Subject: [PATCH 8/8] Addressing review comments --- .../SONIC_4_0_0_Yang_Patch_Testplan.md | 34 ++++++++++++++----- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md index 6cf6464ec6a7..1c9a51399d29 100644 --- a/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md +++ b/TestPlans/system/Yang_Patch/SONIC_4_0_0_Yang_Patch_Testplan.md @@ -8,6 +8,7 @@ | ---- | ---------- | --------------- | ------------------ | | 0.1  | 6/28/2021  | Jagadish Ch     | Initial Version    | | 0.2  | 6/28/2021  | Jagadish Ch     | Fixed alignment issues    | +| 0.3  | 7/14/2021  | Jagadish Ch     | Addressing review comments provided by Faraaz    | ## List of Reviewers @@ -53,9 +54,11 @@ - Verify that yang patch operation will be successful even if the "patch-id" and "edit-id" are the same. - Verify the yang patch operation with target sub-resource as "/". - Verify yang patch operation calls with different target sub-resources(including "/"). - - Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list. - - Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list). + - Verify the yang patch fails if we the sub-resource not points to list instance(keys). + - Verify yang patch call with target sub-resources as containers with different types of data nodes, make sure we have at least one URI (target sub-resource) per operation for each YANG data node (container, list, leaf, and leaf-list). - Verify yang patch with all supported edit operations(single yang patch call). + - Verify "patch-id" in the audit-log for a successful and unsuccessful yang patch call. + - Verify that RESTCONF server MUST return the "Accept-Patch" header field in an OPTIONS response, as specified in RFC5789, which includes the media type for YANG Patch. ### 1.2 Negative Testing - Verify the yang patch operation "create" returns error for an existing data resource. @@ -211,18 +214,18 @@ Topology Description - | **Type**       | **Functional**                                               | | **Steps**      | 1. Configure mtu and description for an interface within the same yang patch call with two edits. In one of the edits use sub-resources as "/".
2. Verify the yang patch call is successful and mtu, description values are reflected as configured.| -#### 3.1.17 Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list. +#### 3.1.17 Verify the yang patch fails if we the sub-resource not points to list instance(keys). | **Test ID**    |**YANG_PATCH_FUNC_017**                                               | | -------------- | :----------------------------------------------------------- | -| **Test Name**  | **Verify the yang patch fails if we use sub-resource not as list while that target sub-resource points to list.** | +| **Test Name**  | **Verify the yang patch fails if we the sub-resource not points to list instance(keys).** | | **Test Setup** | **Topology 1**                                               | | **Type**       | **Functional**                                               | | **Steps**      | 1. Execute yang patch with sub-resource not as list but actually target sub-resource points to list.
2. Verify that yang patch will fail due to invalid sub-resource value.| -#### 3.1.18 Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list). +#### 3.1.18 Verify yang patch call with target sub-resources as containers with different types of data nodes, make sure we have at least one URI (target sub-resource) per operation for each YANG data node (container, list, leaf, and leaf-list). | **Test ID**    |**YANG_PATCH_FUNC_018**                                               | | -------------- | :----------------------------------------------------------- | -| **Test Name**  | **Verify yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list).** | +| **Test Name**  | **Verify yang patch call with target sub-resources as containers with different types of data nodes, make sure we have at least one URI (target sub-resource) per operation for each YANG data node (container, list, leaf, and leaf-list).** | | **Test Setup** | **Topology 1**                                               | | **Type**       | **Functional**                                               | | **Steps**      | 1. Execute yang patch call with target sub-resources as containers with different types(list, non-list), container-leaf with different types(list, non-list).
2. Verify that yang patch call is successful.| @@ -235,6 +238,21 @@ Topology Description - | **Type**       | **Functional**                                               | | **Steps**      | 1. Execute yang patch call with all supported edit operations.
2. Verify that yang patch call is successfully executed.| +#### 3.1.20 Verify "patch-id" in the audit-log for a successful and unsuccessful yang patch call. +| **Test ID**    |**YANG_PATCH_FUNC_020**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify "patch-id" in the audit-log for a successful and unsuccessful yang patch call.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute a successful yang patch call and observe that "patch-id" is shown properly for debugging purpose.
2. Execute a unsuccessful yang patch call and observe that "patch-id" is shown properly for debugging purpose.| + +#### 3.1.21 Verify that RESTCONF server MUST return the "Accept-Patch" header field in an OPTIONS response, as specified in RFC5789, which includes the media type for YANG Patch. +| **Test ID**    |**YANG_PATCH_FUNC_021**                                               | +| -------------- | :----------------------------------------------------------- | +| **Test Name**  | **Verify that RESTCONF server MUST return the "Accept-Patch" header field in an OPTIONS response, as specified in RFC5789, which includes the media type for YANG Patch.** | +| **Test Setup** | **Topology 1**                                               | +| **Type**       | **Functional**                                               | +| **Steps**      | 1. Execute a CURL OPTIONS call with any configuration URI.
2. Observe the Accept-Patch will be shown as "application/yang-data+json, application/yang-patch+json" in response.| ### 3.2 Negative Test Cases @@ -328,7 +346,7 @@ Topology Description - | **Test Name**  | **Verify yang patch with max number of edit operations.** | | **Test Setup** | **Topology 1**                                               | | **Type**       | **Functional**                                               | -| **Steps**      | 1. Configure maximum number of VLANs using yang patch operation "create". For each VLAN configuration use a different edit within the same yang patch call.
2. Verify yang-patch operation is successful and VLANs are created without any issues.
**Note:** The maximum number of edits allowed within a patch call is not specified in HLD.| +| **Steps**      | 1. Configure maximum number of VLANs using yang patch operation "create". For each VLAN configuration use a different edit within the same yang patch call.
2. Verify yang-patch operation is successful and VLANs are created without any issues.
**Note:** The maximum number of edits allowed within a patch call is not specified in HLD and we don't have resource limiting in REST CONF server. So avoiding it for now.|

@@ -344,4 +362,4 @@ Topology Description - ## Reference Links -https://github.com/BRC/M-SONIC/sonic_doc_private/blob/fe5895f60dcae312db6ed9d7909c846d418f2d6c/manageability/mgmt-framework/Yang_Patch_HLD.md \ No newline at end of file +https://github.com/BRCM-SONIC/sonic_doc_private/blob/fe5895f60dcae312db6ed9d7909c846d418f2d6c/manageability/mgmt-framework/Yang_Patch_HLD.md \ No newline at end of file