![]() Being said this, the downstream or upstream switches will definetely know how to handle those packets. My understanding is that the ICMP packets (when the interface and the secondary IP are not specified), are sourced from the reth interface and they use the reth MAC address as the source MAC. I haven’t perform a lab recreation for this but I am concerned about few things here. ![]() Maybe what is meant by “limited monitoring functionality” is show chassis cluster ip-monitoring status You might get limited monitoring functionalityĪlso an odd thing for me is that 192.168.60.1 (monitored IP) status is always reachable Warning: interface option is not configured. If you try to monitor IP e.g 192.168.60.1, you receive the following warning on every commit commit According to my test on a 11.4R7.5 release Let me know if you have any feedback/questions.Īfter finishing this post, Steven asked in this post: what happens if we don’t configure the secondary-ip-address, I didn’t know the exact answer. IP monitoring is more clear for me after these tests. This caused a sort of dead lock in the cluster but Which fails again and causes another failover. ![]() Ping from 11.99 but once the failover occurs, node1 becomes primary and now it starts pinging from 11.100 Yes assumption was correct it should trigger a failover as node1 is able to Iptables -A INPUT -p icmp -s 172.17.11.100 -j DROPĪnd it should trigger a failover. I thought that I can just block ICMP from 172.17.11.100 on the Linux GW device as such This happened after I made simulation mistake:) You might see the high failure count 46 in the output. Now, I change the config and set the IP weight to 200 and global to 255 to simulate a failover Īfter a network failure, node1 becomes primary this show chassis cluster status RG1 threshold must reach 0 which isn’t the case on this simulation. You might have noticed that there is no failover yet, since for failover to happen, Sep 19 14:34:43.379 : hold->secondary, reason: Hold timer expired Redundancy group: 1, Threshold: 155, Monitoring failures: ip-monitoring Sep 19 14:34:43.366 : hold->secondary, reason: Hold timer expired Redundancy group: 0, Threshold: 255, Monitoring failures: none When we check the cluster information, we can see that threshold is 155 now.īecause our global weight is 100 for this monitored IP address show chassis cluster information Ip address is marked as show chassis cluster ip-monitoring status Now I disable ICMP responses on the gateway, to simulate a failure and IP is show chassis cluster ip-monitoring status Is using the IP 172.17.11.99 (with MAC address of the secondary node child interface)Īfter configuring this ip-monitoring, here is the status. Primary node is using reth0.0 interface address (172.17.11.100) as the source and secondary node Note: Configured secondary-ip-address shouldn’t be the primary IP address on reth0.0Īs far as the documentation is concerned but it must be on the same subnet.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |