MDIX

article from http://cciepursuit.wordpress.com/2007/07/08/switch-cabling-and-auto-mdix/

Switch Cabling And Auto-MDIX

Filed under: Cabling,Home Lab,IOS,Switching — cciepursuit @ 6:28 am 

This thread in GroupStudy about using Auto-MDIX to enable the use of straight-through cables between switches reminded me of a real world issue involving the same technology.  At my previous job, there was a “senior” engineer who supported a large site.  She was having an issue with hard-setting the speed and duplex of an uplink port (I think it was a “stack” of 2950s) on a Cisco switch.  While most of our uplinks were fiber, this one was copper (it was a small office that just needed to connect to the MDF on the floor directly above it).  Our standard was to use a cross-over cable for any switch-to-switch connections and to hard-set the speed and duplex on both sides of the connection.  She was having a problem with setting the speed and duplex.  If she hard-set these settings on both sides of the link, then the link would go down.  If she let one side of the link auto-negotiate, the link would come up, but the connection would not meet our standards.  I eventually got dragged into this issue.

Looking at the switch settings, I noticed something odd: auto-MDIX was enabled (globally) on both switches.  Our standard was to disable this on every switch.  This gave us a little protection from users making unauthorized switch-to-switch connections (accidentally or on purpose) as cross-over cables were not generally available to end users (most wouldn’t know what a cross-over cable was).  I asked the engineer if she was using a cross-over cable on the uplink. 

Her response: “That’s not the problem.  You can use a straight-through cable.” 

“Sure you CAN, but our standard is to use crossover cables because….blah, blah, blah.”

Long story shorter: she refused to adhere to our standards and use a cross-over cable and I refused to waste my time on the issue.  I wasn’t sure that the cabling was the issue, but if disabling auto-MDIX and using the proper cabling did not fix the issue then we could at least take those elements out of the equation. 

She muddled on for a couple more days (she couldn’t be bothered to open a TAC case) and the problem remained.  Finally our top-level LAN guy looked into the issue.  He found the answer after a few minutes on Cisco’s web site (this is specific to the 3560):

Configuring Auto-MDIX on an Interface
When automatic medium-dependent interface crossover (auto-MDIX) is enabled on an interface, the interface automatically detects the required cable connection type (straight through or crossover) and configures the connection appropriately. When connecting switches without the auto-MDIX feature, you must use straight-through cables to connect to devices such as servers, workstations, or routers and crossover cables to connect to other switches or repeaters. With auto-MDIX enabled, you can use either type of cable to connect to other devices, and the interface automatically corrects for any incorrect cabling. For more information about cabling requirements, see the hardware installation guide.

Auto-MDIX is enabled by default. When you enable auto-MDIX, you must also set the interface speed and duplex to auto so that the feature operates correctly. Auto-MDIX is supported on all 10/100 and 10/100/1000-Mbps interfaces and on 10/100/1000BASE-TX small form-factor pluggable (SFP)-module interfaces. It is not supported on 1000BASE-SX or -LX SFP module interfaces.

So you can use a straight through cable to connect two switches, but you then cannotexplicitly set the speed and duplex.  The engineer was told that the solution to her problem was to disable auto-MDIX and use a cross-over cable.  Where had I heard that before?  

To be fair, I wasn’t aware of the auto-MDIX needing auto-negotiation issue, BUT whenever you are troubleshooting a problem you want to minimize any deviations from known working configurations to eliminate unnecessary variables.  I think that I remember reading that auto-MDIX uses the same protocol as auto-negotiation and that’s why both need to be enabled.  I’m not positive about that though.

This table is pretty interesting.  I assume that “correct cabling” means a cross-over cable and “incorrect cabling” means a straight-through cable.

Local Side Auto-MDIX	Remote Side Auto-MDIX	With Correct Cabling	With Incorrect Cabling
On	On	Link up	Link up
On	Off	Link up	Link up
Off	On	Link up	Link up
Off	Off	Link up	Link down

---

You can refer to the table below, but it’s pretty easy to determine if a link will be up or not: at least one side needs to have auto-MDIX enabled along with auto-negotiation of speed and duplex, otherwise the link will be down.

sw1		sw2
MDIX	Speed/Duplex	MDIX	Speed/Duplex	Link Status
on	auto	on	auto	up
on	auto	on	hard-set	up
on	auto	off	auto	up
on	auto	off	hard-set	up
on	hard-set	on	auto	up
on	hard-set	on	hard-set	down
on	hard-set	off	auto	down
on	hard-set	off	hard-set	down
off	auto	on	auto	up
off	auto	on	hard-set	down
off	auto	off	auto	down
off	auto	off	hard-set	down
off	hard-set	on	auto	up
off	hard-set	on	hard-set	down
off	hard-set	off	auto	up
off	hard-set	off	hard-set	down

