Router – WAN access on Layer 3 Switch

hp-procurvenetworkingrouterroutingswitch

I have an HP ProCurve 8212zl Switch which I am currently configuring from scratch. This switch is a Layer 3 switch, meaning it also supports routing.

I also have an ISP that provides me with access to the Internet via a 1000SX gigabit SFP fibre channel, and has assigned me a range of static IP addresses, and also given me the IP address of their Gateway.

My goal right now is to setup a minimal configuration that supports both LAN and WAN access (i.e. access to my local network devices and also access to the Internet via the ISP's gateway.)

Setting up the LAN was very simple. I used the switch's CLI to assign an IP address to the switch. Then I manually assigned static IP addresses to all devices connected to the switch. (I realize I should be using DHCP, but again, at the moment I am only interested in the simplest possible configuration that supports LAN and WAN.) So now I have the LAN working: all devices connected to the switch can ping the switch, and all devices connected to the switch can ping each other. The LAN consists of a single default VLAN.

However, I am unable to figure out how to get access to the Internet working.

I have a fibre channel that connects directly to a switch module via an SFP (1000SX Mini-GBIC). The SFP is connected to port B21 in the switch. Using the switch CLI, I can check the status of the fibre channel port by typing show interfaces B21. This shows me that port B21 is indeed enabled, and its status is up, and it is receiving bytes. So the SFP and port seems to be working fine.

Conceptually, my understanding is that in order to access the Internet, the switch would need to:

Check if a packet has a destination IP that is not part of the
local LAN
If so, forward it to my ISP's Gateway via Port B21 (the fibre channel port)

I've read through many of the HP ProCurve manuals, but I don't understand how this is accomplished. The closest I can understand is that you need to enable routing on the switch (which I've done), and then specify a "default route". A default route basically tells the switch "if you see a packet that's destined for some address that is not part of the local LAN, then forward it to <SOME IP ADDRESS>"

So, on the CLI I can do:

# ip route 0.0.0.0/0 <MY ISP'S GATEWAY IP ADDRESS>

This tells the switch that if a packet is destined for some address that is not part of the LAN, forward it to <ISP GATEWAY ADDRESS>.

I tried this, and it doesn't work – meaning, even with the default route set, I still can't ping my ISP's Gateway, and I can't ping any external Internet address (like the IP address of google.com, for example).

But even worse, I don't even understand why this should work. How can the switch possibly know that it must go through the fibre channel port (port B23) to even access the external world in order to even find <ISP GATEWAY ADDRESS>? I don't see how the ip route command gives the switch enough information about where to find <ISP GATEWAY ADDRESS>.

I suspect I must be missing some key concept here. In general, I want to tell the switch: "if you see a packet destined for a non-LAN address, forward it to port B23, where you will find a connection to the outside world and the next hop (my ISP's Gateway)".

So what am I missing here?

Best Answer

Basically what Roman and ewwhite are saying is that you need a much better understanding of networking to get this to work.
If you really intend to do it this way you will need to setup two VLANs on the switch. One for your LAN and one for the internet. You will need to use one of the assigned IP addresses from the internet on your switch for port B23. You will then need to setup routing between the VLANs to accomplish your stated goals.
A quick Google search found this thread with someone looking to do a similar thing to you, please follow it to gain a better understanding.
https://community.spiceworks.com/topic/403586-hp-swtich-setup-routing-between-vlans

Related Solutions

Networking – How Does Layer 3 LACP Destination Address Hashing Work?

What you're looking for is commonly called a "transmit hash policy" or "transmit hash algorithm". It controls the selection of a port from a group of aggregate ports with which to transmit a frame.

Getting my hands on the 802.3ad standard has proven difficult because I'm not willing to spend money on it. Having said that, I've been able to glean some information from a semi-official source that sheds some light on what you're looking for. Per this presentation from the 2007 Ottawa, ON, CA IEEE High Speed Study Group meeting the 802.3ad standard does not mandate particular algorithms for the "frame distributor":

This standard does not mandate any particular distribution algorithm(s); however, any distribution algorithm shall ensure that, when frames are received by a Frame Collector as specified in 43.2.3, the algorithm shall not cause a) Mis-ordering of frames that are part of any given conversation, or b) Duplication of frames. The above requirement to maintain frame ordering is met by ensuring that all frames that compose a given conversation are transmitted on a single link in the order that they are generated by the MAC Client; hence, this requirement does not involve the addition (or modification) of any information to the MAC frame, nor any buffering or processing on the part of the corresponding Frame Collector in order to re-order frames.

