michaelh60
asked on
HP v1910 Trunk VLAN
Experts -
I currently have 2 HP v1910-24g switches that need to pass traffic to each other. Each switch has 3 VLANS (identically configured). The VLAN details are:
VLAN 1:
Port 1 and Port 18 (Port 18 on SFP connected to other v1910 via separate fiber connection)
Assigned ip: 10.1.1.251 (switch A) and 10.1.1.252 (switch B).
VLAN 10:
Port 7 and Port 19 (Port 19 on SFP connected to other v1910 via separate fiber connection)
Assigned ip: 10.1.10.251 (switch A) and 10.1.10.252 (switch B).
VLAN 20:
Port 10 and Port 20 (Port 20 on SFP connected to other v1910 via separate fiber connection)
Assigned ip: 10.1.20.251 (switch A) and 10.1.20.252 (switch B).
Devices connected to port 1 on VLAN 1 can communicate with each other over the "bridge."
However, devices connected on the other mentioned VLANS cannot communicate, nor ping, tracert etc.
I am new to these HP switches and am unsure how to proceed in order to enable communication.
Ideas?
I currently have 2 HP v1910-24g switches that need to pass traffic to each other. Each switch has 3 VLANS (identically configured). The VLAN details are:
VLAN 1:
Port 1 and Port 18 (Port 18 on SFP connected to other v1910 via separate fiber connection)
Assigned ip: 10.1.1.251 (switch A) and 10.1.1.252 (switch B).
VLAN 10:
Port 7 and Port 19 (Port 19 on SFP connected to other v1910 via separate fiber connection)
Assigned ip: 10.1.10.251 (switch A) and 10.1.10.252 (switch B).
VLAN 20:
Port 10 and Port 20 (Port 20 on SFP connected to other v1910 via separate fiber connection)
Assigned ip: 10.1.20.251 (switch A) and 10.1.20.252 (switch B).
Devices connected to port 1 on VLAN 1 can communicate with each other over the "bridge."
However, devices connected on the other mentioned VLANS cannot communicate, nor ping, tracert etc.
I am new to these HP switches and am unsure how to proceed in order to enable communication.
Ideas?
TimotiSt
Just to make sure I understand: the 2 switches are connected by 3 fiber connections?
ok, i haven't used HP switches before but will try to get you in the right direction.
First I want to make sure I understand the problem. So is the problem that hosts within the same VLAN can't communicate at all or just to the other hosts within the same VLAN on the other switch. Or is it that you can't get hosts in one VLAN to talk to hosts in the other VLAN (I'm thinking this one if you're doing traceroute tests).
Here is how vlans should work.
1) There is a thing called a "native vlan". This vlan is what the switches assume a frame to be in when it is "untagged". Some switches allows a port to be considered untagged for any vlan and then all other vlans aren't even configured for that port. That is fine. That means the port is an access port and assigned to the vlan you configured as "untagged" for the port.
2) If you have one vlan on a port be untagged and other vlans on the same port be tagged, the untagged vlan is considered the "native vlan" for what is now a trunk port and the rest are tagged vlans. Tagged vlans on ports only really need to be there on the trunk port
2) hosts within a vlan need to have a default gateway. that default gateway needs to be a layer 3 device. Something capable of routing. If you do not have a router in your network that possesses an interface in each vlan then you can't route packets between the vlans, it doesn't matter what you configure the switch to do. You may have a layer 3 switch but then you still need to configure the routing to be enabled I'm guessing on it. A switch with an IP can be considered to be equal to a host really. Its just there so you can manage it and is why you normally don't have more than a single IP configured on a switch at all; you manage it via the IP on the management subnet, not make it available from multiple vlans opening the "attack surface".
First I want to make sure I understand the problem. So is the problem that hosts within the same VLAN can't communicate at all or just to the other hosts within the same VLAN on the other switch. Or is it that you can't get hosts in one VLAN to talk to hosts in the other VLAN (I'm thinking this one if you're doing traceroute tests).
Here is how vlans should work.
1) There is a thing called a "native vlan". This vlan is what the switches assume a frame to be in when it is "untagged". Some switches allows a port to be considered untagged for any vlan and then all other vlans aren't even configured for that port. That is fine. That means the port is an access port and assigned to the vlan you configured as "untagged" for the port.
2) If you have one vlan on a port be untagged and other vlans on the same port be tagged, the untagged vlan is considered the "native vlan" for what is now a trunk port and the rest are tagged vlans. Tagged vlans on ports only really need to be there on the trunk port
2) hosts within a vlan need to have a default gateway. that default gateway needs to be a layer 3 device. Something capable of routing. If you do not have a router in your network that possesses an interface in each vlan then you can't route packets between the vlans, it doesn't matter what you configure the switch to do. You may have a layer 3 switch but then you still need to configure the routing to be enabled I'm guessing on it. A switch with an IP can be considered to be equal to a host really. Its just there so you can manage it and is why you normally don't have more than a single IP configured on a switch at all; you manage it via the IP on the management subnet, not make it available from multiple vlans opening the "attack surface".
You need to tag each port that is connecting to another switch with the relative VLAN. Technically you do not need a fiber connections for each VLAN between two switches, but it does give you redundancy in case of a fiber break.
Normally this would be done with one fiber connection and then you tag VLAN 1, 10 and 20 to the port that is connected to the other switch. You have to tag the connecting ports exactly the same on both switches.
If you can post a "show run" from your CLI on each switch, it would be easier to troubleshoot.
Normally this would be done with one fiber connection and then you tag VLAN 1, 10 and 20 to the port that is connected to the other switch. You have to tag the connecting ports exactly the same on both switches.
If you can post a "show run" from your CLI on each switch, it would be easier to troubleshoot.
ASKER
In answer to TimotiSt -
Yes - they are two switches connected via 3 fiber connections. We have a high need for redundancy on our fiber connections.
Yes - they are two switches connected via 3 fiber connections. We have a high need for redundancy on our fiber connections.
In that case STP is most likely blocking 2 out of 3 connections, so the vlans don't go through.
For a nice and redundant configuration, what you can do is:
- define Link aggregation (either static or LACP) with 2 (or 3, but that's not really recommended) ports;
- assigned vlans as tagged to this aggregated link.
That'll give you increased bandwidth, redundancy, and it'll carry all vlans across. Routing between the vlans is a separate issue; the V1910 is a "light layer3" switch, so it can route between connected subnets and can have static routes.
For a nice and redundant configuration, what you can do is:
- define Link aggregation (either static or LACP) with 2 (or 3, but that's not really recommended) ports;
- assigned vlans as tagged to this aggregated link.
That'll give you increased bandwidth, redundancy, and it'll carry all vlans across. Routing between the vlans is a separate issue; the V1910 is a "light layer3" switch, so it can route between connected subnets and can have static routes.
just a side note, if you don't already do it, I would recommend using link aggregation on those 3 fiber connections. Removes potential STP issues, simplifies configuration, and potentially increases bandwidth for hosts between switches.
:) was beaten to this note. I'm a slow typist I guess.
:) was beaten to this note. I'm a slow typist I guess.
ASKER
I reconfigured the switches to reflect the proper VLAN tags for the respective ports. No luck in getting them to communicate. I've tested the physical fiber links and they are all good. I will examine the STP configuration for potential issues there. As I am new to HP switches and their STP, are there any "lingo translations" I need to be aware of? Thanks.
We may test the solution using link aggregation, but it is not our first choice. One of our subnets/fiber links is for VOIP traffic and we want a completely separate fiber channel for that.
We may test the solution using link aggregation, but it is not our first choice. One of our subnets/fiber links is for VOIP traffic and we want a completely separate fiber channel for that.
ASKER
Ok - still having issues. I am attaching a copy of the configuration file for one of the switches. Ideas?
ASKER
Sorry - forgot the attachment on the previous post!
startup.txt
startup.txt
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
TimotiSt -
I ended up creating multiple instances in MSTP for our links and applying them to the ports used to connect the two switches together. I am able to ping both sides of the link. It looks like the trunk lines are working now.
I am awarding you the 500 points for your assistance which i heartily thank you for!
I ended up creating multiple instances in MSTP for our links and applying them to the ports used to connect the two switches together. I am able to ping both sides of the link. It looks like the trunk lines are working now.
I am awarding you the 500 points for your assistance which i heartily thank you for!
ASKER
Thank you to everyone who contributed!