isisd: When the ISIS types of the routers do not match on a P2P link

Test Scenario:
RouterA and RouterB are in the same routing domain and have configured a P2P link. RouterA is configured with "is-type level-1" while RouterB is configured with "is-type level-1-2". They establish a level-1 UP neighborship. In this scenario, we expect that when RouterB's configuration is switched to "is-type level-2-only", the neighborship status on both RouterA and RouterB would be non-UP. However, RouterB still shows the neighbor as UP.

Upon receiving a P2P Hello packet, the function "process_p2p_hello" is invoked. According to the ISO/IEC 10589 protocol specification, section 8.2.5.2 a) and tables 5 and 7, if the "iih->circ_type" of the neighbor's hello packet does not match one's own "circuit->is_type," we may choose to take no action.
When establishing a neighborship for the first time, the neighbor's status can remain in the "Initializing" state. However, if the neighborship has already been established and one's own "circuit->is_type" changes, the neighbor's UP status cannot be reset. Therefore, when processing P2P Hello packets, we should be cognizant of changes in our own link adjacency type.

Signed-off-by: zhou-run <[email protected]>

Author: zhou-run

isisd/isis_pdu.c

@@ -231,7 +231,8 @@ static int process_p2p_hello(struct iih_info *iih)
 			return ISIS_OK;
 		}
 	}
-	if (!adj || adj->level != iih->calculated_type) {
+	if (!adj || adj->level != iih->calculated_type ||
+	    !(iih->circuit->is_type & iih->circ_type)) {
 		if (!adj) {
 			adj = isis_new_adj(iih->sys_id, NULL,
 					   iih->calculated_type, iih->circuit);