So, whatever algorithm a switch / NIC driver uses to distribute transmitted frames must adhere to the requirements as stated in that presentation (which, presumably, was quoting from the standard). There is no particular algorithm specified, only a compliant behavior defined.

Even though there's no algorithm specified, we can look at a particular implementation to get a feel for how such an algorithm might work. The Linux kernel "bonding" driver, for example, has an 802.3ad-compliant transmit hash policy that applies the function (see bonding.txt in the Documentation\networking directory of the kernel source):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

This causes both the source and destination IP addresses, as well as the source and destination MAC addresses, to influence the port selection.

The destination IP address used in this type of hashing would be the address that's present in the frame. Take a second to think about that. The router's IP address, in an Ethernet frame header away from your server to the Internet, isn't encapsulated anywhere in such a frame. The router's MAC address is present in the header of such a frame, but the router's IP address isn't. The destination IP address encapsulated in the frame's payload will be the address of the Internet client making the request to your server.

A transmit hash policy that takes into account both source and destination IP addresses, assuming you have a widely varied pool of clients, should do pretty well for you. In general, more widely varied source and/or destination IP addresses in the traffic flowing across such an aggregated infrastructure will result in more efficient aggregation when a layer 3-based transmit hash policy is used.

Your diagrams show requests coming directly to the servers from the Internet, but it's worth pointing out what a proxy might do to the situation. If you're proxying client requests to your servers then, as chris speaks about in his answer then you may cause bottlenecks. If that proxy is making the request from its own source IP address, instead of from the Internet client's IP address, you'll have fewer possible "flows" in a strictly layer 3-based transmit hash policy.

A transmit hash policy could also take layer 4 information (TCP / UDP port numbers) into account, too, so long as it kept with the requirements in the 802.3ad standard. Such an algorithm is in the Linux kernel, as you reference in your question. Beware that the the documentation for that algorithm warns that, due to fragmentation, traffic may not necessarily flow along the same path and, as such, the algorithm isn't strictly 802.3ad-compliant.

Router – Wan access through managed switch

Step 1: If you connect directly to the managed switch, do you get a valid IP address from the DHCP server on the LinkNet router?

Can you ping 192.168.1.1, 192.168.1.2 and 8.8.8.8 and the gateway of your ISP?

Yes, then:

Step 2: Try this again from the Unmanaged switch, and release/renew the DHCP lease from your test device.

Do you still have a valid IP address? Can you still ping 192.168.1.1, 192.168.1.2 and 8.8.8.8 and the gateway of your ISP?

No?

Try connecting the switches with a Crossover cable instead of a straight-through one. Cross-connecting older (or less clever) switches often needs a Crossover cable. Newer/intelligent switches support Auto-MDI/X and will automatically negotiate a crossover link.

Yes? Check the default route, and also that any VLAN configuration on the managed switch is set to "Untagged VLAN 1" on all ports (effectively making it a flat switch).

Step 3: Are you using the DNS servers from your ISP? Can you ping those from anywhere on the network? If not, try pinging Google's public DNS (8.8.8.8, 8.8.4.4). If that works, your ISP is being dumb. -- Use Google's public DNS, and be happy.

Best Answer

Related Solutions

Networking – How Does Layer 3 LACP Destination Address Hashing Work?

Router – Wan access through managed switch

Related Topic