Wired Intelligent Edge

 View Only
last person joined: yesterday 

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

Migrating from PVOS to AOS-CX & could use some help.

This thread has been viewed 55 times
  • 1.  Migrating from PVOS to AOS-CX & could use some help.

    Posted Dec 29, 2021 09:06 AM

    Good afternoon.  I've just about exhausted myself trying to figure this out on my own and figured I'd ask you fine folks for assistance.  Disclaimer: despite at one time holding a CCNA, I'm NOT a networking guy, I'm a systems administrator who *thought* he knew a thing or two about networking but is quickly learning otherwise.

    Small organization, 300 or so users.  3 buildings connected over fiber.  Currently running PVOS switches and have AOS-CX switches to replace them with.

    Warehouse<----->Datacenter<----->headquarters

    Each building is home to 3 vlans:

    Warehouse: 21 data, 23 phone + 100 management

    Datacenter: 11 data, 13 phone + 100 management

    Headquarters: 31 data, 33 phone + 100 management

    All L3 switching happens at the datacenter.  L2 switching happening at warehouse and hq and it's carried over fiber to the datacenter to get where it's going.

    Typical configuration for a port looks like this:

    vlan 21

    name "warehouse data"

    tagged 1-48

    no ip address

    exit

    vlan 23

    name "warehouse voice"

    tagged 1-48

    no ip address

    exit

    If you patch a computer into one of these switches, it will land on vlan 21.  If you patch a phone into a switch, it will contact the DHCP server, get the ftp server option and config file, pull down config file that will bounce the phone over to vlan 23 where it will request a new IP address for vlan 23.  A computer attached to the phone will end up on vlan 21.  All pretty straight-forward stuff so far right?

    On Thursday I went to replace the warehouse switch with a new AOS-CX switch.  Configuration was fairly straightforward, or so I thought.  Basically

    vlan 21

    vlan 23

    vlan 100

    interface 1/1/1-1/1/48

    vlan trunk native 21

    vlan trunk allowed 21, 23, 100

    Connected fiber between AOS-CX switch in the warehouse and the PVOS switch running L3 in the datacenter and got some really, really, really odd pings and behavior.  Spent about 4 hours banging on it on Thursday night before wrapping up for the holiday, but it's been wearing on me.  My best guess was that AOS-CX native vlan was NOT EQUAL to PVOS untag.  

    I spent most of the day today pouring over existing configs, making sure that I wasn't missing something somewhere.  I've been looking through a ton of documentation also, which I'm a little skeptical of.

    Datacenter L3 switch relevant config looks like this

    vlan 21

    name "warehouse data"
    untagged A2 (this is the fiber connection coming from the warehouse)

    ip address 192.168.21.1 255.255.255.0

    ip helper 192.168.11.3

    exit

    vlan 23

    name "Warehouse Voice"

    tagged A2 (fiber connection from warehouse)

    ip address 192.168.23.1 255.255.255.0

    ip helper-address 192.168.11.3

    exit

    This does not work.  So I referenced this:
    ArubaOS-CX 10.04 Fundamentals Guide 6200 Switch Series - Comparing VLAN commands on PVOS, Comware, and ArubaOS-CX (hpe.com)


    I'm extremely skeptical of some of the commands here and am asking for insight.  In scenario 1 there's inter-switch link with all traffic tagged.

    AOS-CX reads interface 1/1/1

    Vlan trunk native 1

    vlan trunk allowed 10, 30, 50

    Correct me if I'm wrong here but for ALL TRAFFIC TAGGED wouldn't we want vlan trunk native 1 TAG?

    On the pvos side we've got

    interface A1

    tagged vlan 10,30,50 

    no untagged vlan 1?
    HUH?  wouldn't it just be untagged vlan 1?

    Scenario 2 actually looks like what I want.  "Interswitchc link with all traffic tagged, EXCEPT for untagged traffic on a specific vlan (21 for me).

    Interface 1/1/1

    vlan trunk native 10 tag? (what? pretty sure we don't want a tag here)

    vlan trunk allowed 10, 30, 50

    note specifically says "same as scenario 1 but allows untagged traffic on vlan 10 as well" how when we are running the vlan trunk native 10 TAG command?

    On the PVOS side this isn't supported.  Scenario 1 is a workaround.

    Onto scenario 3. Interswitch link with all traffic tagged or untagged.

    Interface 1/1/1

    vlan trunk native 5

    vlan trunk allowed 5, 10, 30, 50

    Looks reasonable.  This is actually what we came up with on our side for correct configuration of the AOS-CX switches.  Ok, what do we need to do on the PVOS side to make stuff work?

    interface A1

    untagged vlan 5 - looks reasonable, matches to vlan trunk native 5

    no tagged vlan 10,30,50

    Wait what?  can you actually do this?  If I go into one of my vlans on a PVOS switch and type

    "no tagged vlan 23, 100" you're telling me that it's not going to remove

    tagged 1-48

    Any help, insight, suggestions etc. would be greatly, greatly appreciated here.  I wanted to roll out this upgrade in stages, do the warehouse and then headquarters and then replace the L3 switch with our AOS-CX switches...struggling here.



    ------------------------------
    Killo Richards
    ------------------------------



  • 2.  RE: Migrating from PVOS to AOS-CX & could use some help.

    Posted Dec 29, 2021 11:35 PM
    You provided a lot of context information.  I am also gleaning the details, please forgive me.
    What models of CX switch are you using?

    To create a VLAN, it's either trunk or access.
    Define the vlan, and then attach them to the interface.

    below describes a native vlan 1 (access vlan) with trunk vlans.
    if you have traffic on vlan 1, this will suffice.

    the 71-74 means inclusive vlans.

    interface 1/1/24
    no shutdown
    no routing
    vlan trunk native 1
    vlan trunk allowed 19,24,71-74,80

    If you're trying to interconnect a CX switch to an AOS-S switch, you can use a trunk.
    remember that the AOS-S port has to be tagged/trunk to accept the incoming trunked traffic.

    my example on AOS-S

    vlan 1
    name "DEFAULT_VLAN"
    no untagged 1-8,Trk1
    ip address dhcp-bootp
    ipv6 enable
    ipv6 address dhcp full
    exit
    vlan 19
    name "Infrastructure"
    tagged 5,7-8
    ip address 10.19.70.2 255.255.255.0
    exit
    vlan 24
    name "Wired"
    untagged 3-4
    tagged 7-8,Trk1
    no ip address
    ipv6 enable
    ipv6 address autoconfig
    exit

    Please let me know if you have questions...

    ------------------------------
    Shieva Eccles
    ------------------------------



  • 3.  RE: Migrating from PVOS to AOS-CX & could use some help.

    Posted Dec 30, 2021 07:39 AM
    • Shieva, please forgive me for the wall of text.  I was trying to be thorough and only managed to complicate the question / conversation.

      +Currently PVOS switches 2910's, 2920's etc. throughout the environment
      +Migrating to AOS-CX for core.  6200F stacks for L2 in warehouse and HQ and 6300M for L3 at datacenter

    Last Thursday we attempted to replace a PVOS switch with an AOS-CX switch model 6200F.  Existing config on the PVOS switch we were replacing looks like this (at least the relevant bits):

    vlan 1
       name "DEFAULT_VLAN"
       no untagged 1-40,42,B1-B2,Trk1-Trk4
       no ip address
       exit
    vlan 21
       name "Warehouse_Data"
       untagged 1-40,42,B1-B2,Trk1-Trk4
       no ip address
       exit
    vlan 23
       name "Warehouse_Voice"
       tagged 1-40,42,B1-B2,Trk1-Trk4
       no ip address
       qos priority 7
       voice
       exit
    vlan 100
       name "Management"
       tagged 35,B1,Trk1-Trk4
       ip address 192.168.100.2 255.255.255.0
       exit


    Our basic configuration to re-create this in AOS-CX 6200F switch looked something like this:

    Interface 1/1/1-1/1/48
    no shutdown
    vlan trunk native 21
    vlan trunk allowed 21,23,100
    

    Because of the environment, all ports are trunks and must carry vlan 21 and 23.  Phones are configured for VLAN 23 / tagged and endpoints are vlan 21 untagged, only switches and networking equipment exist on vlan 100. 

    For whatever reason, interfacing the 6200F with a 2920 pvos switch resulted in very odd pings.  We worked on this for 4 hours and were not able to figure out why things weren't working correctly.  When I began to do some research I found this document: ArubaOS-CX 10.04 Fundamentals Guide 6200 Switch Series - Comparing VLAN commands on PVOS, Comware, and ArubaOS-CX (hpe.com)

    Scenario 2 or Scenario 3 appears to be what I want.  However; scenario 2 is not supported on PVOS "Inter-switch link with all traffic tagged EXCEPT for untagged traffic on a specific VLAN (21 for me).  Ok, we will try scenario 3 "Interswitch link with all traffic tagged or untagged".

    ArubaOS-CX
    
    interface 1/1/1
    vlan trunk native 5
    vlan trunk allowed 5, 10,30,50
    VLAN 5 must be allowed on the trunk so that untagged traffic is not dropped.
    
    PVOS
    
    interface A1
      untagged vlan 5
      no tagged vlan 10,30,50 <---!!!! HUH?!?!?!?




    In the example provided by Aruba, they are suggesting to run the command "no tagged vlan 10, 30, 50" which would remove the command tagged vlan 10, 30, 50 and as such the only vlan that would move across this link would be vlan 5.  



    ------------------------------
    Killo Richards
    ------------------------------



  • 4.  RE: Migrating from PVOS to AOS-CX & could use some help.

    Posted Dec 30, 2021 09:50 AM
    Being thorough isn't usually a bad thing.

    I still am unclear as to the situation... here are my interpretations:

    - Because of the environment, all ports are trunks and must carry vlan 21 and 23.  Phones are configured for VLAN 23 / tagged and endpoints are vlan 21 untagged, only switches and networking equipment exist on vlan 100. 


    this should be the CX configuration based on your AOS-S config:

    interface 1/1/1
    no shutdown
    no routing
    vlan trunk native 21
    vlan trunk allowed 21,23,100

    the no routing command converts the port to a L2 port on CX.

    I think I see your observation now:
    I did the same in my lab...

    (eth-23)# sho run int 23


    Running configuration:

    interface 23
    disable
    tagged vlan 10,30,50
    untagged vlan 5
    exit

    (eth-23)# no tagged vlan 10,30,50

    (eth-23)# sho run int 23


    Running configuration:

    interface 23
    disable
    untagged vlan 5
    exit

    (eth-23)#

    I'm not sure what the guide is representing, but it's obviously incorrect.

    If I'm still missing the point, you can send me a private message with your email.



    ------------------------------
    Shieva Eccles
    ------------------------------



  • 5.  RE: Migrating from PVOS to AOS-CX & could use some help.

    MVP GURU
    Posted Dec 30, 2021 08:24 PM
    Hi Killo, why you said that "scenario 2 is not supported on PVOS "Inter-switch link with all traffic tagged EXCEPT for untagged traffic on a specific VLAN (21 for me)." ?

    I don't see any issue/restriction in configuring a physical or logical port (LAG case) used to connect to another switch and having it:

    (1) untagged member of a particular VLAN ID only (this is the "real" Native VLAN ID or Port VLAN ID = PVID in PVOS jargon)
    (2) untagged member of a VLAN ID AND, concurrently, tagged member of any other VLAN IDs (this acts like a port operating in VLAN "Trunk Mode")
    (3) tagged member of a VLAN ID only (and no untagged = untagged orphaned of a particular VLAN ID)
    (4) tagged member of any VLAN IDs only (and no untagged = untagged orphaned of a particular VLAN ID)

    Remember that a port need to have at least a tagging (Tag or No Tag) membership with regard to a VLAN ID, in other terms a port can't be totally orphaned of a VLAN ID membership (it needs to have at least one membership) AND the other rule is that that port can be untagged member of just one VLAN ID (that VLAN ID indeed will represent the "Native" Port VLAN ID or PVID which default to VLAN 1 but can be changed as you already know) BUT that port can also be concurrently - when needed - a tagged member of any number VLAN ID in addition of being untagged member of a VLAN ID OR it can be just only a tagged member of one VLAN ID or more VLAN IDs.

    So the only one restriction PVOS has is the fact a port can't be totally orphaned of VLAN tagging membership.

    You can allow (tagged or untagged) the VLAN IDs you need...if the AOS-CX peer port is:

    interface 1/1/1
    vlan trunk native 5
    vlan trunk allowed 5, 10,30,50


    it means that Interface 1/1/1 is untagged member of VLAN 5 and tagged member of VLAN 10, 30 and 50 SO on the PVOS side the matching port VLAN membership should be simply:

    interface A1
    untagged vlan 5
    tagged vlan 10,30,50

    and you can easily verify that on PVOS with the command: show vlan port ethernet A1 details.

    As a side note I will add that personally on a inter-switch link I prefer to pass (allow) only tagged VLAN IDs...so if I were you I will probably force this on the AOS-CX side and PVOS side:

    ArubaOS-CX
    
    interface 1/1/1
    vlan trunk native 5 tag
    vlan trunk allowed 5,10,30,50
    
    # That way the interface 1/1/1 will, using a PVOS jargon, act as a tagged member of VLAN ID 5, 10, 30 and 50 and is not an untagged member of any VLAN ID (technically it is orphaned of PVID - since it is not untagged member of any VLAN ID - from the PoV of the PVOS peer port). Using a AOS-CX jargon it is simply an interface operating in Trunk Mode where all VLAN IDs are allowed as tagged and the native VLAN ID is tagged to (which from the PoV of PVOS means nothing because the term "Native" refers to untagged membership only).
    
    PVOS (ArubaOS-Switch)
    
    interface A1
    tagged vlan 5, 10, 30, 50
    no untagged vlan 1 # this just to be sure to wipe the default (if any)
    
    # Check with show vlan port ethernet A1 details on PVOS.​


    On PVOS a port in default state has the PVID = 1 (it means it is untagged member of VLAN Id = 1 or that that Native VLAN ID is 1) and to change that default configuration you need to apply transitions like:

    VLAN 1 Untagged -> VLAN x Untagged (it changes the Native VLAN ID from 1 to x <- it remains untagged)
    VLAN 1 Untagged -> VLAN 1 Tagged (it configures the port to be orphaned of Native VLAN ID 1 because the port is becoming a tagged member of the very same VLAN ID 1)
    VLAN 1 Untagged -> VLAN x Tagged -> VLAN 1 No Untagged (it configures the port to be first also a tagged member of a new VLAN ID x AND then it removes the Native VLAN ID 1)


    Always check your changes with the CLI command show vlan port ethernet <port-id> details

    ------------------------------
    Davide Poletto
    ------------------------------



  • 6.  RE: Migrating from PVOS to AOS-CX & could use some help.

    Posted Dec 31, 2021 02:59 AM
    Connected fiber between AOS-CX switch in the warehouse and the PVOS switch running L3 in the datacenter and got some really, really, really odd pings and behavior.  Spent about 4 hours banging on it on Thursday night before wrapping up for the holiday, but it's been wearing on me.  My best guess was that AOS-CX native vlan was NOT EQUAL to PVOS untag. Looks reasonable.  This is actually what we came up with on our side for correct configuration of the AOS-CX switches.  Ok, what do we need to do on the PVOS side to make stuff work?

    ------------------------------
    Nathaniel Witting
    ------------------------------



  • 7.  RE: Migrating from PVOS to AOS-CX & could use some help.

    Posted Dec 31, 2021 06:28 AM
    not sure what the problem is with the switches that were slated for the warehouse but there was either problems in the firmware or corrupted config or something because it was doing some really weird stuff.  Yesterday we upgraded firmware and the problem still persisted.  We zero'd / cleared config and re did the config and it's passing traffic consistently.  

    thanks for the help guys.  i don't think it'll be an issue getting it to talk between pvos and CX.

    ------------------------------
    Killo Richards
    ------------------------------



  • 8.  RE: Migrating from PVOS to AOS-CX & could use some help.

    MVP GURU
    Posted Dec 31, 2021 11:47 AM
    Hi!

    You wrote "Yesterday we upgraded firmware and the problem still persisted. We zero'd / cleared config and re did the config and it's passing traffic consistently."

    That could have been a configuration issue but...what exactly WAS the AOS-CX running software version before the upgrade you did and what IS the AOS-CX software version which is now running?

    I ask that question because - generally - it is a very good practice to start with updating to the latest software build(s) available - consider that ArubaOS-CX is currently developed on its 10.06, 10.07, 10.08 and 10.09 software branches - before any important software configuration.

    That approach is valid also for PVOS (or ArubaOS-Switch) based Switch series; that's to avoid any already known issue and focus on setup a correct running configuration.

    ------------------------------
    Davide Poletto
    ------------------------------



  • 9.  RE: Migrating from PVOS to AOS-CX & could use some help.

    Posted Dec 31, 2021 12:02 PM
    the switches were running 10.05 and we jumped to 10.09

    config is actually really simple its
    vlan 21
    vlan 23
    vlan 100

    int 1/1/1-2/1/48
    vlan trunk native 21
    vlan trunk allow 21,23,100

    My first thought was a problem between CX and Pvos because pings to hosts on vlan 11 through L3 pvos were inconsistent.  could ping a host at x.x.11.4 but not the x.x.11.3 host

    I reviewed the config yesterday and there was nothing in the config on CX that would have caused this.  It was almost like arp table was goofy or something.

    Also sir, i see you recommend interswitch traffic to be tagged, pros and cons?

    im all for doing things better than how they were done to begin with

    ------------------------------
    Killo Richards
    ------------------------------



  • 10.  RE: Migrating from PVOS to AOS-CX & could use some help.

    MVP GURU
    Posted Jan 01, 2022 07:58 AM
    Hello Killo,

    "i see you recommend interswitch traffic to be tagged, pros and cons?"

    I suggested that because - by keeping inter-switch ports only tagged members of VLAN Id(s) you really need to see allowed over them - is a way to avoid that packets belonging to untagged VLAN Id will flow between (untagged) native VLAN Ids of each involved switch and, also, a way to be exactly aware about what VLAN Id(s) really need to explicitly pass through that inter-switch link.

    Just for instance, consider that you can have the default "native" VLAN 1 left on Switch A and the "native" VLAN x set on Switch B as the new native (untagged) VLAN Id, given that...if you leave both inter-switch interfaces as untagged members of - say - respectively VLAN 1 (on Switch A side) and VLAN x (on Switch B side) AND you then configure those inter-switch interfaces to be also tagged members of - say - other VLAN IDs like VLAN y, w, k and z...you will end up with:

    (1) Both switches signalling that there is a mismatch related to inter-switch interfaces' VLAN membership (with regard of associated untagged VLAN on both sides...since you have VLAN 1 on Switch A and VLAN x on Switch B but both are "correctly" untagged)
    (2) Both switches seeing a flow of (potentially undesired) untagged packets despite those packets are really member of different "Native" VLAN Id(s) on each respective side (VLAN 1 on Switch A versus VLAN x on Switch B).

    At that point the only explicitly desired traffic (the one where the VLAN Id(s) - y with y, w with w, k with k and z with z - on both sides are identical) would then be the one related to packets that were allowed to pass by a properly tagged memberships (exactly the traffic of packets tagged with VLAN y, w, k and z IDs on both sides).

    The above is just an example scenario but it happens often than one can imagine because the presence of a "Native" VLAN Id is often forgotten and the main focus is all on the additional tagged VLAN Id(s).

    Sometime the above is instead exactly done on purpose.

    ------------------------------
    Davide Poletto
    ------------------------------



  • 11.  RE: Migrating from PVOS to AOS-CX & could use some help.

    Posted Jan 01, 2022 01:56 PM
    happy new year and thank you sir.

    i think what we will do is do
    trunk vlan native X
    allow x, y, z

    but then on interswitch links do
    allow x, y, z without native 

    if i understand this correctly, suppose i gave an access port that is vlan X native it will be ingress untagged vlan X but when it goes over interswitch it link it will be tagged X.  is this correct?

    it will definitely simplify, improve and tighten up things and make following configs easier.

    also i looked and did not find documentation on the different branches.  oddly i did find another post from you about PVOS branches. 

    https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c02762241


    ------------------------------
    Killo Richards
    ------------------------------



  • 12.  RE: Migrating from PVOS to AOS-CX & could use some help.

    MVP GURU
    Posted Jan 03, 2022 05:21 AM
    Hi Killo,

    I'm not sure to follow your line of reasoning.

    What are you exactly trying to say with the below sentences?

    "i think what we will do is do trunk vlan native X allow x, y, z but then on interswitch links do allow x, y, z without native"

    When you configure a Native VLAN Id by using the trunk vlan native x command on a interface operating in trunk mode (or with the corresponding vlan access x command in case of a interface operating in access mode) and then you configure the allowed VLAN Ids with the additional vlan trunk allowed x, y, z command you can't then write "without native" indeed, IIRC, on AOS-CX operating system based switch series the Native VLAN Id is not (neither automatically nor implicitly) added to the specified VLAN IDs list so if you forget to allow it it will remain denied on that interface: in other words the only way to have packets belonging to Native VLAN Id dropped (not passing) on that particular interface is not allowing that Native VLAN Id (vlan trunk allowed y, z).

    Side note about Native VLAN (or, as it is called, Port VLAN ID or PVID): remember that on PVOS based switch series (and also on AOS-CX operating system based switch series) the Native VLAN Id is the VLAN Id you can set on a logical/physical interface for accepting incoming traffic (input on port) despite the VLAN Tag they could have (or could not have if the traffic is entering is not already tagged) and for sending outgoing traffic (output on port) without the Native VLAN Tag.

    INTERNALLY to the Switch each packet incoming on the above example port is going always to "travel" tagged on that Native VLAN Id (any packet follows this rule) SO, let me say, if you're configuring an access port with the Native VLAN 125 (moving away from the VLAN 1 default), that port is, to use the PVOS jargon, an "untagged member" of that VLAN 125 and incoming packets on that port will internally travel the Switch with the VLAN 125 tag applied to them and they will leave the Switch on that port with VLAN 125 tag stripped away so without that VLAN Tag (in other words those packets leaving the switch on that port are not tagged = untagged).

    To answer your second question: a packet of VLAN 125 could internally flow (switched) toward another port - say we're considering there is another port capable of managing VLAN 125 tag - and leave that particular port as outgoing traffic in two flavors: tagged on VLAN 125 OR untagged on VLAN 125 (with the tag VLAN 125 stripped away = untagged). It's up to you to chose what to do on that very specific port (either it is a port operating in trunk mode or access mode).

    In any case, check the VLAN IDs membership of a AOS-CX interface with the show vlan port <port-id> command (PVOS interface: show vlan port ethernet <port-id> details).

    Back on track: personally for a port operating in trunk mode and used for inter-linking switches, instead of just setting the port operating in trunk mode (carrying more than one VLAN ID) and leaving and allowing the VLAN 125 as the Native VLAN Id for that very port (so outgoing traffic on VLAN 125 will be accepted and VLAN 125 will be stripped away in egressing port) I prefer to explicitly set the VLAN 125 as tagged if possible (or "Native Tagged" as per AOS-CX capability since AOS-CX permits that: you're indeed capable of setting the Native VLAN Id as "tagged" which, from the point of view of PVOS, is a little bit counter intuitive configuration since Native = Untagged as per PVOS jargon) so that that port will send outgoing packets of Native VLAN Id always tagged and accept only incoming tagged packets (clearly if the Native VLAN Id is added to the allowed VLAN IDs).

    ------------------------------
    Davide Poletto
    ------------------------------