We use a variety of WAN providers and many deliver us gig-e services.
No provider appears to deliver the same service the same way. Some circuits are "clear" meaning as far as our endpoints know, the only thing attached to them is our own equipment on the other end. In these instances, for example, if we unplug either end, the other end sees a loss of link.
On other circuits, they aren't clear, even CDP neighbor shows us the local handoff devices, and ONS or whatever it happens to be.
We usually opt to set up all our gig wan circuits as .1q trunks just in case and use SVI's. A handy trick on new turnups to identify if the end to end is really established is to check STP for the vlan of the link. Only one end can be root. If both ends think they are root, you know you don't have a good L2 connection.
And if you can't get the circuit live and the carrier isn't handy, a quick command to try on your interfaces are
'switchport nonegotiate'
which turns off DTP, and DTP is teh suck, so turn it off anyways
'speed nonegotiate'
which shuts off speed/duplex negotiation. this is a clause 37 thing if you care. Different carriers handle it differently on different gear. These two things can help.
Thursday, July 31, 2008
VLAN tagging between Cisco and 3com
A friend recently asked me to work up a config on a cisco to do trunking to a 3com switch for a client.
Cisco in there wisdom calls a link with VLAN tagging enabled a "trunk". A trunk is what everyone else calls a link bundle, but its just semantics. A trunk = a link with 802.1q vlan tagging enabled.
Cisco has the concept of the "native vlan" when talking about trunk links. The native VLAN is treated differently on trunk links in that those frames go into the link untagged.
3com does not have this concept. Additionally/consequently, all frames are tagged on a 3com switch that has vlan tagging enabled by default.
This can be overcome in a number of ways, but I chose to over ride it on the Cisco with the command...
'vlan dot1q tag native'
The effect of this is that the "native vlan" is also tagged. Nothing will go out the trunk port without a VLAN tag in it.
Could write a whole bunch more here about number, use of VLAN 1(and why security boogeyman will tell you its teh evil) and all that other noise, but this is one strategy to deal with interoperability between 3com and Cisco switches.
Cisco in there wisdom calls a link with VLAN tagging enabled a "trunk". A trunk is what everyone else calls a link bundle, but its just semantics. A trunk = a link with 802.1q vlan tagging enabled.
Cisco has the concept of the "native vlan" when talking about trunk links. The native VLAN is treated differently on trunk links in that those frames go into the link untagged.
3com does not have this concept. Additionally/consequently, all frames are tagged on a 3com switch that has vlan tagging enabled by default.
This can be overcome in a number of ways, but I chose to over ride it on the Cisco with the command...
'vlan dot1q tag native'
The effect of this is that the "native vlan" is also tagged. Nothing will go out the trunk port without a VLAN tag in it.
Could write a whole bunch more here about number, use of VLAN 1(and why security boogeyman will tell you its teh evil) and all that other noise, but this is one strategy to deal with interoperability between 3com and Cisco switches.
Labels:
3com,
802.1q,
cisco,
interoperability,
native vlan,
tagging,
trunk,
trunking
load balancing Sharepoint servers through a cisco CSS
Recently had alot of heart ache load balancing some sharepoint systems.
if you are using any of the cute features in sharepoint that require RFC 2518 http methods like copy, propfind, etc... you need to add the directive
'http-method parse RFC2518-methods'
Or your results will suffer.
if you are running Kerberos for your users, you also need to do increase the number of packets the CSS will span to examine HTTP headers. The default is 6. Enabling kerberos makes the HTTP headers exceed 10 1460 length ethernet frames and consequently users get repeatedly prompted for credentials.
Avoid the suffering with...
'spanning-packets 20'
if you are using any of the cute features in sharepoint that require RFC 2518 http methods like copy, propfind, etc... you need to add the directive
'http-method parse RFC2518-methods'
Or your results will suffer.
if you are running Kerberos for your users, you also need to do increase the number of packets the CSS will span to examine HTTP headers. The default is 6. Enabling kerberos makes the HTTP headers exceed 10 1460 length ethernet frames and consequently users get repeatedly prompted for credentials.
Avoid the suffering with...
'spanning-packets 20'
Labels:
11506,
2518,
cisco,
CSS,
headers,
http,
load balancer,
microsoft,
RFC,
sharepoint
Subscribe to:
Posts (Atom)