Forum Discussion
NimbostratusSIP traffic - minor issue with OPTIONS messages
Hello all,
I just need advice for my "problem" if someone knows or had the similar problem.
Rough architecture is like this:
Opencloud Rhino (2 nodes) < = > F5 Big-IP (software version 10.2.4) < = > NSN MSS (6 nodes)
So on LB i have SIP-monitor which i use to check availability of Rhino nodes -> this is working fine
MSS also have health monitor to check availability of LB. So all 6 MSS's nodes are sending OPTIONS messages to LB, and LB should answer on them... If not then MSS receives alarm and the MSS node, on whose requests LB didn't answer, will mark LB like "dead" for time being.
So in my case when there is no SIP traffic between network elements, then OPTIONS messages are just fine (all requests are answered). In case when there is a SIP traffic then sometimes for some (random) calls that OPTIONS message exchange is affected somehow and LB is not answering to all MSS requests (there is no answer to max 2 of 6 nodes). Note this is happening only for a short period of time (1-2 min and then again it is fine) and maybe few times per day, so it is not a big deal, but customer wants to know why this is happening...
I really don't know the answer on that question because i don't know how can i influence on OPTIONS messages, so if someone has some knowledge/experience/suggestion i would be very grateful.
P.s. All calls are working fine, so i guess config is OK.
Regards,
Zvone
16 Replies
Zvone_CRO_12312Anyone?? some suggestion or something.
I don't want my post to be with 0 replies :)- What_Lies_Bene1
Cirrostratus
Zvone, can you expand a bit on the OPTIONS messages, particularly why you think the F5 should be responding to them. What IP on the BIG-IP are you directing them to? - Zvone_CRO_12312
Hello Steve,
LB must respond to those request because of availability check, if MSS recives less than 50% answers then particular MSS node, which was sending requests, will mark LB like "down" and won't send any SIP traffic from that MSS node.
I don't know if F5 is responsible for this issue, that's why i need advice. Customer thinks that this issue has something to do with me/LB since LB is the one not answering to all requests, but i don't see how i can influence on those responses to OPTIONS requests sent from MSS.
SIP health monitor I use on LB to check Rhino servers availability is working perfectly.
The same thing is done from MSS side. There is health monitor from MSS side towards LB and there we have minor issues(only for some calls) i posted in earlier post .
So IP are following:
Active LB 10.21.28.93 (Public IP subnet) ----|
|----- VIP address 10.21.28.94 <<==>> 6 MSS nodes (10.21.50.6 - 10.21.50.11)
Standby LB 10.21.28.92 (Public IP subnet) ----|
I hope i explained problem well.
Regards,
Zvone
- What_Lies_Bene1Sorry for the delay in responding. I'm afraid I'm still somewhat confused by the MSS monitors. Do the MSS node's monitors point to the VIP address for the two Rhino servers? What I'm trying to understand is whether the F5 itself is responding or something else that is accessed through it.
If not the VIP address for the two Rhino servers then what? - Zvone_CRO_12312
Hello Steve,
I am not sure what do you think by "VIP address for the 2 Rhino servers"?? LB is here in place to hide Rhino servers and all other network elements, and MSS nodes can see only LB's Public VIP address, which is 10.21.28.94 .
I would go with assumption that F5 is responding itself since, i guess, i cannot influence ot that responses through F5configuration.
Only MSS and Rhino nnodes are "talking" with LB, there is nothing else accessing LB.
It is really weird issue, i know :) I am also confused.
Don't break your head over this, it is not worth it.
Regards,
Zvone
- What_Lies_Bene1OK, so the MSS nodes send their monitor traffic to the LB public VIP IP yes. So, the F5 won't respond on a servers behalf, it will send that monitor traffic to one of the two Rhino hosts and one of those hosts will respond (hopefully). This isn't an ideal configuration as your monitoring traffic is effectively being load balanced. I'd suggest you would be better off doing a simple tcp port check to the LB VIP (depending on the type); that will prove the VIP is up. For the path between the F5 and the Rhino servers, I assume you have monitors configured and working so you'll have the end to end flow covered.
- Zvone_CRO_12312
Hey Steve,
Yea calls are working so end to end flow is there. On more question from my side since now i am a bit confused :)
So you have said that LB won't respond on a servers behalf, but monitor traffic (request every 5 sec) will be send to Rhino servers. Furthermore, my SIP monitor on LB is also sending those requests (every sec) to Rhino servers to check their availability. Does this mean i am basically duplicating monitor traffic on Rhino servers??
I can suggest this tcp port check from MSS side instead of current monitor.
Regards,
Zvone
- What_Lies_Bene1Sure. Yes, you are monitoring twice, once from the MSS servers via the F5s to one of the Rhino servers (which ever is selected by the load balancing algorithm) and from the F5 itself too. If you could just monitor the Virtual Server from the MSS servers that would be the optimal configuration.
I'd suggest you test first however to ensure that the MSS to VIP monitor fails when both Rhino servers are marked as down. Ping for instance will still work if there are other Virtual Servers using the same Virtual IP Address. - Zvone_CRO_12312
Hey Steve,
Thanks for your answers so far.
I was following your official document for SIP configuration and this is the reason i have SIP monitor towards Rhino servers.
I guess i could try to use some other monitor instead, which won't send OPTIONS messages.
Got it, will also try your suggestion to see what will happen in such scenario.
And for ping; I have only 2 VS and each of them has different VIP.
Will share my findings after i try all above.
- What_Lies_Bene1A SIP monitor from the F5 towards the Rhino servers makes sense but not from the MSS servers.
Let us know. Thanks
