WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!
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?
-
6
3
2- +1
12 Comments
Active today
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.
Active today
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
Join Director of Product Management Todd OBoyle on April 26th as he covers the key elements of a phishing protection program. Whether you’re an old hat at phishing education or considering starting a program -- we'll discuss critical components that should be in any program.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
This tutorial will go through the steps required to write a script that will back up the configuration settings of a HP-ProCurve switch.
You will need to get the following things to follow this tutorial:
Telnet Scripting Tool e.g. TST10.exe
…
I eventually solved a perplexing problem setting up telnet for a new switch. I installed a new Cisco WS-03560X-24P switch connected to an existing Cisco 4506 running a WS-X4013-10GE Sup II-Plus.
After configuring vlans and trunking, I could no…
To export Lotus Notes to Outlook PST or Exchange and Domino Server files to Exchange Server or PST files with ease, go for Kernel for Lotus Notes to Outlook conversion tool. Through the video, you can watch the conversion process. A common user with…
Watch the video which demonstrates the easy migration process from GroupWise to Outlook with the help of Kernel Novell GroupWise to Outlook software. User can export single or multiple mailboxes either by Online mode or via Command line mode with ea…
Suggested Courses
Course of the Month5 days, 7 hours left to enroll
569 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.