Junos 19.4 actively rejects any requests having any value specified for qos

[agileone]

V0.8.9 always include qos attribute for subscribe requests, which Junos 19.4 does not accept. Even with 'marking':0 the router will not execute the request. I included the client.py locally and changed the qos initialization like so:

        # qos
        # if 'qos' not in subscribe or not subscribe["qos"]:
        # subscribe.update({'qos': {'marking': 0}})
        subscribe.pop('qos', "dummy") 

and that resolved the matter.

There has been new versions of this file since the 0.8.9 release addressing qos init, but it stil does not seem to allow not specifying any value :

        # qos
        if self.__no_qos_marking:
            subscribe.update({'qos': None})

There should be a way to make sure qos is not added to the subscribe request.

Error from the router:

******************** Error : <_Rendezvous of RPC that terminated with:
status = StatusCode.UNIMPLEMENTED
details = "Qos not supported"
debug_error_string = "{"created":"@1675546143.152638355","description":"Error received from peer ipv4:xxxxx:57400","file":"src/core/lib/surface/call.cc","file_line":1041,"grpc_message":"Qos not supported","grpc_status":12}"

[akarneliuk]

Hello @agileone , Thanks for raising. We'll see, what may be the best way to implement it.

Did you raise with Juniper TAC, why they don't support "qos"?

Best, Anton

[agileone]

Not yet, but yes, I will engage with Juniper support too. I also made a local version of client.py that provides some workarounds for this issue and another one, I need to validate with Juniper support first. So, I can actually create a fork, for you to review and guide for a solution, maybe based on no_qos_marking flag that is on the HEAD/latest version of client.py.

[Menotomy]

FYI, this was identified in #101, and pull request #103 includes a workaround. So in theory it's fixed in 0.8.10 or whatever next release comes out.

[akarneliuk]

Hey @Menotomy @agileone

That is published in 0.8.10.

Best, Anton