New Cisco CML 2.0 appliances

[jean-christophe-manciot]

I have attached all new CML 2.0 appliances definitions through yaml files in case you don't already have them.

I have noticed:

• I cannot have correctly numbered interfaces in the GUI for CSR-1000v-16.11.1b; they jump from Gi1 to Gi0 to Gi1 again then Gi2... with the following settings:
  • management interface defined as Gi1
  • name format as Gi{0} or Gi{1} for the other interfaces
  • number of interfaces: 32 (as defined in the corresponding yaml)
• 2 strange physical interfaces are defined for IOS-XRv-9k-fullk9-x-6.6.2: this may have some consequences with the connected links (not tested yet)
  • donotuse1
  • donotuse2

[jean-christophe-manciot]

I confirm that on the CSR-1000v-16.11.1b with 32 interfaces set:

• there is no actual GigabitEthernet0 despite having Gi0 displayed in the GUI (in second position)
• only 26 interfaces are available:

CSR_1000v-16.11.1b#sh ip int bri
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       172.21.16.31    YES DHCP   up                    up      
GigabitEthernet2       unassigned      YES NVRAM  administratively down down    
GigabitEthernet3       unassigned      YES NVRAM  administratively down down    
GigabitEthernet4       unassigned      YES NVRAM  administratively down down    
GigabitEthernet5       unassigned      YES NVRAM  administratively down down    
GigabitEthernet6       unassigned      YES NVRAM  administratively down down    
GigabitEthernet7       unassigned      YES NVRAM  administratively down down    
GigabitEthernet8       unassigned      YES NVRAM  administratively down down    
GigabitEthernet9       unassigned      YES NVRAM  administratively down down    
GigabitEthernet10      unassigned      YES NVRAM  administratively down down    
GigabitEthernet11      unassigned      YES NVRAM  administratively down down    
GigabitEthernet12      unassigned      YES NVRAM  administratively down down    
GigabitEthernet13      unassigned      YES NVRAM  administratively down down    
GigabitEthernet14      unassigned      YES NVRAM  administratively down down    
GigabitEthernet15      unassigned      YES NVRAM  administratively down down    
GigabitEthernet16      unassigned      YES NVRAM  administratively down down    
GigabitEthernet17      unassigned      YES NVRAM  administratively down down    
GigabitEthernet18      unassigned      YES NVRAM  administratively down down    
GigabitEthernet19      unassigned      YES NVRAM  administratively down down    
GigabitEthernet20      unassigned      YES NVRAM  administratively down down    
GigabitEthernet21      unassigned      YES NVRAM  administratively down down    
GigabitEthernet22      unassigned      YES NVRAM  administratively down down    
GigabitEthernet23      unassigned      YES NVRAM  administratively down down    
GigabitEthernet24      unassigned      YES NVRAM  administratively down down    
GigabitEthernet25      unassigned      YES NVRAM  administratively down down    
GigabitEthernet26      unassigned      YES NVRAM  administratively down down    

[jean-christophe-manciot]

It seems to be a misinterpretation of the field "Firs port name" on my part.
I've just found a way to make the interfaces labels start at 1:

First port name:
Name format: Gi{port1}

[grossmj]

@jean-christophe-manciot sorry for the delay but are we still behind on this?

[jean-christophe-manciot]

@grossmj
This issue has evolved with GNS3 GUI/Server 2.2.29:

• CSR 1kv 16.11.1b interfaces start with Gi0 on the GUI but start with GigabitEthernet1 on the device CLI on an old lab
• CSR 1kv 17.3.1a interfaces are correctly labelled on the GUI on new labs
• IOS XRv 9k interfaces are correctly labelled on the GUI on new labs

So, the interfaces are correctly labelled for newly added devices, but are not modified on old labs.
I've noticed a new way to modify the interfaces name in the "Configure custom adapters" menu.
It is now kind of cumbersome to modify the numbering when there is a gap: all subsequent interfaces must be relabeled as well.
For instance:
Gi1, Gi0, Gi1, Gi2, Gi3, ... must be manually relabeled into Gi1, Gi2, Gi3, Gi4, Gi5...Gi31...

Isn't it possible to automatically increment the label of the next interfaces when one is modified?
In the previous example, modifying Gi0 into Gi2 would automatically modify Gi1 into Gi3, Gi2 into Gi4 and so on.

If it's too much hassle, don't bother.