Wired Intelligent Edge

Hi Dears!

I've Aruba 2530 48G PoE+ Switch. I need make static route 

On the switch present command ip route "dest address" "mask" "ip address"  It's standard command.

For example on Cisco I make static route the same command, BUT! I write command "no swichport" on the port for change status to L3 mode before assigned ip address on the port.

On the aruba doesn't present "no swichport" and I cannot assign ip address on port. How I can to do it? 

#2530

Hi AlbertYer,

 

Not really sure what you would like to achieve but the 2530 is not a L3 switch. So you cannot create a routed port. You can only set an IP address on a VLAN and put the VLAN untagged on the port. But you cannot set an IP address on a port itself. 

 

And to my knowledge, the 2530 is just a L2 switch and static routes are just for the switch itself. Clients cannot use the switch to be routed to a different network. You would need an external router for that. 

The 2930F, for example, is L3 a switch that can be used as a router. 

Hi Florian!

Also I've Aruba 2930F 48G 4SFP+ Swch.

This switch L3 and also have same problem. I cannot assign IP address on the port. May be need specific command?

Or for static route just one variant. It's make vlan XXX with IP address/30 and assign this vlan on the port like an untagged?

 

For example:

SW1:

vlan 100
ip address 10.10.10.1/30

 

int eth 1
untagged VLAN 100

 

ip route 10.10.10.0 255.255.255.252 vlan 100
or
ip route 10.10.10.0 255.255.255.252 10.10.10.2
or
ip route 10.10.10.0 255.255.255.252 ethernet 1

 

SW2:

vlan 100
ip address 10.10.10.2/30

int eth 2
untagged VLAN 100

 

P.S.

I was on Your website and Youtube channel)

hi AlbertYer,

 

The ArubaOS switches do not support a routed port at all. You can route with them, but only using VLAN interfaces. The config for SW2 is the only working one. 

First, you need to create a VLAN and assign an IP to that VLAN. Afterward, you can assign this VLAN untagged to a port. That is the only way. 

Hi Florian,

Out of curiosity, you wrote:

---

@FlorianBaaske wrote: First, you need to create a VLAN and assign an IP to that VLAN. Afterward, you can assign this VLAN untagged to a port. That is the only way. 

---

Can we also imagine to work (I mean: is it adviseable to do so?) with that "Transit" dedicated port assigned as Tagged only member of that Transit VLAN (on switch side) instead and configure the same also on Router side? I think maybe it more than one Transit VLAN is required ...or simply, since that Transit VLAN would probably be the only one deployed VLAN between the Core Switch and the Router, leave the traffic untagged between them is the usual good way to go?

Actually, I'm not sure if I get the question correct, but you can for sure have the VLAN untagged on the port without any other VLAN's or you can have different tagged VLANs on the port as well. And you can also have the VLAN tagged on the port either as the only VLAN or together with other VLAN's. 

From my point of view, there is no real recommendation if the VLAN should be tagged or not. I think it has more to do with internal rules. I know customers who would never use uplink VLAN untagged, just because to have the rule, that all uplink VLANs are tagged. If it is just one VLAN I think untagged would be the easiest option, because you can then use a routed port on the router without using a VLAN. But that is totally up to you. 

Hi Florian! you get my question correctly...indeed mine was just a "Transit VLAN deployed using tagged or untagged ports on both ends?" doubt...as you suggested...there is no a golden rule to follow...so the important thing is that both ways are, in the end, applicable and a network administrator should evaluate which approach is better (case by case) considering the background networking scenario his/her is dealing with. Thanks!

---

@parnassus wrote:
Hi Florian! you get my question correctly...indeed mine was just a "Transit VLAN deployed using tagged or untagged ports on both ends?" doubt...as you suggested...there is no a golden rule to follow...so the important thing is that both ways are, in the end, applicable and a network administrator should evaluate which approach is better (case by case) considering the background networking scenario his/her is dealing with. Thanks!

---

great summarization.