Comware

Still learning here so please bear with me on what might seem a simple question.

Let's say I have a pair 2910al's linked with 10gbps fiber, and on each I have the following:

VLAN1 - 192.168.1.0/24 (connected to production LAN)
VLAN100 - 192.168.100.0/24
VLAN200 - 192.168.200.0/24
VLAN300 - 192.168.300.0/24

The 10gbps fiber would tag VLAN's 1,100,200,300.

I want to be able to route from VLAN100 TO my production LAN.

I also want to be able to route FROM my production VLAN to VLAN100 from specific IP addresses to any IP and port on VLAN100.

Can I do this easily, and if so how please?

I'm finding myself drowning a little in hundreds of pages of manuals.

Thanks ever so much.

2 things:
1) turn on routing, but doing so allows any vlans with IP addresses assigned and the clients on those vlans using that switch vlan IP addr as their gateway, will be able to get to each other.
2) so, you'll want to implement some ACLs to control traffic flow.

example ACL to your note:

1) create ASE's:

ip access-list 100 permit 192.168.1.x 0.0.0.0 192.168.100.0 0.0.0.255
ip access-list 100 deny 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
ip access-list 100 deny 192.168.300.0 0.0.0.255 192.168.100.0 0.0.0.255
ip access-list 100 permit any any (optional, there is implicit deny at end of ACEs)

2) apply ACL to vlan100:

switch(vlan-100)# ip access-group 100 in

this example ACL may not fully provide all access or deny specific access as you need, it is simply an example.

get this doc if you don't have it already (2910 ACL portion):

http://cdn.procurve.com/training/Manuals/2910-ASG-Feb09-9-ACLs.pdf

Get this CLI ref guide, it shows how to configure HP ProVision, HP Comware5 and Cisco switches for lots of different functions, in a side-by-side comparison, so if you know one CLI, you see how to do it in a different CLI:

http://h10144.www1.hp.com/docs/training/HP-Networking-and-Cisco-CLI-Reference-Guide_June_10_WW_Eng_ltr.pdf

you may not need the other CLI info, but it has alot of good basic, plain speak of how to do "stuff".

hth...Jeff

Thanks, had been reading http://cdn.procurve.com/training/Manuals/2910-ASG-Feb09-9-ACLs.pdf but it's a lot to digest, I think I'm a little clearer.

So let's say on my main LANs core switch I have a route for 192.168.100.0/24 that has 192.168.1.1 as its next hop, the traffic comes into the 2910 on a port in VLAN1 that's connected to my main LAN.

I have "ip routing" enabled.

I create an ACE (did you mean ACE or ASE as I can't see any reference to that?) of:

ip access-list 100 (or iSCSI or whatever name I choose) permit 192.168.1.x 0.0.0.0 192.168.100.0 0.0.0.255
ip access-list 100 permit 192.168.1.y 0.0.0.0 192.168.100.0 0.0.0.255
ip access-list 100 permit 192.168.1.z 0.0.0.0 192.168.100.0 0.0.0.255

With x,y,z being the machines on my main LAN that I want to have access, an implicit deny blocks everything else.

Then:

vlan 100
ip access-group 100 in

And this will only allow 192.168.1.x/y/z to route through to 192.168.100.0?

Thanks.

Paul asked:

"(did you mean ACE or ASE as I can't see any reference to that?)"

yes, my bad...ACE - Access Control Entry

"And this will only allow 192.168.1.x/y/z to route through to 192.168.100.0?"

yes, for vlan 100

hth...Jeff

Cool, thank you very much.

Is "outbound" traffic from VLAN100 "stateful" i.e. if I create an ACL for inbound traffic to VLAN100, if devices on VLAN100 initiate outbound connections (DNS/NTP/SMTP) to other VLANs will the responses be accepted so long as routes are in place?

Paul asked:
"Is "outbound" traffic from VLAN100 "stateful" i.e. if I create an ACL for inbound traffic to VLAN100, if devices on VLAN100 initiate outbound connections (DNS/NTP/SMTP) to other VLANs will the responses be accepted so long as routes are in place?"

Yes :-)

Excellent.

I've been doing some reading on routing/redundancy (tied to my earlier stacking/management question).

Let's say I have two 2910's connected by a 10gbps fiber that tags VLAN's 1, 100, 200, 300.

VLAN1 on Switch A is assigned 192.168.1.1 and VLAN2 on Switch B is assigned 192.168.1.2.

If VLAN1 of each switch is connected to my main LAN, I basically have two routes into VLAN1, 100, 200, 300.

AFAIK there's no way on my main LAN switch (5406zl) to configure 2 routes is there?

Ideally I want the route to use 192.168.1.1 and fall back to 192.168.1.2 if Switch A is down.

I suspect I'm asking too much :-)

(The context here is a basic vSphere "stretch cluster" with an iSCSI SAN on VLAN100 that ideally should be manageable from the main LAN).

Ah bugger, just thought about it and it won't work as the devices on VLAN100 (or whichever VLAN) will only have a single default gateway which may not return traffic to the interface it came in on.

Paul said:
"Ah bugger, just thought about it and it won't work as the devices on VLAN100 (or whichever VLAN) will only have a single default gateway which may not return traffic to the interface it came in on."

Yep, that's why you would want VRRP. But we've been through that too :-)

What ARE we doing, working through this in a Sat ;-) ;-)

Thanks Jeff, much clearer now (Saturday or Sunday!).

One final thing is about loops/STP.

I've attached a very rough diagram of the proposed config.

The intention is simply that the LAN "cloud" and below is our existing LAN (a flat network no VLANs) and above the cloud is the new kit.

