By default the Cisco CSS 11501 series loadbalancers will create an implicit internal service to check the availability of the gateways for its static defined routes.
This internal service monitors the availability of the route which goes through a specific gateway by sending ICMP keepalives to that gateway. In that way if the internal service is in "Alive" state, the route for which the internal service is running is maintained in the routing table, otherwise if the service is in "Down" state then the route is withdrawn from the routing table (if there are no valid arp entries cached for that gateway).
The checking of the service availability is implemented through ICMP keepalives (ping) which are sent to the gateway of the destination defined in the static route.
These services are visible from the debug mode of the CSS. To have a look how they are defined and at which interval the keepalives are sent you can use:
CSS11501# llama
which gets you to debug mode
CSS11501(debug)# show service-internal
Name: nexthop00001 Index: 0
Type: Local State: Alive
Rule ( 192.168.0.1 ANY ANY )
Session Redundancy: Disabled
Redirect Domain:
Redirect String:
Keepalive: (ICMP 5 3 5 )
In the example above the name of the service is nexthop00001, the checked gateway is 192.168.0.1, the keepalive type is ICMP, the frequency with which the ICMP echo requests are sent is 5 seconds, the maximum number of consecutive ICMP failures is 3 (after 3 consecutive ICMP echo requests which do not receive an ICMP echo reply the service will be marked in the "Down" state) and the retry period after which a "Down" state service will be rechecked for availability is 5 seconds.
An important note is that the type of the keepailve cannot be changed into something different than ICMP for the internal service. Should you consider to block ICMP on the next hop routers consider that destinations which are reachable through that router which blocks ICMPs may be withdrawn from the routing table of the loadbalancer, hence causing problems.
Should you have a policy by which you are blocking ICMP echo requests/replies on all your routers you have the workaround to disable the internal service checks on the loadbalancer. In this case all the defined static routes are available, even if the next hop router is not available. The loadbalancer will preserve the route in the routing table and try to forward the packets on that path.
The removal of the internal services for static routes is done by:
CSS11501(config)# ip no-implicit-service
After this command is entered a reboot is needed otherwise this change will take effect only for newly added routes (The existing ones will still have the internal service checks).
After reboot the following output should be seen:
CSS11501(debug)# show service-internal
CSS11501(debug)#
which attests that no internal service check are running for the defined static routes.
This internal service monitors the availability of the route which goes through a specific gateway by sending ICMP keepalives to that gateway. In that way if the internal service is in "Alive" state, the route for which the internal service is running is maintained in the routing table, otherwise if the service is in "Down" state then the route is withdrawn from the routing table (if there are no valid arp entries cached for that gateway).
The checking of the service availability is implemented through ICMP keepalives (ping) which are sent to the gateway of the destination defined in the static route.
These services are visible from the debug mode of the CSS. To have a look how they are defined and at which interval the keepalives are sent you can use:
CSS11501# llama
which gets you to debug mode
CSS11501(debug)# show service-internal
Name: nexthop00001 Index: 0
Type: Local State: Alive
Rule ( 192.168.0.1 ANY ANY )
Session Redundancy: Disabled
Redirect Domain:
Redirect String:
Keepalive: (ICMP 5 3 5 )
In the example above the name of the service is nexthop00001, the checked gateway is 192.168.0.1, the keepalive type is ICMP, the frequency with which the ICMP echo requests are sent is 5 seconds, the maximum number of consecutive ICMP failures is 3 (after 3 consecutive ICMP echo requests which do not receive an ICMP echo reply the service will be marked in the "Down" state) and the retry period after which a "Down" state service will be rechecked for availability is 5 seconds.
An important note is that the type of the keepailve cannot be changed into something different than ICMP for the internal service. Should you consider to block ICMP on the next hop routers consider that destinations which are reachable through that router which blocks ICMPs may be withdrawn from the routing table of the loadbalancer, hence causing problems.
Should you have a policy by which you are blocking ICMP echo requests/replies on all your routers you have the workaround to disable the internal service checks on the loadbalancer. In this case all the defined static routes are available, even if the next hop router is not available. The loadbalancer will preserve the route in the routing table and try to forward the packets on that path.
The removal of the internal services for static routes is done by:
CSS11501(config)# ip no-implicit-service
After this command is entered a reboot is needed otherwise this change will take effect only for newly added routes (The existing ones will still have the internal service checks).
After reboot the following output should be seen:
CSS11501(debug)# show service-internal
CSS11501(debug)#
which attests that no internal service check are running for the defined static routes.
No comments:
Post a Comment