Drag to reposition cover

Brocade ICX Series (cheap & powerful 10gbE/40gbE switching)

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

fohdeesha

Kaini Industries
Nov 20, 2016
2,727
3,075
113
33
fohdeesha.com
How do I do "this" ? ...... Brocade 6450 ........ I would like to set up Brocade 6450's Port 20 to be a port that only has LAN access but no WAN access. So that way, whatever I plug in there will be on the LAN, but cannot have any internet access.

Is this possible?
with the help of a stranger on the internet, anything is possible

Code:
enable
conf t

##create a new ip ACL called nowan

ip access-list extended nowan

#start adding rules, in this order. Order of these commands matters!
#this assumes your local subnet is 192.168.1.0/24 & the drac IP is 192.168.1.199
#replace the IP in each command with the IP of your drac

#only allow traffic FROM drac IP if it's to local subnet
permit ip host 192.168.1.199 192.168.1.0/24
deny ip host 192.168.1.199 any

##only allow traffic TO drac IP if it's from local subnet
permit ip 192.168.1.0/24 host 192.168.1.199
deny ip any host 192.168.1.199

#finally, let everything else through as normal and exit ACL config
permit ip any any
exit

#apply the rule list to the VE 1 interface, in the inbound direction (from the pov of the VE int)
int ve 1
ip access-group nowan in
exit
write mem
You should now still be able to access your DRAC from local machines in the same subnet, but the DRAC can't talk to the internet, and the internet can't talk to it.

In an ACL list, packets come into the switch, and it attempts to match the packet to rules in the list one by one, starting at the top. The first rule it matches, it does what that rules says (allow or deny)

In the ACL rule entry, the first ip/host is the packet source, and the second is the packet destination.

So let's say your DRAC tries to ping a local machine of 192.168.1.5. The switch will start trying to match it in our list of rules, starting at the top:

Code:
 (action)          (source)     (destination)
 permit ip host 192.168.1.199 192.168.1.0/24
 deny ip host 192.168.1.199 any
 permit ip 192.168.1.0/24 host 192.168.1.199
 deny ip any host 192.168.1.199
 permit ip any any