This makes sense because you need at least one side to be able to logically switch the pinouts of a straight-through cable to emulate a cross-over cable.  Hard-setting the speed or duplex disables the auto-negotiation protocol (which auto-MDIX must utilize as well) which effectively disables auto-MDIX:

Note: The only command that I know of that will show the auto-MDIX state of an interface (other than looking at the running-configuration of the interface) is the rather verbose “show controllers ethernet-controller fax/x phy | include MDIX” command.

Note: The default setting for switch ports is to have auto-MDIX enabled.  This is a pretty recent change though.  IOS versions prior to 12.2(20)SE will use the default of “no mdix auto”.

“mdix auto” is the default, so it does not show in the running-configuration:
sw2(config)#do sh run int fa0/32
Building configuration…
Current configuration : 34 bytes
!
interface FastEthernet0/32
end

We can verify that auto-MDIX is on for this interface:sw2(config)#do sh controll eth fa0/32 phy | i MD Auto-MDIX                             :  On   [AdminState=1   Flags=0x00052248]

Let’s hard-set the speed and see what happens to auto-MDIX:sw2(config)#int fa0/32
sw2(config-if)#speed 100sw2(config-if)#do sh control eth fa0/32 phy | i MD
 Auto-MDIX                             :  Off   [AdminState=1   Flags=0x00010A48]

Notice that our configuration does not state that auto-MDIX has been disabled:sw2(config-if)#do sh run int fa0/32
Building configuration…

Current configuration : 45 bytes
!
interface FastEthernet0/32
 speed 100
end

This verifies that hard-setting the speed and/or duplex turns off auto-MDIX for the interface.

Note: I did test to see if DTP was effected by auto-MDIX.  It was not.  As long as the link was up, DTP could work it’s trunking magic.

So the long and the short of it is: you can use straight-through cables to connect two Cisco switches as long as you are willing to sacrifice the ability to hard-set the speed and/or duplex on both sides of the link.

---

Cisco Documentation:

show controllers ethernet-controllerConfiguring Auto-MDIX on an Interface (3560)

mdix auto

Understanding Reverse Proxy Servers

Article by
Scott Forsyth's

The original web page has been gone but can be view at the web archive
http://web.archive.org/web/20130916121434/http://weblogs.asp.net/owscott/archive/2009/08/08/understanding-reverse-proxy-servers-and-the-mailman.aspx

Original article from http://weblogs.asp.net/owscott/archive/2009/08/08/understanding-reverse-proxy-servers-and-the-mailman.aspx

Understanding Reverse Proxy Servers – and the Mailman

Ok, the goal isn’t to learn about the mailman, but he’s going to come in handy later.

Proxy servers have been around since the early days of computing and they play a large role on the web today: sometimes obvious, sometimes not.  They can be used for good or they can be used for harm, like man-in-the-middle attacks.  Today I want to provide a visual representation of a reverse proxy server used for load balancing.  I also want to address some concepts and potential issues and solutions that often come up with proxy based load balancing.

Definition

Proxy: Dictionary.com: “the agency, function, or power of a person authorized to act as the deputy or substitute for another.”

Proxy server: Wikipedia: In computer networks, a proxy server is a server (a computer system or an application program) that acts as a go-between for requests from clients seeking resources from other servers.

Reverse Proxy: Wikipedia: A reverse proxy or surrogate is a proxy server that is installed in a server network. Typically, reverse proxies are used in front of Web servers.

The proxy server drawn out

This can be easily represented with the following diagrams.  This is oversimplifying the meaning slightly, but it communicates the essence of forward and reverse proxies.

Proxy Server	Reverse Proxy Server

The difference between a forward and reverse proxy server is essentially where it lives and who it targets.  If it’s on the perimeter of the client’s network (like a corporate network or ISP) then it’s a proxy server.  If it sits in front of servers or devices on the web (like in a data center) then it’s a reverse proxy server. 

Proxy servers can be used for any numbers of applications, some of them include:

Forward Proxy Server Examples

• Caching web pages to increase the perceived speed of the internet.  AOL has been known over the years for their poor implementation of proxy servers for their users.  Many corporate networks use proxies successfully.
• Filtering to ensure that inappropriate or unapproved content isn’t allowed to the end user.  These are common in corporate environments, schools and colleges. A NetNanny-type of product functions as a proxy server/service.

Reverse Proxy Server Examples

• Caching content for performance for a web server at the data center.  Speeds up a website for all users of that website.
• Load balancing a few servers to distribute load.  Allows scalability or redundancy.
• Webpage treatments for client-side performance gains.

As you can see, there are many reasons for proxy servers, and they are in operation all over the web.  It’s possible that a proxy server is being used for you to see this website right now.

Direct Server Return

