Header Only - DO NOT REMOVE - Extreme Networks
Solved

GraphiQL doesn't give a correct list of VLANs ID

  • 17 October 2019
  • 9 replies
  • 147 views

Userlevel 1

Hello,

 

I’ve been trying to get a list of the VLANs on a VSP device. 

The device is a VSP-8404 with 6.1.6.0 firmware, and the XMC version is 8.2.4.55.

 

I know of two ways to get them.

The first one would be to send a CLI command with emc_cli, and get the output, then filter it to get a list. 

cli_output = emc_cli.send("show vlan basic").getOutput().encode('ascii', 'ignore')

The second one is using emc_nbi and sending a query to get the VLANs ID

var_query = '''query{network{device(ip: "DeviceIP"){deviceData{vlans{vid}}}}}'''
var_result = emc_nbi.query(var_query)
vlans_id = var_result['network']['device']['deviceData']['vlans']

But, I noticed that using NBI doesn’t give me the same result as using CLI.

With CLI, I get this list :  1, 2, 49, 170, 180, 190, 4049, 4051, 4052

With NBI, I get this list : 1, 2, 49, 170, 180, 666, 4049

 

The NBI is not correct, as I don’t get the 190, 4051 and 4052, and it adds the 666.

 

I don’t understand why this difference is present. Is there something I’m doing wrong ?

 

Thanks a lot for the help

icon

Best answer by BCN-rbrt 17 October 2019, 23:01

Hey everyone,

I had the same problem with the NBI and, together with GTAC, found out that refreshing the device with a mutation and querying the right context within the NBI solves it - at least for EXOS and EOS. Try this (replace the IP with the management IP of the switch in question):

mutation {
network {
rediscoverDevices(input: {devices: [{ipAddress: "10.0.0.1"}]}) {
status
message
}
}
}

After firing this mutation, wait for 15 minutes (or check the Operations view) and try the following GraphiQL query (again, replace the IP).

query {
network {
deviceVlans(ip: "10.0.0.1") {
name
vid
primaryIp
netmask
ipForward
}
}
}

See https://link.medium.com/m5yqUU15y0 for an in-depth story on that topic.

View original

9 replies

Userlevel 3

Hi Nealo,

 

those two methods retrieve data from two different sources:

  • emc_cli: queries the switch
  • emc_nbi: queries XMC

The question now is: why does XMC not have the correct list of VLANs for that switch? 

Userlevel 1

Hi Kurt, 

 

As both queries’ sources are different, I guess we can say that as emc_cli queries the switch, it is the correct one ?

 

And I don’t know why XMC doesn’t have the correct list of VLANs. 

I checked with either ERS or VSP, with different firmware versions, the list I get with NBI is never correct.

 

Is there something I can do to help ?

Userlevel 3

I cannot help with why XMC doesn’t retrieve the full, correct list of VLANs from those devices. Maybe someone else reading this can? But yeah, the emc_cli will give you the definitive answer on which VLANs actually exist on a switch since it is executing this CLI command on that switch.

Userlevel 3

Hey everyone,

I had the same problem with the NBI and, together with GTAC, found out that refreshing the device with a mutation and querying the right context within the NBI solves it - at least for EXOS and EOS. Try this (replace the IP with the management IP of the switch in question):

mutation {
network {
rediscoverDevices(input: {devices: [{ipAddress: "10.0.0.1"}]}) {
status
message
}
}
}

After firing this mutation, wait for 15 minutes (or check the Operations view) and try the following GraphiQL query (again, replace the IP).

query {
network {
deviceVlans(ip: "10.0.0.1") {
name
vid
primaryIp
netmask
ipForward
}
}
}

See https://link.medium.com/m5yqUU15y0 for an in-depth story on that topic.

Userlevel 1

Thanks a lot for providing a solution BCN-rbrt !

 

By any chance, do you know what a mutation does ? Does it change anything on the device, or something like that ?

Because, I’d like to be sure it doesn’t affect the network before implemanting a workflow that uses a mutation.

Userlevel 3

The mutation above just triggers a refresh device within XMC, so no changes are done to either the device or XMC.

Userlevel 1

 

query {
network {
deviceVlans(ip: "10.0.0.1") {
name
vid
primaryIp
netmask
ipForward
}
}
}

I have a question about that request. 

The output is different if I use

network {deviceVlans {vid or

network {device {deviceData {vlans {vid

 

Shouldn’t both give the same result ?

Thanks

Userlevel 3

There is a lengthy, open GTAC case regarding API behaviour, which I condensed in the article I shared above. To summarize it for the context question: The API is still in development and deviceVlans is the right context to use for now. Out of the case, from Engineering:

In a nutshell, the query is for deviceData which internally is cached mainly for provisioning/ZTP and should not technically be used for reading device info

As far as I know there is a CR to remove the deviceData/vlans context from the GraphQL API, targeted for XMC 8.4 or 8.5. So this issue will be “solved” soon.

Userlevel 1

Thanks a lot for all those information !

Reply