the first rule matches any packet with a source of 192.168.1.199 (the drac IP) and a destination of any IP in the subnet (like the 192.168.1.5 you're pinging), so the packet gets matched to this first rule. The rule is a "permit" so the switch lets the traffic through

Now let's say the DRAC tries to ping an internet IP of 8.8.8.8 - it won't match the first rule, because the destination of the packet is outside the specified subnet. It will however get matched to the second rule, because the packet SOURCE is still the DRAC IP, and now the packet destination of 8.8.8.8 matches the "destination any" of the second rule. This rule is a deny, so the packet gets dropped.

The next 2 rules are essentially the same, but blocking traffic in the other direction - external IP's trying to get to the DRAC

Finally, for regular traffic, it won't match any of the first 4 rules because it does not have a destination or source of the DRAC IP, so it matches the last rule, which is a permit

The "ip access-group nowan in" applies that list to the VE 1 interface on the IN direction - you can also apply ACL's to interfaces on outbound, but depending on your ACL rule types, they might need to be flipped around, since the VE will now be matching traffic from it's outbound point of view. It's typically best practice to do what you can to keep ACL's on inbound only - for a few reasons, a big one being the packets get dropped before they make the ASIC work to do forwarding & routing lookups, etc. This doesn't matter at all in typical applications, but if you start to push the linerate of an ASIC it can start to save a little capacity. As long as all your traffic is going through the VE (or whatever interface) in one way or another, you can usually accomplish whatever you need on inbound only
 
Last edited:

tommybackeast

Active Member
Jun 10, 2018
286
105
43
with the help of a stranger on the internet, anything is possible

Code:
enable
conf t

##create a new ip ACL called nowan

ip access-list extended nowan

#start adding rules, in this order. Order of these commands matters!
#this assumes your local subnet is 192.168.1.0/24 & the drac IP is 192.168.1.199
#replace the IP in each command with the IP of your drac

#only allow traffic FROM drac IP if it's to local subnet
permit ip host 192.168.1.199 192.168.1.0/24
deny ip host 192.168.1.199 any

##only allow traffic TO drac IP if it's from local subnet
permit ip 192.168.1.0/24 host 192.168.1.199
deny ip any host 192.168.1.199

#finally, let everything else through as normal and exit ACL config
permit ip any any
exit

#apply the rule list to the VE 1 interface, in the inbound direction (from the pov of the VE int)
int ve 1
ip access-group nowan in
exit
write mem
You should now still be able to access your DRAC from local machines in the same subnet, but the DRAC can't talk to the internet, and the internet can't talk to it.

In an ACL list, packets come into the switch, and it attempts to match the packet to rules in the list one by one, starting at the top. The first rule it matches, it does what that rules says (allow or deny)

In the ACL rule entry, the first ip/host is the packet source, and the second is the packet destination.

So let's say your DRAC tries to ping a local machine of 192.168.1.5. The switch will start trying to match it in our list of rules, starting at the top:

Code:
 (action)          (source)     (destination)
 permit ip host 192.168.1.199 192.168.1.0/24
 deny ip host 192.168.1.199 any
 permit ip 192.168.1.0/24 host 192.168.1.199
 deny ip any host 192.168.1.199
 permit ip any any

the first rule matches any packet with a source of 192.168.1.199 (the drac IP) and a destination of any IP in the subnet (like the 192.168.1.5 you're pinging), so the packet gets matched to this first rule. The rule is a "permit" so the switch lets the traffic through

Now let's say the DRAC tries to ping an internet IP of 8.8.8.8 - it won't match the first rule, because the destination of the packet is outside the specified subnet. It will however get matched to the second rule, because the packet SOURCE is still the DRAC IP, and now the packet destination of 8.8.8.8 matches the "destination any" of the second rule. This rule is a deny, so the packet gets dropped.

The next 2 rules are essentially the same, but blocking traffic in the other direction - external IP's trying to get to the DRAC

Finally, for regular traffic, it won't match any of the first 4 rules because it does not have a destination or source of the DRAC IP, so it matches the last rule, which is a permit

The "ip access-group nowan in" applies that list to the VE 1 interface on the IN direction - you can also apply ACL's to interfaces on outbound, but depending on your ACL rule types, they might need to be flipped around, since the VE will now be matching traffic from it's outbound point of view. It's typically best practice to do what you can to keep ACL's on inbound only - for a few reasons, a big one being the packets get dropped before they make the ASIC work to do forwarding & routing lookups, etc. This doesn't matter at all in typical applications, but if you start to push the linerate of an ASIC it can start to save a little capacity. As long as all your traffic is going through the VE (or whatever interface) in one way or another, you can usually accomplish whatever you need on inbound only

wonderful, thank you SO much

so given Halloween is coming up,
should we call you Count DRACula the rest of the month?
 
  • Like
Reactions: fohdeesha

tommybackeast

Active Member
Jun 10, 2018
286
105
43
with the help of a stranger on the internet, anything is possible

Code:
enable
conf t

##create a new ip ACL called nowan

ip access-list extended nowan

#start adding rules, in this order. Order of these commands matters!
#this assumes your local subnet is 192.168.1.0/24 & the drac IP is 192.168.1.199
#replace the IP in each command with the IP of your drac

#only allow traffic FROM drac IP if it's to local subnet
permit ip host 192.168.1.199 192.168.1.0/24
deny ip host 192.168.1.199 any

##only allow traffic TO drac IP if it's from local subnet
permit ip 192.168.1.0/24 host 192.168.1.199
deny ip any host 192.168.1.199

#finally, let everything else through as normal and exit ACL config
permit ip any any
exit

#apply the rule list to the VE 1 interface, in the inbound direction (from the pov of the VE int)
int ve 1
ip access-group nowan in
exit
write mem
You should now still be able to access your DRAC from local machines in the same subnet, but the DRAC can't talk to the internet, and the internet can't talk to it.

In an ACL list, packets come into the switch, and it attempts to match the packet to rules in the list one by one, starting at the top. The first rule it matches, it does what that rules says (allow or deny)

In the ACL rule entry, the first ip/host is the packet source, and the second is the packet destination.

So let's say your DRAC tries to ping a local machine of 192.168.1.5. The switch will start trying to match it in our list of rules, starting at the top:

Code:
 (action)          (source)     (destination)
 permit ip host 192.168.1.199 192.168.1.0/24
 deny ip host 192.168.1.199 any
 permit ip 192.168.1.0/24 host 192.168.1.199
 deny ip any host 192.168.1.199
 permit ip any any

the first rule matches any packet with a source of 192.168.1.199 (the drac IP) and a destination of any IP in the subnet (like the 192.168.1.5 you're pinging), so the packet gets matched to this first rule. The rule is a "permit" so the switch lets the traffic through

Now let's say the DRAC tries to ping an internet IP of 8.8.8.8 - it won't match the first rule, because the destination of the packet is outside the specified subnet. It will however get matched to the second rule, because the packet SOURCE is still the DRAC IP, and now the packet destination of 8.8.8.8 matches the "destination any" of the second rule. This rule is a deny, so the packet gets dropped.

The next 2 rules are essentially the same, but blocking traffic in the other direction - external IP's trying to get to the DRAC

Finally, for regular traffic, it won't match any of the first 4 rules because it does not have a destination or source of the DRAC IP, so it matches the last rule, which is a permit

The "ip access-group nowan in" applies that list to the VE 1 interface on the IN direction - you can also apply ACL's to interfaces on outbound, but depending on your ACL rule types, they might need to be flipped around, since the VE will now be matching traffic from it's outbound point of view. It's typically best practice to do what you can to keep ACL's on inbound only - for a few reasons, a big one being the packets get dropped before they make the ASIC work to do forwarding & routing lookups, etc. This doesn't matter at all in typical applications, but if you start to push the linerate of an ASIC it can start to save a little capacity. As long as all your traffic is going through the VE (or whatever interface) in one way or another, you can usually accomplish whatever you need on inbound only
In the interest of my learning.
Your command

#only allow traffic FROM drac IP if it's to local subnet
permit ip host 192.168.1.199 192.168.1.0/24
deny ip host 192.168.1.199 any

if that was flipped to

#only allow traffic FROM drac IP if it's to local subnet
deny ip host 192.168.1.199 any
permit ip host 192.168.1.199 192.168.1.0/24

This was completely block ANY and all access to port 192.168.1.199, either LAN or WAN.
correct?
 

fohdeesha

Kaini Industries
Nov 20, 2016
2,727
3,075
113
33
fohdeesha.com
I also just realized you asked about blocking WAN access based on things plugged into port 20, not based on IP. However in a past message you mentioned it was to block DRAC internet access. the IP based method I gave above is a little neater in application as it will block the DRAC from getting out to the internet regardless of where it's plugged in, as long as it retains the same IP.

if you would like to actually block anything on physical port 20 from getting out to the internet, that's also possible, but it requires creating and applying the ACL a little differently
 

fohdeesha

Kaini Industries
Nov 20, 2016
2,727
3,075
113
33
fohdeesha.com
In the interest of my learning.
Your command

#only allow traffic FROM drac IP if it's to local subnet
permit ip host 192.168.1.199 192.168.1.0/24
deny ip host 192.168.1.199 any

if that was flipped to

#only allow traffic FROM drac IP if it's to local subnet
deny ip host 192.168.1.199 any
permit ip host 192.168.1.199 192.168.1.0/24

This was completely block ANY and all access to port 192.168.1.199, either LAN or WAN.
correct?
exactly- however only in the direction of the drac OUT to anything else

traffic can still get TO the drac (since the packets will be from other devices, they won't get matched on the "source: 192.168.1.199" part of the rule). To totally block that too, you would just flip the source and destination:

deny ip any host 192.168.1.199

There's also an implied "deny everything" invisible rule at the end of ACL's, this is why we need the permit ip any any rule at the bottom to let everything else through so it gets matched before it hits the implied deny everything rule

I forgot to add a note, when you do all this, do not "write mem" until you've tested that you still have internet and local LAN access as expected - if you screw up the order and block all LAN traffic or something, you can then just reboot the switch and all those changes will be gone since you didn't save them
 
  • Like
Reactions: Etaber

tommybackeast

Active Member
Jun 10, 2018
286
105
43
with the help of a stranger on the internet, anything is possible

Code:
enable
conf t

##create a new ip ACL called nowan

ip access-list extended nowan

#start adding rules, in this order. Order of these commands matters!
#this assumes your local subnet is 192.168.1.0/24 & the drac IP is 192.168.1.199
#replace the IP in each command with the IP of your drac

#only allow traffic FROM drac IP if it's to local subnet
permit ip host 192.168.1.199 192.168.1.0/24
deny ip host 192.168.1.199 any

##only allow traffic TO drac IP if it's from local subnet
permit ip 192.168.1.0/24 host 192.168.1.199
deny ip any host 192.168.1.199

#finally, let everything else through as normal and exit ACL config
permit ip any any
exit

#apply the rule list to the VE 1 interface, in the inbound direction (from the pov of the VE int)
int ve 1
ip access-group nowan in
exit
write mem
You should now still be able to access your DRAC from local machines in the same subnet, but the DRAC can't talk to the internet, and the internet can't talk to it.

In an ACL list, packets come into the switch, and it attempts to match the packet to rules in the list one by one, starting at the top. The first rule it matches, it does what that rules says (allow or deny)

In the ACL rule entry, the first ip/host is the packet source, and the second is the packet destination.

So let's say your DRAC tries to ping a local machine of 192.168.1.5. The switch will start trying to match it in our list of rules, starting at the top:

Code:
 (action)          (source)     (destination)
 permit ip host 192.168.1.199 192.168.1.0/24
 deny ip host 192.168.1.199 any
 permit ip 192.168.1.0/24 host 192.168.1.199
 deny ip any host 192.168.1.199
 permit ip any any

the first rule matches any packet with a source of 192.168.1.199 (the drac IP) and a destination of any IP in the subnet (like the 192.168.1.5 you're pinging), so the packet gets matched to this first rule. The rule is a "permit" so the switch lets the traffic through

Now let's say the DRAC tries to ping an internet IP of 8.8.8.8 - it won't match the first rule, because the destination of the packet is outside the specified subnet. It will however get matched to the second rule, because the packet SOURCE is still the DRAC IP, and now the packet destination of 8.8.8.8 matches the "destination any" of the second rule. This rule is a deny, so the packet gets dropped.

The next 2 rules are essentially the same, but blocking traffic in the other direction - external IP's trying to get to the DRAC

Finally, for regular traffic, it won't match any of the first 4 rules because it does not have a destination or source of the DRAC IP, so it matches the last rule, which is a permit

The "ip access-group nowan in" applies that list to the VE 1 interface on the IN direction - you can also apply ACL's to interfaces on outbound, but depending on your ACL rule types, they might need to be flipped around, since the VE will now be matching traffic from it's outbound point of view. It's typically best practice to do what you can to keep ACL's on inbound only - for a few reasons, a big one being the packets get dropped before they make the ASIC work to do forwarding & routing lookups, etc. This doesn't matter at all in typical applications, but if you start to push the linerate of an ASIC it can start to save a little capacity. As long as all your traffic is going through the VE (or whatever interface) in one way or another, you can usually accomplish whatever you need on inbound only
First, my compliments for your method of explaining complex (well complex to me) network concepts. I could not have written the code you did, but following along it does make sense.

Second, I just realized a possible flaw in my plan :( if I am on 2nd floor office using iDRAC 7 Enterprise to access the Dell Server in basement; and I call out to LifeCycle for any updates (to call home to Dell); does LifeCycle using the iDRAC port/ip;

or will LifeCycle call home to Dell using one of the two 1GB RJ45connections on the Server's NIC card.
 
  • Like
Reactions: Emanuele

tommybackeast

Active Member
Jun 10, 2018
286
105
43
I also just realized you asked about blocking WAN access based on things plugged into port 20, not based on IP. However in a past message you mentioned it was to block DRAC internet access. the IP based method I gave above is a little neater in application as it will block the DRAC from getting out to the internet regardless of where it's plugged in, as long as it retains the same IP.

if you would like to actually block anything on physical port 20 from getting out to the internet, that's also possible, but it requires creating and applying the ACL a little differently
I appreciate I asked two different "How To" questions; similar but different. You have now answered my iDRAC security question; but my other question, while similiar is different. I would like to on the Brocade 6450 Port 20 block ALL Wan but allow all LAN (I use 192.168.1.0/24). This way, any device I plug into Port 20, I know will be LAN only access; and not WAN.

Thank you
 

tommybackeast

Active Member
Jun 10, 2018
286
105
43
I forgot to add a note, when you do all this, do not "write mem" until you've tested that you still have internet and local LAN access as expected - if you screw up the order and block all LAN traffic or something, you can then just reboot the switch and all those changes will be gone since you didn't save them
Thank you, very logical.

A public thank you for all your help as well as your iDRAC recent work. I needed to buy some PDUs; and was doing research here on STH; and a trusted user suggested a brand I had not heard in year, Lantronix. Small company making quality products. so I bought a bunch; as I needed several.

May I send you one with my compliments? https://www.lantronix.com/wp-content/uploads/pdf/SLP_PB.pdf

on bottom lower left of page 2 of the above pdf is tiny pix of the unit I'd like to send you.

Lantronix SLPH0811E-02

Has RJ45 port for Network Management, LED for displaying amps drawn on the PDU

Easy to reset to Factory via Paper Clip into reset hole for 10 seconds.
https://www.lantronix.com/products/lantronix-slp-816/

The 8port I have to send you has Rack Ears; and is in mint shape.

I know you enjoy tinkering with gear....
 

ljvb

Member
Nov 8, 2015
97
32
18
47
Arista QSFP-SR4 40GBASE-SR4 Tranceiver QSFP-40G-SR4
for $18.08

It is used, is that a decent price?
 

ljvb

Member
Nov 8, 2015
97
32
18
47
right now I want to murder mine.. cannot figure out why my vlans are not working.. config below editing out access/auth
What is working, I can ping ve1 no problem, anywhere from the network, I cannot ping ve30 (I have not setup static routes on my other devices yet so that is to be expected) . I currently have pfsense running with 4 interfaces, 2 in a lag connected to my older SG300-20 (passing around 8 different vlans, non poe, I'll find a use for it elsewhere), 1 to the FIOS ONT, and 1 I connected to the 6610 port 1

Connected to port 24 (nothing on 23 I just did not want the vlan to clear when I way playing with port 24 settings), is the intel card assigned to a Freebsd VM (via vmdirectpath). I manually set the ip of 192.168.16.10 and a gateway of 192.168.16.1, but no traffic is passing, no pinging, no nothing.. I had a conference call to get onto before I had the chance to bust out my tcpdump skills (I an an IT Security/Pentester by trade.. I am however not a network admin.... concepts I know well.. implementation.. not so much) . Ultimately I am going to move each vlan over 1 at a time as to not interrupt my wifes internet (this would not end well for me as she is working from home), but right now I am just making sure I can route one machine onto the internet first.

Code:
Current configuration:
!
vlan 1 name DEFAULT-VLAN by port
 router-interface ve 1
!
vlan 30 by port
 tagged ethe 1/1/23 to 1/1/24 
 router-interface ve 30
!
!
hostname coreswitch
!
ip dhcp-client disable
ip dns server-address 1.1.1.1
ip route 0.0.0.0/0 192.168.16.1
!
no telnet server
username admin password .....
!
clock timezone us Eastern
!
ntp
disable serve
 server 155.94.164.121
!
interface ve 1
 port-name "PFSense uplink"
 ip address 192.168.16.2 255.255.255.0
!
interface ve 30
 ip address 192.168.30.1 255.255.255.0
end
 

fohdeesha

Kaini Industries
Nov 20, 2016
2,727
3,075
113
33
fohdeesha.com
you have the port 23 device configured with a subnet of 192.168.16.0 with a GW of 192.168.16.1 - but that port is in vlan 30, who's VE IP/subnet is 192.168.30.1 - how in the world would that work?

if you want to do inter-vlan routing, you need to either do it on the switch, or in pfsense, trying to do it on both at once will make a crazy mess. It sounds like pfsense already has all the vlans and routing configured on it, so the switch does not need multiple VE's (that is only needed for routing between the subnets on the switch itself). Just one VE with an IP for management access is all you need
 

u238

Member
Aug 11, 2018
40
10
8
Does anyone know of a source for rack ears that fit the 6450? One of mine got wrecked in shipping. I was able to salvage the chassis with some persuasion with a hammer, but the rack is is pretty bad.
 

kapone

Well-Known Member
May 23, 2015
1,095
642
113
The way I configured mine with pfSense was...to disconnect pfsense from it first. It's a layer 3 switch...you don't need pfSense to do the routing. I set up my VLANs, gateway IPs, ACLs, etc etc on the switch first and confirmed that they are working as expected. The IP address space I used on the switch was 192.168.x.x

Once everything was working, I created the "transit" VLAN with one of the 10g ports on the 6610 (my pfsense has a 10g nic in it as well, which is the interface connected to the 6610). On the switch side the IP address of that VLAN was 172.16.0.1, and on the pfSense side the IP address was 172.16.0.2. (new Gateway under System-->Routing). The default route on the switch points to 172.16.0.2

Now, all traffic can reach pfSense (that is not routed internally by the switch), but pfSense does not know how to send this traffic back. So..create a Static route on the pfSense end (under System-->routing-->static routes) where the destination "network" is 192.168.x.x and uses the 172.16.0.2 gateway defined above.

Now pfSense is happily talking to the switch and vice versa.

Now under pfSense go to Firewall rules and knock yourself out if you want to control on the pfsense end or go into the switch ACLs for the switch side.
 

ljvb

Member
Nov 8, 2015
97
32
18
47
you have the port 23 device configured with a subnet of 192.168.16.0 with a GW of 192.168.16.1 - but that port is in vlan 30, who's VE IP/subnet is 192.168.30.1 - how in the world would that work?

if you want to do inter-vlan routing, you need to either do it on the switch, or in pfsense, trying to do it on both at once will make a crazy mess. It sounds like pfsense already has all the vlans and routing configured on it, so the switch does not need multiple VE's (that is only needed for routing between the subnets on the switch itself). Just one VE with an IP for management access is all you need
There is nothing on 1/1/23, it's just tagged on vlan 30. I may have gone overboard editing out the white space when I copied and pasted it over. I can just as easily remove that.

I am migrating away from using pfsense for routing, whenever I play around or make changes to it the entire network craps out.

I will go the route someone else noted and remove pfsense altogethor and set things up.
 

ljvb

Member
Nov 8, 2015
97
32
18
47
I'm very familiar with pfsense. The issue I appear to be having, and not sure whether it's me or the switch..

I erased the config.. and started over, with nothing other than 1 cable connected (I changed 24 to 11 just in case there is a port problem).
That cable is connected to a laptop, just to avoid seeing if the VM with a physical interface assigned was the problem.

configurations I ran.

create vlan30
tag e 1/1/11
router-interface ve 30
int ve 30
ip address 192.168.30.1/24

I then wrote the config.

I plugged the laptop into port 1/1/11 and manually configured the IP (this is my work windows machine) of 192.168.30.2 and gateway 192.168.30.1

I attempted to ping 30.1 from the laptop, no joy, same goes for trying to ping 30.2 from the switch.

Then for shits and giggles, I connected port 1 back to the pfsense box and ran the following
int e 1/1/1
ip address 192.168.16.2/24
exit
ip route 0.0.0.0/0 192.168.16.1/24
wr mem


What am I doing wrong.. I have watched a ton of videos, they all show the same process to create vlans . Right now I am not concerned about the return traffic from the network, I just want to get a handle on vlans within the icx.. I'm probably missing something stupid too.. I did swap the cables as well

edit : I am able to ping 16.2 from anywhere on my network, and I did setup a static route for 30.0/24 and the traceroute/ping loops and dies at 192.168.16.1 but at least it's going in the right direction
 
Last edited:

fohdeesha

Kaini Industries
Nov 20, 2016
2,727
3,075
113
33
fohdeesha.com
you're adding the port to the vlan as tagged, as in the device on the other end needs to be properly adding a vlan tag to packets, and properly accepting tagged packets. I sincerely doubt you configured this on your windows laptop - if you're not messing with setting up tags on the end device, you need to add the port to the vlan as UNtagged

Code:
enable
conf t
vlan 30
no tag e 1/1/11
untag e 1/1/11
enjoy your pingpongbingbong
 

ljvb

Member
Nov 8, 2015
97
32
18
47
you're adding the port to the vlan as tagged, as in the device on the other end needs to be properly adding a vlan tag to packets, and properly accepting tagged packets. I sincerely doubt you configured this on your windows laptop - if you're not messing with setting up tags on the end device, you need to add the port to the vlan as UNtagged

Code:
enable
conf t
vlan 30
no tag e 1/1/11
untag e 1/1/11
enjoy your pingpongbingbong
Same result, even untagged (I had tried it both ways. Ultimately the majority of the ports will be tag as they are trunks from distributed switches (vmware switches, does the ICX require specific commands for trunking, or does it do it automatically, on my cisco boxes I have to specify trunk)