ldpd: Option for disabled LDP hello message during TCP

[AndriiFullroot]

Currently the LDPD services on TCP session establishment sends additional UDP multicast hello message. Overall, it should speed up label acknowledge.
On the big LAN with a lot of LDPD services(100+) that may reconnect it would lead to a HUGE traffic in the network, when we would lost any performance. So, this PR propose an option to disable "additional hello" during the TCP establishment.

Added option "disable-establish-hello" that disables sending additional LDP hello multicast messages during TCP session establishment. This option enables per interface: "(config-ldp-af-if)"

Usage example:

VyOS# configure
VyOS(config)# mpls ldp
VyOS(config-ldp)# address-family ipv4
VyOS(config-ldp-af)# interface eth0
VyOS(config-ldp-af-if)# disable-establish-hello
VyOS(config-ldp-af-if)# end
VyOS# show run
Building configuration...

Current configuration:
!
frr version 10.4-dev
frr defaults traditional
hostname VyOS
no ipv6 forwarding
!
mpls ldp
 !
 address-family ipv4
  ! Incomplete config, specify a discovery transport-address
  !
  interface eth0
   disable-establish-hello
  exit
  !
 exit-address-family
 !
exit
!
end

[sever-sever]

some background https://vyos.dev/T7226

[donaldsharp]

please add a topotest that exercises this new functionality. Additionally this command needs to be documented in the ldpd documentation

[riw777]

I'm a bit confused, I think ... from the external link:

LDP Hello packets are generated to answer incoming Hello before forming neighbor adjacency. According to RFC 5036, Hello packets should be generated periodically at a certain interval. By default, it is 5 sec. But in FRR we see strange behavior. If a router has not formed an LDP neighbor adjacency yet, it answers to all received LDP Hello packets from not neighbors with new Hello packets. That behavior is incorrect.

But then this pr seems to make it an optional change? Is this a problem with the way we implement the spec or is this just an optimization ... ??

[AndriiFullroot]

I'm a bit confused, I think ... from the external link:

LDP Hello packets are generated to answer incoming Hello before forming neighbor adjacency. According to RFC 5036, Hello packets should be generated periodically at a certain interval. By default, it is 5 sec. But in FRR we see strange behavior. If a router has not formed an LDP neighbor adjacency yet, it answers to all received LDP Hello packets from not neighbors with new Hello packets. That behavior is incorrect.

But then this pr seems to make it an optional change? Is this a problem with the way we implement the spec or is this just an optimization ... ??

Well, sending an additional LDP hello is a valid optimization to speed up the TCP session establishment. The problem appears when there are a lot of ldpd services in a local network. So, this patch adds an option to NOT send the "additional" LDP hello so admins may configure their network if they see the network may be overflowing with multicast traffic, which brings more harm then good.

[AndriiFullroot]

please add a topotest that exercises this new functionality. Additionally this command needs to be documented in the ldpd documentation

Added please review and provide comments.

[riw777]

looks good

[AndriiFullroot]

I've checked on my local docker ubuntu22 image:

docker exec frr-ubuntu22 bash -c 'cd ~/frr/tests/topotests ; sudo pytest -v -s ldp_establish_hello_topo1/test_establish_hello_topo1.py'
....
stdout: /bin/bash: line 1: iptables: command not found
....

Not sure what the correct solution is.
Add iptables to the Dockerfile? Is it suitable?
Any suggestions?