bpdu guard and bpdu filter`

WTT 10M link down. Checked due to FW sw f0/6 err-disabled and the interface is configured with bpdu guard. This triggers me the interests on what is the the actual difference between bpdu guard and bpdu filter on a switch interface.


bpdu guard
the port cannot receive any bpdu, if received, the port will be err-disable.


bpdu filter
the filter means more like from switch inside point of view, the bpdu is "filtered" (by the switch itself) from sending out of the switch port so it doesn't expect to receive any also. But it allow to receive, though not expect.

Reference

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_55_se/configuration/guide/3560_scg/swstpopt.html#wp1033638

===================================================================
https://supportforums.cisco.com/document/45136/importance-bpdu-guard-and-bpdu-filter

Blog from Ganesh Hariharan in supportforums.cisco.com

Introduction
In Networking World we know that to avoid any loops or any problem related to switching arcihtecure the stability of the Root Bridge is of paramount importance in the operation and continual uninterrupted service of spanning-tree. A change in the position of the Root Bridge will cause service disruption on the network with data and voice session timing out.

It is important to consider what events could cause a change in the position of the Root Bridge, events such as links failing between the existing Root Bridge and the rest of the network would cause a change, or possibly a duplex mismatch between the Root Bridge and downstream switches causing the spanning-tree messages from the Root Bridge from reaching the other parts of the network. These events are easily fixed and resolved none of which would require the use of the BPDU Guard feature.

Always a better practice to enforce the Spanning-tree domain borders and keep our active topology and the position of our Root Bridge predictable.

Best Practices to enable BPDU Guard only on access ports (access ports lead to end user devices) so that any end user devices on these ports that have BPDU Guard enabled are not able to influence the Spanning-tree topology.

Configuring BPDU Guard
Following are the modes in which we can configure BPDU Guard in switches

Interface mode
spanning-tree bpduguard enable (Puts port in errdisable upon receiving any bpdu).

Global mode
spanning-tree portfast bpduguard default (It enables bpduguard on ports that have port-fast configuration, puts port in errdisable upon receiving a bpdu).

Once BPDU Guard is enabled it will keep an eye open for any BPDU's entering the access ports. The only devices which can reliably create and transmit BPDU's are switches.Our main aim to have a predictable topology and not allow other switches outside our control onto our network. If a rogue switch is introduced into our topology it will in most cases transmit a BPDU, if the rogue switch has "better" values than the existing Root Bridge it will cause a topology change in the switched network. Any topology change is bad news for the users.

By configuring the "BPDU Guard" feature on the access-ports enables the spanning-tree protocol to shut the port down in the event that is receives a BPDU. As a rule of thumb, BPDU's are really only expected across trunk links.If a rogue switch is plugged into a port configured for BPDU Guard, the port will disable as soon as the first BPDU is received, by shutting the port down we prevent the rogue switch from affecting our spanning-tree topology.

To re-enable a port disabled by BDPU Guard you will need to remove the offending device and then bounce the port by issuing the shut/no shut command

BPDUfilter on the other hand just filters BPDUs in both directions, which effectively disables STP on the port.Bpdu filter will prevent inbound and outbound bpdu but will remove portfast state on a port if a bpdu is received.Enabling BPDU filtering on an interface is the same as disabling spanning tree on it and can result in spanning-tree loops.

Configuring BPDU Filter
Following are the method to configure BPDU Filter in switches

Interface mode
spanning-tree bpdufilter enable (Results port to not participate in STP, loops may occur).

Global mode                              
spanning-tree portfast bpdufilter default (It enables bpdufiltering on ports that have port-fast configuration, so it sends a few bpdu while enabling port then it filters bdpu unless receives a bpdu, after that it changes from port-fast mode and disables filtering for port to operate like a normal port because it has received bpdu).

You always should allow STP to run on a switch to prevent loops. However, in special cases when you need to prevent BPDUs from being sent or processed on one or more switch ports, you can use BPDU filtering to effectively disable STP on those ports.you would use bpdufilter when you want a switch plugged into your network but you don't want it participating in spanning tree.

An example:  In an office environment where someone needs  another network drop under their desk but you don't have time/budget to  run a new line for now.  you are been given a small switch but don't want it to break spanning tree.The switch  you have lying around for this task is a simple unmanaged switch and  will only have one uplink into your network. so you put bpdufilter on your  switch port.

Ganesh.H

Single Mode vs Multi Mode Fiber

cost

Cable itself, single mode is cheaper than multi mode fiber. But for overall cost, including the cost of the transceiver, the cost of single mode "system" is much expensive.

e.g
From Amazon
Fiber cost
Multi mode 500 ft 50/125 is $ 229.95 (page archived at https://archive.is/M69VR) 
Single mode 500 ft 9/125 is $99.99 only (page archived at https://archive.is/BDSOe)

The youtube video provide a clear explanation.
https://youtu.be/OFcvpaQThA8?t=132

https://youtu.be/OFcvpaQThA8

What is multi mode optical fiber video

https://www.youtube.com/watch?v=6xYOzY4zj0o

Fiber Optic Connector Types Explained in Details

https://www.youtube.com/watch?v=4Ovqe3XjRqM

A discussion forum about if single mode can work with multi mode, normally no, depends on a lot of factor, such as the characteristics of the transceiver and the fiber itself etc. (archived here)

==========================================================================

http://www.lanshack.com/fiber-optic-tutorial-fiber.aspx

Optical Fiber Tutorial (from lansharck.com)

Fiber Specifications

The usual fiber specifications you will see are size, attenuation and bandwidth. While manufacturers have other specs that concern them, like numerical aperture (the acceptance angle of light into the fiber), ovality (how round the fiber is), concentricity of the core and cladding, etc., these specs do not affect you. 

Fiber Itself

Fiber Optics, as we said, is sending signals down hair-thin strands of glass or plastic fiber. The light is "guided" down the center of the fiber called the "core". The core is surrounded by a optical material called the "cladding" that traps the light in the core using an optical technique called "total internal reflection." The core and cladding are usually made of ultra-pure glass, although some fibers are all plastic or a glass core and plastic cladding. The fiber is coated with a protective plastic covering called the "primary buffer coating" that protects it from moisture and other damage. More protection is provided by the "cable" which has the fibers and strength members inside an outer covering called a "jacket". 

Multimode & Singlemode Fibers

Multimode & Singlemode fiber are the two types of fiber in common use. Both fibers are 125 microns in outside diameter - a micron is one one-millionth of a meter and 125 microns is 0.005 inches- a bit larger than the typical human hair. Multimode fiber has light traveling in the core in many rays, called modes. It has a bigger core (almost always 62.5 microns, but sometimes 50 microns ) and is used with LED sources at wavelengths of 850 and 1300 nm (see below!) for slower local area networks (LANs) and lasers at 850 and 1310 nm for networks running at gigabits per second or more. Singlemode fiber has a much smaller core, only about 9 microns, so that the light travels in only one ray. It is used for telephony and CATV with laser sources at 1300 and 1550 nm. Plastic Optical Fiber (POF) is large core ( about 1mm) fiber that can only be used for short, low speed networks. 

Step index multimode was the first fiber design but is too slow for most uses, due to the dispersion caused by the different path lengths of the various modes. Step index fiber is rare - only POF uses a step index design today. 

Graded index multimode fiber uses variations in the composition of the glass in the core to compensate for the different path lengths of the modes. It offers hundreds of times more bandwidth than step index fiber - up to about 2 gigahertz. 

Singlemode fiber shrinks the core down so small that the light can only travel in one ray. This increases the bandwidth to almost infinity - but it's practically limited to about 100,000 gigahertz - that's still a lot! 

Size Matters

Fiber, as we said, comes in two types, singlemode and multimode. Except for fibers used in specialty applications, singlemode fiber can be considered as one size and type. If you deal with long haul telecom or submarine cables, you may have to work with specialty singlemode fibers. 

Multimode fibers originally came in several sizes, optimized for various networks and sources, but the data industry standardized on 62.5 core fiber in the mid-80s (62.5/125 fiber has a 62.5 micron core and a 125 micron cladding.) Recently, as gigabit and 10 gigabit networks have become widely used, an old fiber has been revived. The 50/125 fiber was used from the late 70s with lasers for telecom applications before singlemode fiber became available. It offers higher bandwidth with the laser sources used in the gigabit LANs and can go longer distances. While it still represents a smaller volume than 62.5/125, it is growing. 

Fiber Types and Typical Specifications

Core/Cladding	Attenuation	Bandwidth	Applications/Notes
Multimode Graded-Index
	@850/1300 nm	@850/1300 nm
50/125 microns	3/1 dB/km	500/500 MHz-km	Laser-rated for GbE LANs
50/125 microns	3/1 dB/km	2000/500 MHz-km	Optimized for 850 nm VCSELs
62.5/125 microns	3/1 dB/km	160/500 MHz-km	Most common LAN fiber
100/140 microns	3/1 dB/km	150/300 MHz-km	Obsolete
Singlemode
	@1310/1550 nm
8-9/125 microns	0.4/0.25 dB/km	HIGH! ~100 Terahertz	Telco/CATV/long high speed LANs
Multimode Step-Index
	@850 nm	@850 nm
200/240 microns	4-6 dB/km	50 MHz-km	Slow LANs & links
POF (plastic optical fiber)
	@ 650 nm	@ 650 nm
1 mm	~ 1 dB/m	~5 MHz-km	Short Links & Cars

CAUTION: You cannot mix and match fibers! Trying to connect Singlemode to Multimode fiber can cause 20 dB loss - that's 99% of the power. Even connections between 62.5/125 and 50/125 can cause loss of 3 dB or more - over half the power. 


=============================================================================

http://www.multicominc.com/training/technical-resources/single-mode-vs-multi-mode-fiber-optic-cable/

Single Mode vs. Multi-Mode Fiber Optic Cable (from Multicom)

Fiber Optics is sending signals down hair-thin strands of glass or plastic fiber. The light is “guided” down the center of the fiber called the “core”. The core is surrounded by a optical material called the “cladding” that traps the light in the core using an optical technique called “total internal reflection.”

The core and cladding are usually made of ultra-pure glass. The fiber is coated with a protective plastic covering called the “primary buffer coating” that protects it from moisture and other damage. More protection is provided by the “cable” which has the fibers and strength members inside an outer covering called a “jacket”.

Single Mode Fiber Optic Cable

Single Mode fiber optic cable has a small diametral core that allows only one mode of light to propagate. Because of this, the number of light reflections created as the light passes through the core decreases, lowering attenuation and creating the ability for the signal to travel faster, further. This application is typically used in long distance, higher bandwidth runs by Telcos, CATV companies, and Colleges and Universities.

Left: Single Mode fiber is usually 9/125 in construction. This means that the core to cladding diameter ratio is 9 microns to 125 microns.

Multimode Fiber Optic Cable

Multimode fiber optic cable has a large diametral core that allows multiple modes of light to propagate. Because of this, the number of light reflections created as the light passes through the core increases, creating the ability for more data to pass through at a given time. Because of the high dispersion and attenuation rate with this type of fiber, the quality of the signal is reduced over long distances. This application is typically used for short distance, data and audio/video applications in LANs. RF broadband signals, such as what cable companies commonly use, cannot be transmitted over multimode fiber.

Above: Multimode fiber is usually 50/125 and 62.5/125 in construction. This means that the core to cladding diameter ratio is 50 microns to 125 microns and 62.5 microns to 125 microns.

 

What’s Happening Inside The Multimode Fiber

Step-Index Multimode Fiber

Due to its large core, some of the light rays that make up the digital pulse may travel a direct route, whereas others zigzag as they bounce off the cladding. These alternate paths cause the different groups of light rays, referred to as modes, to arrive separately at the receiving point. The pulse, an aggregate of different modes, begins to spread out, losing its well-defined shape. The need to leave spacing between pulses to prevent overlapping limits the amount of information that can be sent. This type of fiber is best suited for transmission over short distances.

Graded-Index Multimode Fiber

Contains a core in which the refractive index diminishes gradually from the center axis out toward the cladding. The higher refractive index at the center makes the light rays moving down the axis advance more slowly than those near the cladding. Due to the graded index, light in the core curves helically rather than zigzag off the cladding, reducing its travel distance. The shortened path and the higher speed allow light at the periphery to arrive at a receiver at about the same time as the slow but straight rays in the core axis. The result: digital pulse suffers less dispersion. This type of fiber is best suited for local-area networks.

======================================================================================

http://www.blackbox.com/resources/blackboxexplains.aspx?id=bbe_2124

Black Box Explains...Multimode vs. single-mode Fiber.. (from Blackbox)

Multimode vs. single-mode. Multimode cable has a large-diameter core and multiple pathways of light. It can be used for most general data and voice applications, such as adding segments to an existing network.

Multimode comes in two core sizes and four varieties: 62.5-micron OM1, 50-micron OM2, 50-micron OM3, and 50-micron OM4. (OM stands for optical mode.) All have the same cladding diameter of 125 microns, but 50-micron fiber cable has a smaller core (the light-carrying portion of the fiber). Although all can be used in the same way, 50-micron cable, particularly laser-optimized OM3 and OM4 50-micron cable, provides longer link lengths and/or higher speeds and is recommended for premise applications (backbone, horizontal, and intrabuilding links) and should be considered for new installations. OM3 and OM4 can also be used with LED and laser light sources.

Single-mode cable (OS1, OS2) has a small (8–10-micron) glass core and only one pathway of light. (OS stands for optical single-mode.) With only a single wavelength of light passing through its core, single-mode realigns the light toward the core center instead of simply bouncing it off the edge of the core as multimode does. OS1 is applied to inside-plant tight-buffered cable. OS2 is applied to loose-tube cables.

Single-mode provides far greater distances than multimode cable and can go as far as 40 km so it’s typically used in long-haul network links spread out over extended areas, including CATV and campus backbone applications. Single-mode cable also provides higher bandwidth than multimode fiber.

Specification comparison

OM1 62.5-/125-Miron Multimode Fiber

850-nm Wavelength:
Bandwidth: 160 MHz/km;
Attenuation: 3.5 dB/km;
Distance: 220 m;

1300-nm Wavelength:
Bandwidth: 500 MHz/km;
Attenuation: 1.5 dB/km;
Distance: 500 m

OM2 50-/125-Micron Multimode Fiber
850-nm Wavelength:
Bandwidth: 500 MHz/km;
Attenuation: 3.5 dB/km;
Distance: 550 m;

1300-nm Wavelength:
Bandwidth: 500 MHz/km;
Attenuation: 1.5 dB/km;
Distance: 550 m
OM3 50-/125-Micron Multimode Fiber

850-nm Wavelength:
Bandwidth: 1500 MHz/km;
Attenuation: 3.5 dB/km;
Distance: 550 m;

1300-nm Wavelength:
Bandwidth: 500 MHz/km;
Attenuation: 1.5 dB/km;
Distance: 550 m

OM4 50-/125-Micron Multimode Fiber
850-nm Wavelength:
Bandwidth: 3500 MHz/km;
Attenuation: 3.5 dB/km;
Distance: 550 m;

1300-nm Wavelength:
Bandwidth: 500 MHz/km;
Attenuation: 1.5 dB/km;
Distance: 550 m

OS2 8–10-Micron Single-Mode Fiber
Premise Application:
Wavelength: 1310 nm and 1550 nm;
Attenuation: 1.0 dB/km;

Outside Plant Application:
Wavelength: 1310 nm and 1550 nm;
Attenuation: 0.1 dB/km 

DNS Forwarders vs. Root Hints in Windows Server

http://www.dell.com/support/article/us/en/19/SLN156952/EN

DNS Forwarders vs. Root Hints in Windows Server

---

Article Summary: This article provides information on the function of forwarders and root hints in Windows DNS.

---

A Windows DNS server, like any DNS server, provides authoritative answers to queries for records in the zones stored in the server's DNS database. It often must answer queries for records not in any of its zones, though. A DNS server in a network connected to the internet must provide a way for other machines on the network to resolve internet hostnames to IP addresses, for example. Responses to queries of this sort are non-authoritative responses, because the server must obtain the requested data from a source other than its own DNS database. The nslookup tool indicates when a response is non-authoritative, as shown below:


There are two ways to configure a Windows DNS server to provide non-authoritative responses: forwarders and root hints. These are both lists of servers that are used to resolve queries that the local DNS server can't resolve on its own, and both provide the same functionality from the perspective of a client. They do so in different ways, however:

• Root hints use iterative queries. When the local DNS server can't resolve a query using its cache or database, it sends a query to one of the root DNS servers on the internet. The root server will respond with a referral, which contains the addresses of the DNS servers authoritative for the top-level domain (such as .com or .net) in the original query. The local server then queries one of the servers in the referral, which will respond with another referral, this time to the servers authoritative for the second-level domain (dell.com, for example) in the original query. This query/referral process continues until a server is reached that is authoritative for the fully qualified domain name (FQDN) in the original query. It will return an authoritative positive or negative response - a response which either contains the record sought by the original query or indicates that it doesn't exist - and the local server will send that response to the querying client.
• Forwarders, on the other hand, use recursive queries. If forwarders are configured, when the local DNS server can't resolve a query, it sends a recursive query to one of the forwarders in its list. This type of query tells the forwarder that the local server will accept either a positive or negative response, but not a referral. Essentially, the forwarder does the work of tracking down the record in the query, which may involve the referral process above, and the local server simply waits for the response, which it then sends to the querying client.

To configure forwarders or root hints on a Windows DNS server, follow this procedure:

1. Open the DNS Management console.
2. Right-click the DNS server in the left pane and select Properties.
3. To configure forwarders, select the Forwarders tab of the properties window:
   
   
   To configure root hints, select the Root Hints tab of the properties window:
   
   
   Note: Forwarders must be manually configured, but root hints are present by default on a Windows DNS server. The root hints list can be manually modified, however.

The decision to use root hints or forwarders for external resolution is often a matter of preference, but there are a few things to keep in mind:

• When configuring forwarders, be sure to add at least two servers to the list. If only a single forwarder is present in the list and that forwarder becomes unreachable, the local server will not be able to resolve external names at all.
• Properly configured forwarders often provide quicker responses than root hints, but the difference is usually only a matter of milliseconds.
• Although the root hints list will typically contain only thirteen entries (a.root-servers.net throughm.root-servers.net), each of those entries is highly redundant. There are 376 geographically distributed root DNS servers as of this writing.
• Forwarders are not stored in Active Directory. This is important, since DNS servers in an AD domain are typically domain controllers (DCs). Forwarders configured on one DC will not replicate to other DCs; they must be manually configured on each DC which is also a DNS server.

Checkpoint HA and Linux ping

======= ping from Mkdata fw 1

[Expert@HKDC-MDFW01]# ifconfig et2
et2: error fetching interface information: Device not found
[Expert@HKDC-MDFW01]# ifconfig eth2
eth2      Link encap:Ethernet  HWaddr 00:11:0A:5C:9C:42
          inet addr:10.64.47.2  Bcast:10.64.47.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2765092474 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1641068850 errors:121688095 dropped:0 overruns:0 carrier:121688095
          collisions:264179110 txqueuelen:100
          RX bytes:4254983326 (4057.8 Mb)  TX bytes:385093500 (367.2 Mb)
          Base address:0x5000 Memory:fdfe0000-fe000000

From 10.64.47.33 icmp_seq=33 Destination Host Unreachable
[Expert@HKDC-MDFW01]# ping 192.168.7.20
PING 192.168.7.20 (192.168.7.20) 56(84) bytes of data.
From 10.64.47.33 icmp_seq=0 Destination Host Unreachable

--- 192.168.7.20 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
, pipe 2

[HKDC-MDFW01]# cphaprob state

Cluster Mode:   Load Sharing (Unicast)

Number     Unique Address  Assigned Load   State

1 (local)  172.29.1.2      30%             Active       (pivot)
2          172.29.1.3      70%             Active


======= but recieved the reply at fw -2-

[Expert@HKDC-MDFW02]# ifconfig eth2
eth2      Link encap:Ethernet  HWaddr 00:11:0A:5D:03:68
          inet addr:10.64.47.3  Bcast:10.64.47.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:451092050 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2584982750 errors:4759498 dropped:0 overruns:0 carrier:4759498
          collisions:43777881 txqueuelen:100
          RX bytes:3569653811 (3404.2 Mb)  TX bytes:4193433553 (3999.1 Mb)
          Base address:0x5000 Memory:fdfe0000-fe000000

[Expert@HKDC-MDFW02]# fw monitor -e 'accept icmp and host(10.64.47.33);'
 monitor: getting filter (from command line)
 monitor: compiling
monitorfilter:
Compiled OK.
 monitor: loading
 monitor: monitoring (control-C to stop)
eth2:i[56]: 10.64.47.33 -> 10.64.47.1 (ICMP) len=56 id=17086
ICMP: type=3 code=1 unreachable (host)
      10.64.47.1 -> 192.168.7.20 (ICMP: t=8 c=0) ipid=217
eth2:I[56]: 10.64.47.33 -> 10.64.47.2 (ICMP) len=56 id=17086
ICMP: type=3 code=1 unreachable (host)
      10.64.47.2 -> 192.168.7.20 (ICMP: t=8 c=0) ipid=217
 monitor: caught sig 2
 monitor: unloading
[Expert@HKDC-MDFW02]#

======= conclusion 
event the Linux levle traffic are HA ed by checkpoint

multicast routing

http://www.enterprisenetworkingplanet.com/netsp/article.php/3623181/Networking-101--Understanding-Multicast-Routing.htm

DVMP dense mode
PIM dense mode just like DVMP, flood anywhere first then prune by the router when on one want to have that multicast stream (by IGMP)
PIM sparse mode, use RP to inform who like to have the stream and where to pass it (join, or graft, the opposite of join).

RFP (Reverse Path Forwarding) is used to prevent routing loop, by looking and choosing the shortest path to the sender.

MOSFP, BGMP rarely used.

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.