Routers reachability using 15999 or /self/up API

Not applicable

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
1 5 477
5 REPLIES 5

@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.

5857-screenshot-2017-11-02-at-10445-pm.png

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.

Not applicable

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:

  • 200 would indicate reachable
  • 503 would indicate unreachable

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/*

sgilson
Participant V

Hi @Andy Trickett

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:

https://docs.apigee.com/private-cloud/latest/enablingdisabling-server-message-processorrouter-reacha...

Stephen