Ethernet Switching
Highlighted
Ethernet Switching

vlan ingress filtering

[ Edited ]
‎09-20-2018 04:17 AM

Hello guys!
Here is the issue I faced with.
Imagine, we have a ring topology as depicted. Ports ge-0/0/0 and ge-0/0/2 are uplink trunk ports, port ge-0/0/1 - downlink access port.

Vlan-id 100 is the only one vlan that is allowed to pass ports ge-0/0/0 and ge-0/0/1. 
See configuration snippet bellow.

ge-0/0/0 {
        unit 0 {
                  ethernet-switching {
                  port-mode trunk;
                  vlan {
                             members 100;
                }
          }
     }

}

ge-0/0/1 {
        unit 0 {
                   ethernet-switching {
                  port-mode access;
                  vlan {
                             members 100;
                }
           }
      }
}

ge-0/0/2 {
        unit 0 {
                  ethernet-switching {
                  port-mode trunk;
                  vlan {
                             members 200;
                }
          }
     }

}

 

If sw1 receives ingress packet tagged with vlan-id 100 on its ge-0/0/2 port, switch accepts packet and  send it forward regarding to its vlan-table (ge-0/0/0 and ge-0/0/1 accordingly), this leads to forming unidirectional L2 loop.
I heard that there are two types of packet filtering: egress and ingress. I supposed that Juniper switches use ingress filtering, so I expected that received packet tagged with vlan-id 100 on ge-0/0/2 should be dropped. Am I right? Could you tell me where can I find description of such behavior in case if Junipers uses egress vlan filtering scheme?

Thanks a lot in advance.

5 REPLIES 5
Highlighted
Ethernet Switching

Re: vlan ingress filtering

[ Edited ]
‎09-20-2018 04:37 AM

Serg, I thought by your use of topology you would have included some diagram, but I get the picture -Smiley Happy

 

When you set any interface as port-type = trunk, that means it can handle all Q-tagged frames it receives.  None of the received Q-tagged frames will be dropped UNLESS the VLAN ID in the tag was not known by the switch.  Untagged frames are dropped by default, but can be allowed via the use of default-VLAN.

 

What the VLAN 200 membership says is that the interface only sends packets that are associated with VLAN 200, and set with proper tag.

 

Make sense?  I think every switch from every vendor works like this, . . . of should!

Highlighted
Ethernet Switching

Re: vlan ingress filtering

‎09-20-2018 05:26 AM

rccpgm, thank you for reply, I tried to include network diagram twice, but unfortunatelly it was not successful.

We also use cisco switches and extreme summit switches and they do not accept frame if vlan-id 100 is not explicitly allowed on the port. Here we have a situation when switch accepts frame if vlan-id presents in vlan database, no matter whether this vlan-id is allowed on a port or not.

 

Diagram1.png

Highlighted
Ethernet Switching

Re: vlan ingress filtering

‎09-20-2018 05:30 AM

I see diagram now -Smiley Happy

 

Let me do some checking if this behavior is by design or potentially a bug.  OK?

Highlighted
Ethernet Switching

Re: vlan ingress filtering

‎09-20-2018 06:27 AM

It'd be great. I hope this will help the others. By the way, this behavior could be overcomed by using firewall filter that allows exact vlan-ids.

Someting like this:

# show firewall family ethernet-switching
filter ge-0/0/0_ingress_vlans {
      term permit {
                  from {
                               vlan 100;
                  }
                  then accept;
        }
        term end {
                   then discard;
        }
}
filter ge-0/0/2_ingress_vlans {
        term permit {
                    from {
                                vlan 200;
                    }
                     then accept;
        }
        term end {
                    then discard;
        }
}

 

But this is burdensome.

Highlighted
Ethernet Switching

Re: vlan ingress filtering

‎09-20-2018 06:39 AM

I assumed filter would work, and for right now is probably your only option.  Regardless of whether this is expected or non-expected behavior, any change would take time, especially if the answer is expected.  Then Juniper would need to consider enhancement request, which would most likely require a new config 'knob' in order to not break what is out there today.

 

Just FYI.  My suggestion is to go with the filter, place it in a group for easier use.

 

BTW, in 20+ years of dealing with VLANs, your situation is 1st time anyone has asked about this, . . .