Comware

I have 2 HP 2530 switches connected together through a trunk. The first switch is connected to a Palo Alto 200 firewall. I created 2 new VLANs on the switches and the PAs, but i cannot ping the firewall DMZ IP from the DMZ VLAN on the switch.

trunk 23 trk1 trunk
trunk 22 trk2 trunk
no telnet-server
ip default-gateway 10.1.15.254
vlan 1
name "DEFAULT_VLAN"
no untagged 3,15,17,19
untagged 1-2,4-14,16,18,20-21,24-28,Trk1-Trk2
ip address dhcp-bootp
exit
vlan 10
name "Data_Network"
tagged Trk1-Trk2
ip address 10.20.70.2 255.255.255.0
exit
vlan 30
name "Test_Network"
tagged Trk1-Trk2
ip address 10.10.70.2 255.255.255.0
exit
vlan 50
name "Mgmt_Network"
tagged Trk1-Trk2
ip address 10.1.70.2 255.255.255.0
exit
vlan 60
name "DMZ_Network"
tagged 3,Trk1-Trk2
ip address 172.17.170.2 255.255.255.0
exit
vlan 70
name "Wifi_Network"
tagged Trk1-Trk2
ip address 10.30.70.2 255.255.255.0
exit
vlan 99
name "Internet"
untagged 15,17,19
tagged Trk1-Trk2
no ip address
exit
spanning-tree
spanning-tree Trk1 priority 4
spanning-tree Trk2 priority 4
no dhcp config-file-update

IP Route Entries

Destination Gateway VLAN Type Sub-Type Metric Dist.
------------------ --------------- ---- --------- ---------- ---------- -----
0.0.0.0/0 10.1.15.254 1 static 250 1
10.1.15.0/24 DEFAULT_VLAN 1 connected 1 0
10.1.70.0/24 Mgmt_Network 50 connected 1 0
10.10.70.0/24 Test_Network 30 connected 1 0
10.20.70.0/24 Data_Network 10 connected 1 0
10.30.70.0/24 Wifi_Network 70 connected 1 0
127.0.0.0/8 reject static 0 0
127.0.0.1/32 connected 1 0
172.17.170.0/24 DMZ_Network 60 connected 1 0

Switch can ping DMZ IP

Trace-route from the firewall:

traceroute host 172.17.170.2
traceroute to 172.17.170.2 (172.17.170.2), 30 hops max, 40 byte packets
1 10.1.15.254 (10.1.15.254) 0.568 ms 0.752 ms 0.989 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *

---

@ae10 wrote:
trunk 23 trk1 trunk

trunk 22 trk2 trunk

There is something strange in your conception of "trunk"...it looks like a little bit Cisco biased.

Trunk...in HP/HPE/Aruba jargon (specifically in HP ProVision/Aruba ArubaOS-Switch network operating systems jargon...the OS your two HP/Aruba 2530 are running on)...means Port Aggregation (Cisco EtherChannel)...not VLAN trunking.

So with:

trunk 23 trk1 trunk
trunk 22 trk2 trunk

