At Percona’s web store you can order your MySQL database support needs in minutes. No hassles, no fuss, just pick and click. Pay online with a credit card.
Course Of The Month
Become a Premium Member and unlock a new, free course in leading technologies each month.
Solved
HP v1910 Trunk VLAN
Posted on 2013-06-18
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?
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
6
3
2- +1
12 Comments
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.
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.
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.
Ok - still having issues. I am attaching a copy of the configuration file for one of the switches. Ideas?
Sorry - forgot the attachment on the previous post!
startup.txt
startup.txt
The biggest difference in STP in Cisco and HP is that Cisco by default runs Per-VLAN STP, while HP runs standard STP or RSTP, which is not vlan aware (MSTP would be, but it's overkill in your case).
So STP and RSTP will block your redundant fibers, even if they carry different vlans, ann theoretically couldn't cause a loop.
You can either setup multiple instances in MSTP, or keep your life simple and just go with the suggestion of using aggregated interfaces. Aggregation does provide the redundancy and higher speed you need.
So STP and RSTP will block your redundant fibers, even if they carry different vlans, ann theoretically couldn't cause a loop.
You can either setup multiple instances in MSTP, or keep your life simple and just go with the suggestion of using aggregated interfaces. Aggregation does provide the redundancy and higher speed you need.
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!
Featured Post
Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
This article is a how to to configure a UCS Ethernet-uplink portchannel via
the console.
It is easy to do and can be done quite quickly. In certain versions of the UCS manager the portchannel has issues coming up and this is a workaround.
I am…
Hi there,
This article summarizes what you need if you are going to set up your home or small business Network Attached Storage (NAS) to be accessible from the internet. Of course there are configuration differences based on your NAS or router ma…
This is my first video review of Microsoft Bookings, I will be doing a part two with a bit more information, but wanted to get this out to you folks.
Add bar graphs to Access queries using Unicode block characters. Graphs appear on every record in the color you want. Give life to numbers.
Hopes this gives you ideas on visualizing your data in new ways ~
Create a calculated field in a query:
…
Suggested Courses
Earn Certification
HTML5 Specialist - Certification
Free withPremium
Course of the Month4 days, 7 hours left to enroll
635 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.