Trunking Help

[doubleH]

Hello Friends,

I am going to be upgrading our network equipment from a 3M 100fx solution to an HP 100/1000tx solution. I haven't done this before and am somewhat familiar with switching concepts, but definitely not and expert and need some help. I have a few questions towards the bottom of this post. Please feel free to also provide suggestions or point out misconfiguration. I've provided a few diagrams as well as a very basic configuration of the switches to help toubleshoot.

----------------------
Environment
----------------------
20 Servers
120 workstations
22 network printers

----------------------
Current Setup (3M Switches)
----------------------
See attached file "Network Topology - Switches 3m.gif" As you can see currently it is a hodge podge of equipment that my predecessor setup. Basically everything is a member of the default vlan 1.


----------------------
New Setup (HP Switches)
----------------------
See attached file "Network Topology - Switches Hp.gif". I am able put workstations on each core, different VLANS and can ping back and fourth so it appears the trunks are working properly between the core. I can also put my test DHCP server on the core and it hands out leases to the different VLANS properly as well.

----------------------
Questions
----------------------
1. Once I connect a cable from CORE_1 port A3 to Edge_1 port 21 I cannot ping the ip address for VLAN 1 on Edge_1 whch is 192.168.71.3. Even if I put a workstation on Edge_1 port 1 (member of VLAN 5) with a static ip address, I cannot ping anything on either core. I've tried enabling ip routing on Edge_1, but that still didn't work.

2. Should I enable jumbo packets? Sounds like something that I should use. All servers will be running 1000T and about 50% of the workstations have 100/1000T nics. Jsut want to make sure it won't impact other devices that aren't running 1000T.

Thanks!

[Matt Hobbs · Accepted solution]

It looks like you don't have your trunks configured quite right. Trunks in ProCurve land are simply aggregated ports.

From your network map, it looks like you want a 4 port trunk between the two Core switches, and from each a 2 port trunk going to Edge_1.

To configure this, you should set something like this on the core switches:

trunk a1-a4 trk1
trunk b1-b2 trk2

On the edge switch:

trunk 21-22 trk1
trunk 22-23 trk2

So the core switches will connect to each other on ports a1-a4, and ports b1-b2 will connect to 21-22 and 22-23. The trunk numbering trk1, trk2, etc, is unimportant.

You will need to enable 'spanning-tree' on all 3 switches, and you should set 'spanning-tree pri 1' on Core1, and pri 2 on Core2.

You should then tag all trunks for all VLANs (except maybe VLAN 1, it's up to you).

That should do the trick. Also K.11.33 is now out so I'd recommend you udpate to that firmware.

Matt

[doubleH]

Thanks Matt for the quick response! I really appreciate it. I can now put a workstation on Edge_1, port 1 (Vlan 5) and ping devices on Core_1.

Questions
-----------
1. I cannot ping the ip address (192.168.71.3) of VLAN 1 on Edge_1 from devices attached to either of the cores or the edge. Do you have any ideas?

2. When assigning ports to the trunk 1 (connecting the cores together) i decided to split up the trunks across different modules (a1,a2,b1,b2 vs. a1-a4) in case a module fails. Is there any reason why in your answer you said to put them on the same module?


3. Should I enable jumbo packets? Sounds like something that I should use. All servers will be running 1000T and about 50% of the workstations have 100/1000T nics. Just want to make sure it won't impact other devices that aren't running 1000T.

4. Now that spanning tree is enabled..if I connect the hp switches to my existing 3M switches will spanning tree cause any issues?

5. "You should then tag all trunks for all VLANs (except maybe VLAN 1, it's up to you)"
Is there reasons why I should not do this?

[Matt Hobbs]

A1. You need to set 'ip default-gateway 192.168.71.1' to allow that address to be pingable from other VLANs.

A2. It's best to do your trunks as you have suggested for that exact reason. I just suggested that because it was the easiest to type :)

A3. Jumbo frames, for now I wouldn't enable them. There are some caveats that you need to understand. From my understanding, all devices on the network need to support Jumbo frames as the switch will not fragment them back down to 1522 bytes if required for a device that does not support Jumbo frames. If you haven't done so already read through that chapter in the manual, in particular the section 'Operating Notes for Jumbo Traffic-Handling'.

A4. In theory it should be okay to connect to 3M switches. Only one way to find out.. .

A5. When using multiple VLANs with spanning-tree, you should create all VLANs on all switches, even if there are going to be no ports in a particular VLAN on a given switch. The reason for this is for a failover situation. In your example, if the 4 port trunk between the two core switches failed, then only traffic for VLANs 1 and 5 would be able to reach each core since it would be going via the Edge switch. So what you should do is configure VLANs 1-8 on the edge switch and at minimum, assign those vlans tagged to the uplink trunks. (Or us mentioned earlier, leave VLAN 1 untagged as many prefer, including me). The reason to leave VLAN 1 untagged is to simplify any new switch deployments, you can simply plug it in to a port untagged on 1, and it will get a DHCP address.

Matt

[rick jones]

WRT JumboFrames. Matt is indeed correct that one really needs _everything_ in the broadcast domain to support JumboFrames before you enable them. Indeed, switches, being a layer-two thing does not know how to fragment layer-three IP datagrams :)

Now.... IFF you know beyond a shadow of a doubt that none of the systems on which you will be enabling JumboFrame will communicate with, or _through_ non-JumboFrame-enabled kit with UDP, you _might_ get away with enabling JF on only a subset of the systems.

How?

Because TCP will exchange this thing called the MSS - Maximum Segment Size when a connection is established and the connection will use the smallest of the two exchanged. So, if JF talks TCP to non-JF, JF is effectively disabled.

One additional caveat - if there is a device between two JF-enabled systems that does not grok JF, even TCP will not cover you.

There is a feature of some GbE NICs called "TSO" or "Large Send" - this is "poor man's" JF - it allows the sending system to give very large TCP segments to the NIC (larger even than the JF MTU :) and the NIC will resegment them down to the 1460/1440 typically seen on Ethernet. The sending side gets a decent fraction of the benefit of JF, but without the restriction of anything outside the sending system having to know. The downside is it does nothing for the receiver :)