I want to briefly mention another type of method used by some load balancers, called Direct Server Return (DSR). It’s helpful to contrast this with a Proxy Server.

Load Balancer using Direct Server Return

Notice that the load balancer isn’t as aggressive as the ones in the previous diagrams.  It passes on the request from the client to the web server and then it minds its own business and stays out of the rest of the communication.  In fact, with this solution, the web server barely even realizes that the load balancer played a role.  In this role, a load balancer is not taking the role of a reverse proxy server.  It does not stand in the middle for the whole process.

Additionally, even though routers and switches are middle-men between the client and server, they are not considered proxy devices either. 

Reverse Proxy Servers and Load Balancers

Now on to the main points that I want to cover.  Recently I’ve started to work with Microsoft’s new Application Request Routing (ARR) load balancer which I’ve been extra impressed with.  I plan to post more over time on how to really leverage this as a full blown flexible, stable and scalable load balancing solution.  Over the last few years I’ve been using DSR based load balancers for the most part.  As a result of working with ARR, I’ve run into a few concepts and addressed a few issues that I want to cover here.

The Mailman as a Proxy

The biggest issue that comes up with proxying requests is that it’s nearly impossible for the proxy (or reverse proxy) server to stay hidden.  Consider the mailman who delivers mail to your house each day.  He’s not the original sender, but he’s the person that, at first glance, appears to be the sender.  How many jokes are made of the mailman building a romantic relationship with the wife?

The mailman is a type of proxy.  The trick is to make sure that you can tell who the original sender is, and that you don’t get confused and give the mailman credit for a letter that’s not from him.  You certainly don’t want your love letters to your spouse or significant other being credited to the wrong person. 

In the case of the mailman, there is some evidence of the postal system proxying the mail, in the form of markings in the top right corner.  However the larger markings are the ‘return’ and ‘to’ addresses.  It’s important for the receiver to understand which markings to pay attention to and which to ignore.

The Proxy Server Leaves a Mark

When a server acts as a proxy, it will change some of the request headers.  In particular, the headers to watch for are:

• REMOTE_ADDR
• REMOTE_HOST
• Some proxy servers can also off-load SSL, which means that it will proxy from SSL to HTTP.  In that case SERVER_PORT and some certification headers come into play.

In the case of IIS and the web server, it will try to set REMOTE_ADDR and REMOTE_HOST to the IP of the proxy server.  Any code that depends on these headers will get confused.  For example, if you check for blog spam by client IP, you may check REMOTE_ADDR from code.  With the proxy server in-between, it will appear that all traffic comes from a single IP.  Additionally the web server will log the traffic as coming from the proxy server.

To avoid this impacting affect caused by the proxy server, it’s necessary to rewrite all relevant header and log information back again so that it appears to come from the original sender.  This can be done various different ways, but I’ll cover a common method, and how ARR handles this.

ARR’s Header Rewriting

With ARR, this can be handled one of four ways:

1. Ignore the issue.  Some people don’t have any site features that depend on knowing the client IP, and they are fine with not knowing the client IP in their site statistics. 
2. Update your code to use the custom headers that ARR sets, namely X-Original-URL, X-Forwarded-For, X-ARR-SSL, X-ARR-LOG-ID.  This won’t address the IIS logs, but it can address everything else.
3. ARR Helper.  Anil Ruia, one of the primary ARR developers, has written a helper module that works in IIS7 to rewrite the relevant headers back.  The ARR Helper module is not officially supported by Microsoft, but works like a charm.  ARR itself will place the original client’s site in a configurable request header, which is X-Forwarded-For by default.  It will also place certificate information for SSL offloading in X-ARR-SSL.  On the actual web server, the ARR Helper runs silently in the background and will rewrite those headers back to REMOTE_ADDR, REMOTE_HOST, SSL and REMOTE_PORT.  It will also ensure that the logs recover the original client IP.  It’s installed at the server level and doesn’t have any impact on non-load balanced sites and performance overhead is negligible (for load balanced or non-load balanced).  We’re running this in production at ORCS Web and are very pleased with the results.  No code changes are necessary for the site owner.
4. With ARR and URL Rewrite 2.0, currently in Beta, it can also do the same thing.  ARR itself takes care of the writing on the ARR server, and URL Rewrite 2.0 can rewrite the X-Headers back to the appropriate locations.  URL Rewrite 2.0 needs to be installed and configured on each of the web servers.  Currently I’m running this in testing only since version 2.0 does not have a go-live license, but the end goal is to use URL Rewrite for the web server rewriting.  While Anil’s solution works perfectly, this will be the Microsoft supported solution moving forward.

In future blog posts, I hope to dig deeper into ARR technically, but I wanted to lay the groundwork first on the concept of proxying, and what you need to consider by having a middle man between the client and web server.