Aruba & ProVision-based
1753902 Members
9491 Online
108810 Solutions
New Discussion

Assistance with VLAN Traffic Flow Through ProCurve 5402zl

 
SOLVED
Go to solution
iglablues
Occasional Contributor

Assistance with VLAN Traffic Flow Through ProCurve 5402zl

Hi, 

 

I'm trying to understand how VLANs will affect the traffic flow through my network. We're moving from using Cisco Nexus switches to a ProCurve 5402zl as the core. IP routing is enabled, but it will not have a public IP and will eseentially act as a layer 2 device between the ISP and our load balancer (and eventually our Cisco ASA 5505). 

 

Here's the configuration right now:

 

HP Diagram

 

Ports B21 and B23 are the uplinks to our ISP and untagged for V200. The trunked ports go to our load balancer: Trunks 1 and 2 specifically to the one in this discussion (3 and 4 go to a failover LB) so we'll only be referencing Trunks 1 and 2. For reasons I won't go into, the LB doesn't have a VLAN 1 so it uses V1000 as the internal network. The LB also doesn't do trunking so it has two aggregated ports per vlan, which means that even though the HP links are carrying multipe vlans, the other side of the link is only tagged or untagged for one vlan. The LB sits in front of a cluster of web servers that have a public IP, let's say 1.1.1.1. 

 

Here's how I understand the flow of traffic when a client on the internet requests a web page from us:

-Client url DNS lookup resolves to 1.1.1.1

-HTTP request is sent to 1.1.1.2, the ISP router

-the ISP router arps for the device that has that IP. The arp is received on the untagged V200 port on the HP (let's say B21 cuz B23 is not active), thus associating the frame with v200. 

-the HP sees that it doesn't know the network in question and continues forwarding the frame out all of its ports that are members of an untagged vlan, including ports belonging to Trunks 1 and 2 to the LB. VLAN 200 is untagged on both trunks. 

-the LB drops the frames from Trunk 2 because its connected ports are only tagged for V1000. It accepts the frames from Trunk 1 because those connected ports are untagged v200, so at this point the frames become associated with vlan 200 again. It sees that it has the IP the router is looking for and responds to the router back out ports 1-2 (attached to Trunk 1), still untagged for V200. Dst mac is the router now. 

-HP receives this frame on Trunk 1which is set untagged for V1. That means the ARP response from the LB goes from V200 back to V1.

-Now the HP has a frame destined for the router, coming in on a port assigned to V1. It's not going to flood now because it has a mac table entry for the router, but the entry is associated with a port with pvid 200. That means that technically the frame should be dropped and outbound traffic to the router doesn't get through.

 

It does. How? My theories:

 

-by default (according to a document I read called "Understanding VLANs by Understand MAC Table Operation") when 802.1Q-capable switches look in their mac tables, they only look for entries matching the pvid of the received frame. So in this case, the HP would only look for entries matching VLAN 1. Once it didn't find that entry, it supposedly treats it as a broadcast and floods out its untagged ports again, which would mean it would get to the router. This seems contrary to the whole idea of segregating broadcast traffic though. 

 

-or, because IP routing is enabled, it just looks through the mac table and send it out the port to the router despite being on a different vlan because it knows how to do that.

 

Can someone confirm/explain/deny this? I'd really appreciate it. 

 

Thanks!

 

 

5 REPLIES 5
Fredrik Lönnman
Honored Contributor

Re: Assistance with VLAN Traffic Flow Through ProCurve 5402zl

If I understand you correctly, both of your two scenarios are wrong. Basically, the LB needs to have vlan 200 tagged sinces its tagged from the HP Core.

---
CCIE Service Provider
MASE Network Infrastructure [2011]
H3CSE
CCNP R&S

iglablues
Occasional Contributor

Re: Assistance with VLAN Traffic Flow Through ProCurve 5402zl

Okay, I rechecked my setup and you're right, I had the tagging/untagging on the LB swapped. VLAN 1000 is untagged on ports 3 and 4, and VLAN 200 is tagged on ports 1 and 2. 

 

So, the HP received untagged frames from the router, but since they come in on ports untagged for VLAN 200, they become part of VLAN 200. The destination mac is still a broadcast address, so the HP sends it out all of the ports associated with VLAN 200, regardless of whether they're tagged or untagged, which means it sends it out all of the ports connected to the LB. Then the LB receives them, but only accepts them on the ports that it is tagged for V200, ports 1 and 2. It responds to the ARP request with its own mac address since it's proxy-arping for the physical servers behind it, and that reply goes back out interfaces 1 and 2 (trunked) because that's where the source mac was registered. The HP gets this tagged frame back, and now it needs to send the frames back out its uplink port to the router. Those ports are still untagged though. How does the HP manage then to send a tagged frame out an untagged port? The Advanced Traffic Management Guide says:

 

Inbound Tagged Packets: If a tagged packet arrives on a port that is not
a tagged member of the VLAN indicated by the packet’s VID, the switch
drops the packet. Similarly, the switch will drop an inbound, tagged packet
if the receiving port is an untagged member of the VLAN indicated by the
packet’s VID.

 

Thanks in advance for helping me work through this. 

Fredrik Lönnman
Honored Contributor
Solution

Re: Assistance with VLAN Traffic Flow Through ProCurve 5402zl

 

How does the HP manage then to send a tagged frame out an untagged port?


It wont.  The reply will be sent untagged to the ISP. An untagged/access port means that the VLAN tag will be popped on egress and pushed on ingress.

 

---
CCIE Service Provider
MASE Network Infrastructure [2011]
H3CSE
CCNP R&S

iglablues
Occasional Contributor

Re: Assistance with VLAN Traffic Flow Through ProCurve 5402zl

So the rule I quoted above, in which it states that a tagged frame destined for a port that is an untagged member of the vlan, applies to external packets ingressing the switch, and not for the internal forwarding actions of the switch (i.e. forwarding from one port to another inside the switch itself)? 

Fredrik Lönnman
Honored Contributor

Re: Assistance with VLAN Traffic Flow Through ProCurve 5402zl

Yes the quote is about packets ingressing a switchport, not the internal forwarding.
---
CCIE Service Provider
MASE Network Infrastructure [2011]
H3CSE
CCNP R&S