You'll see that by having the two 2910's connected to the existing LAN I'll have an L2 network loop that I'm assuming stp/rstp on the Procurve's will sort out?

We already run RSTP on our core Procurve's on our main LAN though I'm by no means an expert on it.

I'm not planning on tagging VLAN 1 between the switches and I know it's considered bad practise to use VLAN 1 however our main LAN is just "dumb and flat" right now.

Really I only need the two 2910's connected to the primary LAN so I can manage the switches themselves and iSCSI kit on VLAN 100 - still debating whether it wouldn't be simpler just to stick a firewall in front of one of the switches and use that as a gateway in/out.

Paul said:
"You'll see that by having the two 2910's connected to the existing LAN I'll have an L2 network loop that I'm assuming stp/rstp on the Procurve's will sort out?

We already run RSTP on our core Procurve's on our main LAN though I'm by no means an expert on it."

RSTP is the default level of STP that the 2910's should come up to...depends on version of code, they may have upgraded to MSTP, but if you don't configure MSTP, then it operates as simple RSTP.

HOWEVER, spanning tree is NOT generally enabled by default, you must do a 'span' to enable it on each switch.

The other primary thing to do is define which switch is the root and which is the backup root. (Jeff's best practice)

Decide which switch you want to be the Layer2 root (generally the router or close to it) and do a 'span pri 0', and then decide which switch should be the backup root and do 'span pri 1'.

The default priority setting in ProVision is 8 (actually 8*4k, so its 32768, which is the standard).

Refer to the CLI guide ch 18.

Can't remember if I mentioned the CLI Ref Guide, get it, makes things a bit easier if you just want to config things.

Get this CLI ref guide, it shows how to configure HP ProVision, HP Comware5 and Cisco switches for lots of different functions, in a side-by-side comparison, so if you know one CLI, you see how to do it in a different CLI:
http://h10144.www1.hp.com/docs/training/HP-Networking-and-Cisco-CLI-Reference-Guide_June_10_WW_Eng_ltr.pdf

hth...Jeff

Thanks Jeff, that CLI guide is useful but not so much for the side by side as I'm not a Cisco person either - more a GUI person with CLI when I have to :-)

I know we're running RSTP/STP on the two core 5406zl's that we have as well as on some other old Baystack's and assorted switches - right now our root bridge appears to be an old Baystack that I think is only root by virtue of having the lowest MAC, it certainly isn't by design and my intention is that when I have a window I want to make the gateway 5406 the root bridge, and the second 5406 the backup.

The LAN isn't supposed to be my responsibility but I seem to keep noticing these things and it gets a little awkward trying to cajole those who should be doing it, into doing it so I seem to end up learning little by little and doing it myself.

Happy to help...

I kinda figured the CLI Guide may not be the big help, it is sometimes a bit easier to do stuff without having to slog through the big manuals :-)

A note, the 5400 by default comes up to MSTP when spanning tree is enabled. Of course it can be "rev'd" back to RSTP, and it's ok to do (I suspect that's probably what was done to be fully compatible with those Baystacks.)

Cheers...Jeff

Ha I was just reading about MSTP as I was finding myself thinking "What if there's a route between switches that is more efficient BUT the VLAN in question isn't tagged on those ports?" - but I think you've headed me off at the pass with pointing out RSTP defaults to MSTP.

I think "Plan A" is to walk before I run and just get the VLAN's setup and test they work within the switches, then link them and tag the link, and then make sure the VLAN's work over the link, and then uplink each switch to the main LAN and check I still have a network :-)

I'm hoping that as with most things it's all in the planning, and if I've got that right the implementation should be much more pleasant.

Paul said:
"I'm hoping that as with most things it's all in the planning, and if I've got that right the implementation should be much more pleasant."

Aw come on now, plan ahead, isn't that like reading the manuals before turning it on - hahahahahaha!

I have been accused for years of ready-fire-aim...

Regardless, don't tell folks how easy this all is or everyone will want to do it, and then the "guru status" gets lost.

I hope it goes well for you, sounds like you are VERY close to it!!!!

Bangers and Mash on me mate!

Jeff, up and running albeit early days/testing/staging phase.

The switch management is on VLAN1 (not ideal but as I said we don't use VLAN's on the main LAN right now).

One thing I noticed is that VLAN1 "DEFAULT_VLAN" seems to be the default untagged VLAN on all ports.

On the ports that I *only* want to use in tagged mode, is there any disadvantage to simply using the "forbid" option to stop them being members of VLAN1 for untagged?

It seems daft putting them in a bogus VLAN for untagged traffic?

Paul said:
"It seems daft putting them in a bogus VLAN for untagged traffic?"

My best practice is to NEVER use VLAN1 for ANYTHING.

Next to that, then I create a "no-use" VLAN and put all ports untagged into there, then move them to using VLANs when I need them.

Either way, I believe it is the better way to control the use of ports.

Cheers...Jeff

Makes sense, as I eluded to earlier, at some point I want to get our main LAN onto VLAN's, for now there's an element of fire fighting I guess.

A "no-use" VLAN sounds sensible tbh - the main thing is I don't want the default VLAN spanning those two switches via the 10gbps trunk.

Thanks,
Paul

btw, you can also reassign which VLAN is the "default-vlan"...you may want to create the "no-use-vlan" and assign it to be the "default-vlan" ????

btw2, as long as you don't assign the 10G ports tagged or untagged into VLAN1 on both sides, VLAN1 is isolated across that link.

btw3, a port has to have a home, whether it is untagged into a VLAN or tagged into a VLAN, it just has to have a home.

hth...Jeff