non-ondatra device connections

[cm-nokia]

👋 hello!

I'm currently working on the accountz tests (though I believe this applies to at least a few others as well) and there is a requirement to connect to a dut "directly" on ipv4/ipv6 addresses of the dut, and also for some of these connections to intentionally fail (bad auth).

afaik this isn't currently super easy to do as ondatra lets us get at ready-made (working!) connections to the device and doesn't expose v4/v6 addresses directly.

so the main question is: what is the recommended/preferred way to get at this information to satisfy these test requirements?

currently just using a quick and dirty thing like:

    var serviceDUT interface {
        Service(string) (*tpb.Service, error)
    }

    err := binding.DUTAs(dut.RawAPIs().BindingDUT(), &serviceDUT)
    if err != nil {
        t.Log("DUT does not support `Service` function, will attempt to use dut name field")

        return dut.Name()
    }

    dutSSHService, err := serviceDUT.Service("ssh")
    if err != nil {
        t.Fatal(err)
    }

    return dutSSHService.GetOutsideIp()

which works but feels kinda janky and also does us no favors for getting alternate addresses (v6).

we could simply fetch the mgmt interface of the dut and get the v4/v6 address that way of course -- perhaps this is the "best" answer overall, but wont work for kne and I can see some other scenarios where maybe it wont work for real hardware too.

tagging @greg-dennis for some fp/ondatra wisdom and @morrowc as this is related to accountz tests (you can share some fp/ondatra wisdom too :P)

[greg-dennis]

It seems like those addresses should be available over gNMI?

[cm-nokia]

It seems like those addresses should be available over gNMI?

as in, we can fetch them via gnmi (like off the mgmt port)? if yes then, yeah I think thats a totally viable path!

I think that wont work for kne though which is maybe relevant/important? and then was just worried that maybe there was some proxy/nat/whatever between where tests run and the hardware in other cases that this maybe wouldn't work with (its not an issue for me but just didn't wanna assume it wasn't for anyone else!)

if thats not what ya meant, say more! as im probably missing something 😁

[greg-dennis]

Yeah, you're right, proxies may get in the way. By "directly connect" in your original post, you mean by SSH then?

[cm-nokia]

you mean by SSH then

yea that, and also p4rt/gnmi/gribi. normally id just use the client I can fetch from ondatra but the test (this guy for example) specifically calls out connecting to the v4 and v6 addresses which I dont think I can request when fetching clients from ondatra right? that and needing to explicitly fail to connect on purpose (either via ssh w/ bad key as in credz tests or just bad password for ssh/gnmi in the accountz one)

[greg-dennis]

We do have the introspection API, actually, to retrieve details of how the grpc dials will work: https://github.com/openconfig/ondatra/blob/main/binding/introspect/introspect.go#L46

Anything with SSH, though, is going to be limited to devices that support that Service API, which is only KNE right now. If the test can stick to g* protocols, that would be ideal.

[LimeHat]

We do have the introspection API, actually, to retrieve details of how the grpc dials will work:

The challenge is the requirement to alternate ipv4/v6 connections. Is there any option in ondatra to accommodate v4 vs v6 target bindings?

https://github.com/openconfig/featureprofiles/blob/285c4233c71438b68737789cb9b30c4741b06df7/feature/security/gnsi/acctz/RecordSubscribeFull/README.md?plain=1#L9

Or is there an expectation to perform a dns lookup in the code and extract A/AAAA entries..?

[greg-dennis]

I've been thinking about this, and it's just not properly supported today. There is, however, an enhancement to the introspection API, and subsequent changes to the bindings, that would enable it. What's the urgency of the request?

[LimeHat]

From our perspective there's no urgency; we have to skip some of the acctz test scenarios that were outlined by @haussli and @morrowc in the test plans. Perhaps we can mark those as a future TODO item.