With the same configuration, ISIS neighbor could set up when NE80E uses GE to connect with GW P320, but it fails to set up when POS is used.
Execute dis isis interface command at the interconnecting interfaces, it displays mtu/up;lnk/dn;IP/up; the link is down, but the ports at both sides are normal; there is no ISIS session, so the configurations are normal. The ISIS negotiation of POS ports at both sides is problematic.
According to the interpretation from G company, its POS port of PXXX does not support ISIS when the link protocol is PPP, and it is because the product does not use the standard code value. Change it hdlc.
Through debugging, it is found that NE80E has transmitted code ConfReq, and P320 at peer will update its state to initialization theoretically when it receives ConfReq packets. Then, NE80E transmits ConfReq and ConfAck packets for negotiation with NE80E again, but the packet sent by P320 is code ProtoRe; that is to say, P320 could recognize OSICP(8023) packets, but it refuses them, failing the negotiation, and making both NE80E and OSICP in the state of Stopped. It is known that NE80E uses code, so it is P320 at peer that does not realize OSICP according to standard, resulting in the problem like above.