- Community Home
- >
- Networking
- >
- Legacy
- >
- Switching and Routing
- >
- Procurve 2626 tagged ports and send/receive to A/P...
Categories
Company
Local Language
Forums
Discussions
Knowledge Base
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2011 01:48 AM
08-05-2011 01:48 AM
Procurve 2626 tagged ports and send/receive to A/P firewall cluster
Hi,
I have a firewall A/P cluster where I am getting some odd errors with mac addresses on a Vlan connected to a HP 2626. The setup is:
Firewall Active/Passive:
A/P cluster vrrp
eth5 is configured with one Vlan, vlan50.
HP 2626:
vlan 50
name "GUEST1"
forbid 1-23
untagged 24
ip address 192.168.50.3 255.255.255.0
tagged 25-26
ip igmp
exit
spanning-tree 24 point-to-point-mac Auto
spanning-tree 25 point-to-point-mac Auto bpdu-filter
spanning-tree 26 point-to-point-mac Auto bpdu-filter
Port 25 is connected to the active firewall and port 26 is connected to the passive firewall.
The switch is running firmware H.10.50.
Whenever there is traffic from the Vlan50 to the firewall cluster I get these kernel errors from my passive cluster firewall (which is not supposed to receive traffic when it is passive state):
kernel eth5.50: received packet with own address as source address
So I did a packet capture on both interface 25 and 26 on the switch and to my surprise I saw traffic on port 26 like ARP, WHOIS, normal traffic ect. which I believe should not be seen as this port is connected to the passive firewall. So my guess is clients respond back to the cluster Arp whois and hits both the active and passive firewall ports and that is why I see the kernel address error.
But looking at my cluster passive eth5 statistics I see:
eth5 Link encap:Ethernet HWaddr 00:00:5E:00:01:08
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34331 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5986991 (5.7 MiB) TX bytes:0 (0.0 B)
Interrupt:16 Memory:feae0000-feb00000
eth5.50 Link encap:Ethernet HWaddr 00:00:5E:00:01:08
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18599 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2863885 (2.7 MiB) TX bytes:0 (0.0 B)
The passive cluster only receive traffic on the eth5 and is not sending any.
Statistics from the switch Vlan50:
MAC Address Located on Port
------------- ---------------
00005e-000108 25
Here I only see the active clusters vrrp MAC address which is expected.
Statistics from the switch port25:
MAC Address
-------------
00005e-000108
Again I see active cluster vrrp MAC address.
Statistics from the switch port26:
MAC Address
-------------
Empty as this is the passive cluster connected here.
I cannot figure out why my switch and connected clients on vlan50 somehow traffic seems to hit both the active firewall and passive firewall?
Is my switch configuration wrong?
How does tagged ports work regarding sending/receiving traffic?
Anyone seen this before?
If I google this error, I can see a lot of articles with the same error on linux kernels with bridge networks, so my first thought was, it is a firewall issue. But my vender says they cannot replicate this error with the same setup on there cluster.
Any good thoughts? Could this be a procurve issue?
Regards
Robert