Loadbalancers in front of Routers should be configured to monitor on the port 15999 (tcp) or the /self/up API (http)?
https://docs.apigee.com/private-cloud/latest/enablingdisabling-server-message-processorrouter-reacha... As per the docs above, we can block the port 15999 to make the routers unreachable and at the bottom it says check the /self/up to get the reachable status.
As per my tests below , it doesn't work that way. any ideas?
If we are supposed to only use 15999 to monitor and to control the reachability, what is the purpose of the /self/up API on routers?
[root@test-n1 ~]# sudo iptables -A INPUT -i eth0 -p tcp --dport 15999 -j REJECT [root@test-n1 ~]# sudo iptables -A INPUT -i lo -p tcp --dport 15999 -j REJECT [root@test-n1 ~]# curl http://localhost:8081/v1/servers/self/up true[root@test-n1 netstat -anp | grep 15999 tcp 0 0 0.0.0.0:15999 0.0.0.0:* LISTEN 11705/nginx: master [root@test-n1 ~]# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001 inet 172.31.32.124 netmask 255.255.240.0 broadcast 172.31.47.255 inet6 fe80::10cb:5bff:fe32:393c prefixlen 64 scopeid 0x20<link> ether 12:cb:5b:32:39:3c txqueuelen 1000 (Ethernet) RX packets 313285315 bytes 23876771990 (22.2 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 311974076 bytes 30668161646 (28.5 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 45328124 bytes 8488933098 (7.9 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 45328124 bytes 8488933098 (7.9 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
@Maruti Chand /self/up runs on 8081 not 15999 you are saying correct ? IF you look is the external host versus Mgmt ports checking e2e flow.
True, my point is this
We say use sudo iptables -A INPUT -i eth0 -p tcp --dport 15999 -j REJECT to disable the reachability and
To get the reachable status of a Router, make a request to port 8081 on the Router:
> curl -v http://<routerIP>:8081/v1/servers/self/up
I don't think they both are related
Correct as one is for the host and the other is mgmt api call which run on two different ports. I believe that two different steps must be done to achieve what you are looking for.
In short there are two items to address (why is shown below):
Application reachability should be checked with /v1/servers/self/reachable and NOT /v1/servers/self/up when checking ports 8081 and 8082
Host reachability from a loadbalancer perspective doesn't have to call a URL, it could just check port TCP/15999 is accessible.
Better...
If loadbalancers monitored /v1/servers/self/reachable on port 8081 from the firewall then a return of:
and would also more accurately reflect system state and does not require firewall changes on the local machines.
----------------------------------------------------------------------------------------------------------
The documentation needs an update.
It specifies to check router reachability you call
curl http://<router_ip>:8081/v1/servers/self/up
which will return true if the router is reachable.
This is not correct. It will return true if the Router is UP.
In the example below a Router has been marked as unreachable via a call to the management API.
[andy@devportal] # curl http://192.168.241.242:8081/v1/servers/self/up
true
[andy@devportal]# curl http://192.168.241.242:8081/v1/servers/self/reachable
{
"message" : "This host is not reachable",
"contexts" : [ ]
}
This though, is reachability from an Edge perspective.
----------------------------------------------------------------------------------------------------------
From the loadbalancer however things are a little muddy.
Documentation says block the port to disable access to the router.
This iscorrect in that setting a firewall rule will prevent access to the service.
Let's disable that firewall
firewall-cmd --zone=`firewall-cmd --get-default-zone` --remove-port=15999/tcp
Test reachability as specified in the documentation:
curl http://192.168.241.242:15999/v1/servers/self/reachable -I
curl: (7) Failed connect to 192.168.241.242:15999; No route to host
So that works as expected.
However if someone disables the firewall rule while the router is still marked unreachable:
firewall-cmd --zone=`firewall-cmd --get-default-zone` --remove-port=15999/tcp
and retests reachability...
[andy@devportal]# curl http://192.168.241.242:15999/v1/servers/self/reachable -I
HTTP/1.1 200 OK
Hang on, that doesn't look right. We know the router is marked as unreachable but our loadbalancer check says that we should be reachable.
In fact,
http://192.168.241.242:15999/v1/servers/self/anything/here/at/all -I
HTTP/1.1 200 OK
Given the above it makes more sense to have a simple TCP check on port 15999 since the health-check doesn't reflect the state of the underlying system and simply returns 200 for anything /v1/server/self/*
Maruti and I updated that doc a few days back with more info along the lines of what you are saying, including adding the URL that the load balancer can use to perform an HTTP health check on the Router:
http://router_IP:15999/v1/servers/self/reachable
And changing the description of the following url:
http://<routerIP>:8081/v1/servers/self/up
Take a look and let me know what you think:
Stephen