Forum Discussion

Stefan_Klotz's avatar
Stefan_Klotz
Icon for Cumulonimbus rankCumulonimbus
Feb 12, 2026
Solved

Partially reachabilty issues with VS in F5OS tenant

As preparation of our service migration from iSeries to rSeries, we created a test-VS without a pool, but with an iRule responding with a simple static html-website.
This works fine so far, but we must notice, that sometimes this VS is not reachable in the F5OS tenant.
For now we could at least identify that the issue seems to be on the border between F5OS and tenant, because we see incoming packets with tcpdump on F5OS level, but they will not be forwarded into the tenant, because with the tcpdump there it's missing.
Is this behavior related to the VS type of just using an iRule or is there something wrong/corrupt in our configuration?
How can I further verify/troubleshot this, once the issue occurs again? Or which settings should I double check?
We want to be sure to have the correct basic setup available, before migrating the first productive VS to the new platform.

For your reference, we are using route domains in combination with partitions within the tenant.
So we created the VLANs on F5OS level, then deleted them in the Common partition in the tenant and then re-created them again with the same name, but in the correct partition/route domain. And finally created the selfips within the partition/route domain within the tenant.
F5OS: 1.8.3EHF1, TMOS: 17.5.1.3

Thank you!

Regards,
Stefan

  • It seems I could identify and solve the issue.
    I added another VS in that partition, but with a real pool, poolmember and monitors. As of now it looks like, that the continuous traffic from the node- and pool-monitor keeps "something" alive, because all VS are always reachable. No interruptions anymore.
    Ok, my initial test with just an iRule based VS was maybe not optimal, but nevertheless it would be interesting why this VS is not reacting from outside?
    Has someone an explanation for this, especially in combination with the above mentioned conditions?
    Thank you!

    Regards,
    Stefan :)

4 Replies

  • Hi Stefan

    From where do you test the connectivity?

    I have seen scenarios where the tcpdump didn't "work" in the tenant (aka no packages caught) but the VS working just fine.

    From what you are describing you are doing nothing wrong, all seems to be by the book and the software versions you are using should have fixed weird vlan problems.

    What I would do is setup a proper VS configuration with pool members, that way you are making a better test and the traffic will move through the device the way it is designed. 

  • The thing is, that I see packets correctly with tcpdump within the tenant, the moment, where the VS is working. And I just see them on F5OS-level, the moment, where it is not working. I'm trying to reach the VS (via browser or ping) from outside the LB. At the time when the issue occurs, I can ping the VS from within the LB/tenant.
    In the meantime, I've created a normal VS including a pool and poolmember in a second partition/route domain, but on the same tenant, and here I don't see any disruptions so far. I also created such a iRule-based VS with the same static website and also for this I can't replicate the issue.
    So I'm still wondering, if I made maybe any small mistake in the other partition/route domain (any maybe in others as well), which would then have any negative impact during/after migration of services onto the new platform.
    That's why I want to verify where this behavior comes from, meaning some kind of "normal" behavior or some corrupt configuration.
    Thank you!

    Regards,
    Stefan :)

  • It seems I could identify and solve the issue.
    I added another VS in that partition, but with a real pool, poolmember and monitors. As of now it looks like, that the continuous traffic from the node- and pool-monitor keeps "something" alive, because all VS are always reachable. No interruptions anymore.
    Ok, my initial test with just an iRule based VS was maybe not optimal, but nevertheless it would be interesting why this VS is not reacting from outside?
    Has someone an explanation for this, especially in combination with the above mentioned conditions?
    Thank you!

    Regards,
    Stefan :)