The MPLS WG Archive

[Mikael Abrahamsson <swmike@swm.pp.se>]

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