Wired Intelligent Edge

last person joined: 2 days ago 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

AOS-CX Switch - Virtual Appliance (OVA) - Trunk ports dropping traffic

This thread has been viewed 16 times
  • 1.  AOS-CX Switch - Virtual Appliance (OVA) - Trunk ports dropping traffic

    Posted Jul 13, 2020 05:42 PM

    Hi Airheads,

     

    I recently deployed the ArubaOS-CX virtual switch (OVA) in my lab (ESXi 6.7) for some TACACS testing.. I'm able to get the switch connected to my external network using an access port, but not using a trunk port. For reference, the upstream device has been configured to allow all VLANs with a PVID of 999 (no routable). VLAN 20 is to be used for switch connectivity on the default VRF. Is there something I'm missing that might apply to the virtual switch specifically? It seems like it's dropping tagged traffic.

     

    Access:

     

    interface 1/1/1
        no shutdown
        no routing
        vlan access 20
    interface vlan20
        ip address 172.16.10.31/24
    ip route 0.0.0.0/0 172.16.10.1
    
    ArubaCX-Lab-SW1# ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 100(128) bytes of data.
    76 bytes from 8.8.8.8: icmp_seq=1 ttl=115 (truncated)
    76 bytes from 8.8.8.8: icmp_seq=2 ttl=115 (truncated)
    76 bytes from 8.8.8.8: icmp_seq=3 ttl=115 (truncated)
    76 bytes from 8.8.8.8: icmp_seq=4 ttl=115 (truncated)
    ^C
    
    --- 8.8.8.8 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3003ms
    rtt min/avg/max/mdev = 18.433/19.725/21.600/1.216 ms

     

    Trunk:

     

    vlan 20
    	name Lab-Data
    vlan 999
    	name VLAN-Drop
    interface 1/1/1
    	no shutdown
    	no routing
    	vlan trunk native 999
    	vlan trunk allowed all
    interface vlan20
    	ip address 172.16.10.31/24
    ip route 0.0.0.0/0 172.16.10.1
    
    
    Aruba-CX-Lab-SW1# ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 100(128) bytes of data.
    
    --- 8.8.8.8 ping statistics ---
    5 packets transmitted, 0 received, 100% packet loss, 4111ms

     



  • 2.  RE: AOS-CX Switch - Virtual Appliance (OVA) - Trunk ports dropping traffic
    Best Answer

    MVP GURU
    Posted Jul 13, 2020 07:09 PM

    Hi! so the peer device has a NIC port configured to have PVID (Port VLAN Id) equal to 999...but, AFAIK, if you're playing with ESXi the vSwitch where that NIC port is connected to (vnic) should be agnostic...is the related Port Group that should have the VLAN id set to none (default) as per untagged packets or set to the VLAN id you need if you're creating a relationship with Tagged VLAN Id on switch side. 



  • 3.  RE: AOS-CX Switch - Virtual Appliance (OVA) - Trunk ports dropping traffic

    Posted Jul 13, 2020 07:20 PM

    That's the part I was missing(!). Reconfigured the port group for vlan ID 4095 in VMware and the switch was much happier:

     

    REgan_0-1594682379712.png

     



  • 4.  RE: AOS-CX Switch - Virtual Appliance (OVA) - Trunk ports dropping traffic

    MVP GURU
    Posted Jul 14, 2020 05:06 AM

    Nice, the attached image is too small...I didn't know about VLAN Id 4095 mode on Port Group...I usually go with a VLAN id for each Port Group so in a Port Group that should accept untagged traffic I simply set its VLAN id to 0 (None) which, AFAIK, means disabling VLAN tagging on that port group (EST Mode), in favor of VLAN untagging, I add.

     

    VLAN id 4095 use case looks like when a Port Group is going to receive various concurrent VLAN id(s) all tagged.



  • 5.  RE: AOS-CX Switch - Virtual Appliance (OVA) - Trunk ports dropping traffic

    Posted Jul 14, 2020 05:18 PM

    Correct! - It looks like VID of 4095 in a VMware Port Group will accept all tagged traffic so it should work with trunk ports on the CX.

     

    Also, I made the image bigger. - Thanks again for your help!