jlixfeld
commented
6 years ago For the archives, this was due to a few different things. Mainly, I suspect a bug in XR 5.3.4 where the output was too large and required streaming to be enabled. To throw a bunch of poo against the wall to see what stuck while debugging this, I also maxed out the throttle memory, but I didn't test to see if removing the memory throttle but leaving the streaming would have any affect. YMMV.
!
xml agent tty
throttle memory 600
iteration off
streaming on size 48
!Lastly, the output that was finally produced when running this on the XR CLI was so incredibly huge, I have to think that there is some sort of XR bug that created a loop of the same XML output. I saw the same data stream many tens of times in the output before I finally went ^C on it after over 5 minutes of it spewing whatever it was spewing.
This will produce the loop:
RP/0/RSP0/CPU0:bfr01.905KingStW01.YYZ#xml format echo
Sat Oct 27 10:51:48.007 EDT
XML><?xml version="1.0" encoding="UTF-8"?>
<Request MajorVersion="1" MinorVersion="0">
<Get>
<Operational>
<BGP>
<ConfigInstanceTable>
<ConfigInstance>
<Naming>
<InstanceName>
default
</InstanceName>
</Naming>
<ConfigInstanceVRFTable>
</ConfigInstanceVRFTable>
</ConfigInstance>
</ConfigInstanceTable>
</BGP>
</Operational>
</Get>
</Request>
When limiting it only to the VRF you're interested in, it works fine.
XML> <?xml version="1.0" encoding="UTF-8"?>
<Request MajorVersion="1" MinorVersion="0">
<Get>
<Operational>
<BGP>
<InstanceTable>
<Instance>
<Naming>
<InstanceName>
default
</InstanceName>
</Naming>
<InstanceActive>
<VRFTable>
<VRF>
<Naming>
Inetv4
</Naming>
<GlobalProcessInfo>
</GlobalProcessInfo>
<NeighborTable>
</NeighborTable>
</VRF>
</VRFTable>
</InstanceActive>
</Instance>
</InstanceTable>
</BGP>
</Operational>
</Get>
</Request>
<?xml version="1.0" encoding="UTF-8"?>
<Response MajorVersion="1" MinorVersion="0">
<Get>
...
...
...
</Get>
<ResultSummary ErrorCount="0"/>
</Response>
XML>
beufanet
ktbyers
jbotello7381
Not sure what to make of this, but I suspect it's a timeout issue although I'm not sure if it's user error or something else. I've tried to pass
--optional_args timeout=120to extend it a bit, but that still seems like a long time to return results. We're connecting, as can be seen from the successfulopen(),connection_tests()andget_facts().Looking at the device logs, the session is closed very shortly after the traceback is thrown, so it would seem to me it's not a keepalive issue closing the session.
I'm not finding any results searching for similar symptoms, so either no one is using napalm with XR 5.3.4, or this issue is something unique to me :)
Does anyone have some clue to lob over?