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.