Subject: [mpls] ambiguity in the LDP RFC (RFC3036) ?

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Oct 2006 15:21:45 +0200 (CEST)

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: [email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Steve Yao <[email-masked]>
Date: Tue, 10 Oct 2006 11:46:06 -0500

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:[email-masked]] 
Sent: Tuesday, October 10, 2006 8:22 AM
To: [email-masked]
Subject: [mpls] ambiguity in the LDP RFC (RFC3036) ?

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.

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?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Oct 2006 18:54:42 +0200 (CEST)

> Could it be the case that the loopback on A wasn't announced so it is not

The loopbacks were reachable via ISIS.

Setting up a targetted TDP session works (loopback-loopback), and setting 
vendor A:s implementation to do all TDP for that interface via the 
interface IP address also works, so there are two workarounds for the 
problems.