The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] ambiguity in the LDP RFC (RFC3036) ?
Could it be the case that the loopback on A wasn't announced so it is not reachable from B? Steve -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Tuesday, October 10, 2006 8:22 AM To: mpls@lists.ietf.org Subject: [mpls] ambiguity in the LDP RFC (RFC3036) ? I am interop-testing equipment from three vendors and I have discovered a problem I would like your opinion on. I have equipment from three vendors. I'm trying to test if they can properly talk all "needed" protocols together, ie ISIS, LDP, BGP etc. I'll call the vendors A, B and C. First I started by enabling ISIS, LDP and BGP between vendor A and C. This worked without any noticable problems. Routers from vendor B and C was already doing this so that also worked well. My problem arose when I tried to get ISIS+LDP up between vendor A and B. ISIS worked properly but LDP wouldn't come up. Router from vendor B would say "Illegal Hello packet" and drop the packet, and upon sniffing I noticed that A router was sending LDP hellos to 224.0.0.2 with its loopback address as SRC-IP, instead of its nearest interface IP. Upon reading RFC3036 I cannot say that either vendor is doing something wrong, as the source IP of the hello packet isn't specified or mentioned in the text. My "feeling" is that the intention is that a packet going to "all local routers" mcast group should have a local IP address as sending IP, but I can't find anywhere in the RFC that justifies dropping the hello packet on the floor if it has another SRC-IP. It validates the "be strict in what you send, be liberal in what you receive" principle, but there might be security considerations behind the decision to do so. Vendor A has an interface command that specifies that all LDP communication on the interface should be with the interface IP address and this makes it work (hello packet is sourced from interface IP), but also makes the LDP TCP session be originated from the interface IP, which I think is undesireable. My feeling is that both vendors are doing something they shouldn't be doing here, vendor A should send packets with interface IP as SRC, and vendor B shouldn't drop the packets. Opinions? -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|