8 Replies Latest reply: Mar 1, 2011 11:06 AM by Jeroen RSS

    Enable TX force untag

    Jeroen

      Hi everyone,

       

       

      I'm looking for opinions about what this option does. This pertains a Cisco smart switch and hence the dubious terminology. Please refer to a full description at the bottom of my post.


      "When this option is enabled, all egress frames from this port become untagged"

       

      Egress? As in, a host sends a tagged frame to the ingress port of the switch, and when it egresses from that switch port it will become untagged?

       

      Or

       

      Egress, as in, when a switch receives a tagged frame on a port (ingress), it will remove the tag before it sends the frame to the host (egress).

       

       

       

      A) Suppose the option is enabled:

       

      Possible answer 1:

       

      it is an option that prevents a host from ever sending tagged frames.

       

      Possible answer 2:

       

      it is an option that prevents a host from ever receiving tagged frames.

       

       

       

      B) Suppose the option is disabled:

       

      Possible answer 1:

       

      it is an option that allows a host to send tagged frames (except frames tagged with a VLAN ID equal to the PVID)

       

      Possible answer 2:

       

      It is an option that allows a host to receive tagged frames (except frames tagged with a VLAN ID equal to the PVID)

       

      Many thanks for your thoughts!

       

       

      Enable Tx Force Untag 

      When this option is enabled, all egress frames from this port become untagged. The default value is Disable. When this function is disabled, only frames with the VLAN ID equal to the PVID will become untagged, otherwise, frames are sent with a VLAN tag.

        • 1. Re: Enable TX force untag
          Keith Barker - CCIE RS/Security, CISSP

          Back in 2001, when I went to my first CCIE lab at building C in San Jose, I ate at the cafeteria.

           

          There is a location there, in the cafeteria where we can return the trays, plates, glasses, flatware, etc.   At that location, there were two openings, one said ENTER and the other said EXIT.

           

          Enter, with regards to that opening, means ingress.    Exit, with regards to the other opening, means egress.

           

          Egress are the bits leaving the switchport, heading towards the wire.    Ingress are bits coming in from the wire towards the port.

           

          The feature you are refering to will NOT tag outbound frames (from the switch perspective).

           

          Best wishes,

           

          Keith

          • 2. Re: Enable TX force untag
            Jeroen

            Hi Keith

             

            Perhaps I've overcomplicated my question. When I know the flow of traffic (from a host to the switch or the other way around), I know what ingress and egress means.

             

            I'm more confused of what the goal of this option is. I know a switch will not insert dot1q vlan headers on frames it receives on an access port.

             

            In truth, I don't know what the option does and what I typed up are the possible scenario's that play in my head.

             

            So I'll rephrase, when and why would "Tx force untag" be used?

             

            best regards,

            Jeroen

            • 3. Re: Enable TX force untag
              Keith Barker - CCIE RS/Security, CISSP

              Hello Jeroen.

               

              Normally, egress frames (from the switch perspective) will include the VLAN Tag in the 802.1q header, as the switch places the frame on the wire.

               

              When the switch has a frame that belongs to the native VLAN, it will not tag the frame, but rather simply send it without a tag, and the other side (using the same native VLAN) would understand that the untagged frame belongs to the native VLAN.

               

              Now for your command.

               

              When we use the command Enable Tx force untag, based on the description given for it, a switch will NOT tag any frames, but rather just send them, very similar to the way it sends frames for the native VLAN.

               

              And now for the why.   It was probably a corner case, where someone had a need, and Cisco provided the feature.   Such as a protocol analyzer that didn't have the ability (decades ago) to understand a dot1q header, or something similar, so they wanted the egress switch to not include them.

               

              In normal operations, without the tags, dot1q would be very disfunctional to the downstream switch that receives all the untagged frames, as it would believe they all belong to the native VLAN.

               

              Thanks for the interesting question.   I am happy to supply my opinion.   I am also open to any other input people may have regarding how they would use the untagged option. 

               

              Best wishes,

               

              Keith.

              • 4. Re: Enable TX force untag
                Jeroen

                Keith Barker - CCIE RS/Security, CISSP, CCSI wrote:

                 

                Hello Jeroen.

                 

                Normally, egress frames (from the switch perspective) will include the VLAN Tag in the 802.1q header, as the switch places the frame on the wire.

                 

                When the switch has a frame that belongs to the native VLAN, it will not tag the frame, but rather simply send it without a tag, and the other side (using the same native VLAN) would understand that the untagged frame belongs to the native VLAN.

                 

                I'm sure we are on the same page here, but frames between access ports on the same switch are never tagged, are they? I.E. the switch will never at any point during the frames live insert the DOT1Q header. Only if the frame travels through a trunk to another VLAN-aware device (2 switches in my case), the sending switch will insert a VLAN-header with a VLAN-ID. The receiving switch will then strip the VLAN-header and forward the frame to the correct VLAN based on the ID of the VLAN-header it stripped.

                 

                The only "exception" to this is the native VLAN (probably VLAN-1 on most switches). Both switches will never insert a DOT1Q header for frames received from ports with PVID = 1. To prevent VLAN-hopping, I disallow untagged frames between the trunk ports. I've changed the native VLAN to 100 and not a single access port is in VLAN 100. Only the trunk ports on both switches are in VLAN 100.

                 

                Also, there is only 1 native VLAN? Unless for a port with, for instance, PVID = 5 you could say 5 is its native VLAN. I'm not too sure my last statement is accurate.

                 

                Now for your command.

                 

                When we use the command Enable Tx force untag, based on the description given for it, a switch will NOT tag any frames, but rather just send them, very similar to the way it sends frames for the native VLAN.

                 

                Yes, in case you enable this option on a trunk port it would be pretty unusual for a switch to remove the DOT1Q-header (and it would break the trunk). But I'm wondering what effect this has on an access port. Frames received on an access port should never be tagged, correct?

                Therefore, it looks like when "TX force untag" is disabled, the access port will accept tagged frames except when they are tagged with a VLAN ID equal to the PVID of the port it is receiving the tagged frame on (as that would be pretty pointless).

                 

                And now things get more interesting. When TX force untag is disabled, and ingress filtering disabled, a VLAN-aware device in(lets say)  VLAN-5 could tag its frames with VLAN-ID 20 (again, randomly chosen ID as an example). Normally, an access port should drop tagged frames, but since ingress filtering is disabled, it will happily forward the frame with the VLAN-20 tag to VLAN 20. The switch will (or should?) most likely untag the frame before flooding it to VLAN-20.

                 

                 

                I can't, however, see how the device in VLAN 20 could ever reply unless it tags its frame for VLAN 5.

                 

                Have I just dreamt up a plausible explanation of this feature or is this plain wrong? An access port WILL drop tagged frames period. Tx force untag has nothing to do with it whatsoever. Is it possible for a tagged and untagged VLAN to exist on the same port?

                 

                And now for the why.   It was probably a corner case, where someone had a need, and Cisco provided the feature.   Such as a protocol analyzer that didn't have the ability (decades ago) to understand a dot1q header, or something similar, so they wanted the egress switch to not include them.

                 

                In normal operations, without the tags, dot1q would be very disfunctional to the downstream switch that receives all the untagged frames, as it would believe they all belong to the native VLAN.

                 

                Thanks for the interesting question.   I am happy to supply my opinion.   I am also open to any other input people may have regarding how they would use the untagged option. 

                 

                Best wishes,

                 

                Keith.

                 

                For a trunk port what you say here directly above certainly makes sense.

                May I ask whether you think my explanation is possible?

                 

                I may be able to test certain things:


                I have a laptop that can send tagged frames (thank you Intel NIC's).
                I could thus create VLAN 5 and VLAN 20. Put the laptop in VLAN 5 and put any device capable of responding to ping in VLAN 20. Then I'll send tagged frames with ID=20 from the laptop to the device in VLAN 20.

                 

                If they arrive, I could probably sniff the VLAN 5 port and see the DOT1Q-header, and then sniff the VLAN 20 port and see the frame arrive with the DOT1Q-header stripped. I just need a computer whose NIC passes the VLAN-headers so wireshark can sniff them:).

                 

                Thank you for you patience. Judging from your certs, this stuff mus be pretty easy for you:)

                • 5. Re: Enable TX force untag
                  Keith Barker - CCIE RS/Security, CISSP

                  Yes, frames sent egress on access ports are not sent with tags, so this command would only have an effect on 802.1q tagged frames.

                   

                  What is your application for this?  Do you have a specific function you want to set up?   That may be a better approach to this.

                   

                   

                   

                  Keith

                  • 6. Re: Enable TX force untag
                    Jeroen

                    I want the (switch) management VLAN (VLAN 100) isolated from the VLAN my computers are in (VLAN 10). However, My computer still needs to be able to access the management interface on VLAN 100 regardless of the fact it is in VLAN 10. So if my on my computer supports dot1q tags this might be possible somehow.

                    • 7. Re: Enable TX force untag
                      Keith Barker - CCIE RS/Security, CISSP

                      You don't want to route to your management VLAN, with some access-lists that control who comes in and out of the management VLAN?

                       

                      Keith

                      • 8. Re: Enable TX force untag
                        Jeroen

                        I see your point. At the time I didn't find a good reason to put every VLAN in its own subnet (since my setup is fairly simple) and now that is biting me in the *ss. Another lesson learned here. However, I have a mikrotik router where a VLAN = subinterface and there I can specify access lists. So I'm probably still in the clear.

                         

                        I'll probably test my theory some time but I've got the idea the Cisco switch is stuck on egress filtering enabled and that the option to disable it is not working.

                         

                        Thanks for the interesting session. Testing this will probably reveal any particuliarities the switch has.