you're just configuring 2 Port Aggregations (respectively trk1 and trk2), each one, respectively composed by just one port in static mode (trunk=non protocol=static...which, in other terms, mean you're not going to bond member interfaces of the trunk using a dynamic protocol like LACP)...so port 23 is part of trk1 and port 22 is part of trk2. Both trk1 and trk2 are logical interfaces against which you would set tagging/untagging (untagged/tagged VLAN memberships will propagate automatically down to trunks' member interfaces...so you should not worry about that).

Now the interesting part: setting a Port Aggregation with just one port is somewhat very strange...possible but really strange...so, what you want to achieve? what is your topology? who is connect to what? in which port? who is responsible for performing VLAN IP routing (The Palo Alto or one of your two HP 2530)?

Thanks parnassus. 

Unfortunately, I inherited this from another guy and it's in another office, so it's really hard to manage. Also, I have never dealt with HP switches before. I don't know why only one port is part of the trunk.

I want the PA to handle the VLANs IP routing...

Trunk1 (port 23) is connected to the PA...and port 22 (TRK2) is connected to the other switch....I have routes configured on the PA, but I cannot ping 172.17.170.2 from the PA...tracert stops @ 10.1.15.254

# show vlan

Status and Counters - VLAN Information

Maximum VLANs to support : 256
Primary VLAN : DEFAULT_VLAN
Management VLAN :

VLAN ID Name | Status Voice Jumbo
------- -------------------------------- + ---------- ----- -----
1 DEFAULT_VLAN | Port-based No No
10 Data_Network | Port-based No No
30 Test_Network | Port-based No No
50 Mgmt_Network | Port-based No No
60 DMZ_Network | Port-based No No
70 Wifi_Network | Port-based No No
99 Internet | Port-based No No

# show ip route

IP Route Entries

Destination Gateway VLAN Type Sub-Type Metric Dist.
------------------ --------------- ---- --------- ---------- ---------- -----
0.0.0.0/0 10.1.15.254 1 static 250 1
10.1.15.0/24 DEFAULT_VLAN 1 connected 1 0
10.1.70.0/24 Mgmt_Network 50 connected 1 0
10.10.70.0/24 Test_Network 30 connected 1 0
10.20.70.0/24 Data_Network 10 connected 1 0
10.30.70.0/24 Wifi_Network 70 connected 1 0
127.0.0.0/8 reject static 0 0
127.0.0.1/32 connected 1 0
172.17.170.0/24 DMZ_Network 60 connected 1 0

# show trunks

Load Balancing Method: L3-based (Default), L2-based if non-IP traffic

Port | Name Type | Group Type
---- + -------------------------------- --------- + ----- --------
22 | 100/1000T | Trk2 Trunk
23 | 100/1000T | Trk1 Trunk

I have Cisco 2960 switches in other offices...I have similar setup, and everything is working fine . Please see below (thought this might be helpful to understand what i am trying to achive)

interface Vlan1
no ip address
no ip route-cache
shutdown
!
interface Vlan10
ip address 10.20.2.2 255.255.255.0
ip helper-address 10.1.2.11
ip helper-address 10.1.12.45
no ip route-cache
!
interface Vlan30
ip address 10.10.2.2 255.255.255.0
ip helper-address 10.1.12.45
no ip route-cache
!
interface Vlan50
ip address 10.1.2.2 255.255.255.0
ip helper-address 10.1.12.45
no ip route-cache
!
interface Vlan60
ip address 172.17.102.2 255.255.255.0
ip helper-address 10.1.12.45
ip helper-address 10.1.2.11
no ip route-cache
!
ip default-gateway 10.1.2.1
ip http server
ip http secure-server

interface GigabitEthernet1/0/1
switchport mode trunk
channel-group 1 mode active
!

interface GigabitEthernet1/0/2
switchport mode trunk
channel-group 1 mode active

Please let me know if you need more information. 

First strange thing: with regard to the Cisco example you provided for other offices with similar setup - where all is OK - VLAN tagging/untagging can't be seen...so hard to tell you how Cisco trunked (AKA permitted VLANs passing on one interface...this in Cisco jargon) VLANs to related firewall and to downlinked other switch (there are two ports trunked 1/0/1 and 1/0/2)...so I can't do a 1:1 comparison to see how you setup...apart from that I'll concentrate on the HP scenario you're dealing with.

Probably you have:

Palo Alto firewall LAN port <---> port 22 (trk1) HP 2530-1 (trk2) port 23 <---> port x HP 2530-2

On HP-2530-1 port 3 there is a tag for VLAN 60 "DMZ_Network" (172.17.170.0/24 VLAN IP is 172.17.170.2) so I imagine that on port 3 there is something connected related to DMZ Network and that device is set to pass traffic TAGGED in VLAN 3 (so it understand VLAN tagging), probably a Server or a Switch setup accordingly.

On HP-2530-1 trk1 (port 22) and trk2 (port 23) are tagged on every VLAN you defined on the HP and are untagged member of VLAN 1...so I suspect that you are using both ports to transport those VLANs to Palo Alto and to the other HP Switch...which port do what you know, I just supposed that port 22 goes to Palo Alto and the other goes to the other HP...but it could be the contrary (it doesn't matter)...this means that trk1 and trk2 transport all your VLANs somewhere. Good.

Since IP routing is NOT enabled I then suspect that Palo Alto does IP routing for your setup...so its LAN port (facing the HP-2530-1 in my supposed topology) need to (a) be untagged in VLAN 1 (with compatible IP Addressing) and, concurrently, (b) be tagged for any VLAN you're trasporting to it (with compatible IP Addressing on each VLAN).

I then suspect that, since the Palo Alto is the default gateway for your network, then the 10.1.15.254 is its LAN port IP Address...but...in which VLAN? VLAN 99 or VLAN 1?

Looking at VLAN 99 I see ports 15, 17 and 19 untagged members of VLAN 99...so probably those are clients.

Looking at VLAN 1 I see ports 1-2, 4-14, 16, 18, 20, 21, 24-28, Trk1 and Trk2 as untagged members of VLAN 1...so I suspect that you're using that default gateway on VLAN 1 and so that IP addressing is valid for VLAN 1 (on HP and on Palo Alto LAN VLAN 1).

Now, if my picture is OK, this means that a client connected to, as example, on port 1 with an IP Address compatible with 10.1.15.254 (/24?) should ping your Palo Alto if its default gateway is set with 10.1.15.254 (which is the Palo Alto). Is this right?

Since you haven't on that HP access ports (for client hosts) on other VLANs than the VLAN 1, VLAN 60 and VLAN 99 then a step further would be test ping from port 3 (see above) or 15, 17, 19 (see above)...since VLAN 60 and VLAN 99 are transported (permitted) on trk1 (port 22) then a client on one of those ports (with the right client IP addressing) should be able to ping directly the Palo Alto IP Address(es) associated to the VLAN where the client is (and if the Palo Alto firewall inter-VLAN routing is configured accordingly also other VLAN IP address space). Does this happen?

Thanks again. Here are the answers to your questions:

1. Port 3 on switch 1: I added this port to DMZ VLAN and tried to connect a host to see if I can ping the gateway from it.
2. Port 22 on switch 1 is connected to a patch panel. We couldn’t trace it!.
3. Port 23 on switch1 is connected to the PA firewall (please see the diagram).
4. I couldn’t run the command : IP routing on the HP switches. Command is not available (it could be a version issue. Current version is: YA.15.10.0003).
5. PA is the default gateway for the network (10.1.15.254) and it’s tagged as VLAN50 on the PA.
6. You can ignore VLAN 99 and its ports (Legacy stuff!).
7. Yes, Default gateway is used in VLAN 1.
8. Clients that are on 10.1.15.0/24 subnet can ping the default gateway and have network access
9. I connected a device to port 3 and I couldn’t ping 172.17.170.1 which is the default gateway for VLAN 60. I tried to tag the port and un-tag it with no luck.
10. Trace-route to 172.17.170.2 from the firewall stops at 10.1.15.254.
11. Switch 2 VLAN 60 IP is 172.17.170.3. I cannot ping 172.17.170.2 from switch 2 and vice versa.
12. discovered that we have an HP ProCurve 1400 which is unmanaged and it’s connected to the firewall and switch 2. Please see the diagram.

I am not sure how to upload an image to this forums

Gosh, forget about step 4 on HP 2530: 2530 Switch series doesn't support IP Routing...no Layer 3 features! I forget that...it's a Layer 2 managed Switch, not a Layer 3 (lite) one...

I need to recap...since HP 2530 can't perform any IP Routing feature...it's a matter of understanding exactly your topology (an image would help) and read carefully what you wrote about 2530.

To upload press "Photos" icon (Insert Photos) and follow instructions.

i am pretty sure the issue is because the firewall interface is connected to the unmanaged switch...thoughts? 

Well, the unmanaged HP ProCurve 1400 doesn't support VLAN Tagging so it is unaware of any other VLAN tagging applied to traffic egressing the port of other Switch it is connected to...in other terms if port 23 of the HP 2530-24G Switch 2 (connected to port 23 of the unmanaged) carries multiple VLANs then only the untagged one it is recognized...that's because an unmanaged Switch is just a VLAN-unaware up/down-link to an untagged port assigned to a VLAN on a managed Switch...and so you're just not going to be able to carry tagged (trunked in Cisco jargon) traffic of multiple VLANs to that unmanaged Switch.

Clearly things get weird if the Port 23 of Switch 2 carries tagged traffic (it's a trunk port in Cisco terminology)...since the unamanaged is VLAN unaware it could discard or not tagged traffic (802.1Q frames).

At this point I will leave it out of the equation beacuse, if deployed, it should just be an extension of Port 23 Untagged VLAN of Switch 2.

Don't know why the unmanaged Switch is uplinked to Palo Alto port 3 via its Port 19 and to Palo Alto port MGT via its port 18...

In my head the Palo Alto port 4 is the interface on which you are tagging all required VLANs (apart leaving VLAN 1 untagged) and so Port 23 of Switch 1 should be configured to be untagged member on VLAN 1 and tagged member of all remaining VLANs (the same on Ports 24 on both Switch 1 and Switch 2 if Switch 2 is an extension of Switch 1)...doing things that way and letting the PA to be the router then you just require to set required access ports on Switch 1 and 2 to belong to desired VLANs to let them speak to PA (that will become their Default Gateway)...this becasue 2530 switches can't perform any IP routing service.

I will remove/get rid of trk1 and trk2 on HP 2530 switches and just define port 23 and port 24 as untagged members of VLAN 1 and tagged members of all the VLANs you have defined on PA's Port 4...that's essential to let Switch 1 to transport all VLANs to PA Firewall...then I will do the same for port 24 of Switch 2...to let Switch 1 and 2 to transport all VLANs each others.

On Switch 1 HP 2530:

vlan 1
untagged 23,24
vlan 10
tagged 23,24
vlan 30
tagged 23,24
vlan 50
tagged 23,24
vlan 60
tagged 23,24
vlan 70
tagged 23,24

On Swithc 2 HP 2530:

vlan 1
untagged 24
vlan 10
tagged 24
vlan 30
tagged 24
vlan 50
tagged 24
vlan 60
tagged 24
vlan 70
tagged 24

VLAN IDs defined on Switch 1 and 2 should clearly match and they should match with those on PA firewall (that's pretty clear).

At that point an host connected to an access port member of (so to a port untagged on) VLAN x either on Switch 1 or on Switch 2 should be able to ping:

• IP Address of VLAN x defined on PA firewall (directly via port 23 SW-1 <--> port 4 PA if on SW-1 or indirectly if on SW-2)
• IP Address of VLAN x defined on Switch 1
• IP Address of VLAN x defined on Switch 2
• any other host's IP Address belonging to the same subnet if that host is connected to an access port member of the same VLAN.
• If PA is doing routing correctly between any VLANs then that host should be able to ping (if Access rules on PA permit that) any other host or IP of any other VLAN.

Personally, if not disruptive for your operation, I would temporarily disconnect Port 3 and MGT of PA and Port 23 of SW-2 (downlink to HP 1400)...to test scenario proposed...then I'll plan how to reconnect them correctly (that is, depending on their pourposes).

As expected, the unmanaged switch was cauaing all the issues.. Thank you very much for your help.