Sam.McGeown.co.uk

No matter how good your network diagrams are, sometimes you need to verify the port your server/desktop is in. Cisco Discovery Protocol is a great tool for network admins when you need to quickly map routers and switches, and if you’ve got an ESX server connected you’ll see that it picks up CDP info too – but the vast majority of my managed systems are Windows.

Here’s how to use TCPDUMP by Micro Olap to extend that functionality to your Windows boxes.

Firstly you need to find the interface number of the network adaptor you are trying to find CDP data for.  Use this command:

tcpdump -D

Which gives you a list of the interfaces on the computer:

My actual NIC is the third one in the list, so I can run the command:

tcpdump -i 3 -nn -v -s 1500 -c 1 ether[20:2] == 0x2000

-i n [interface and the number in the list, for me 3]

-nn [don’t resolve DNS, speeds things up]

-v [verbose mode, otherwise we won’t see all the packet details]

-s 1500 [set the maximum packet size to capture, the MTU is 1500 by default so it will capture the entire packet]

-c 1  [Capture one packet only, since we only want the CDP packet and filter using the header]

ether[20:2] == 0x2000 [Check the Ethernet header packet ID for the hex value 0x2000 – CDP protocol]

Some output is omitted, but you can see that the name of the switch and the port are both in there.

Easier than tracing a cable!

Cisco, Networking, Windows 7, Windows Server, Windows XP, Windows Vista, Windows Vista SP1 Cisco Discovery Protocol, CDP, Cisco, Windows, Network, Cable, Trace

I recently had an issue where a hosting environment was registering a lot of Netlogon Event 1030/1058 issues, being unable to find the Group Policy objects or download them. In this example, the server DC is the domain controller for DOMAIN.LCL.

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date:  10/09/2009
Time:  06:24:29
User:  NT AUTHORITY\SYSTEM
Computer: DC
Description:
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Date:  10/09/2009
Time:  06:24:29
User:  NT AUTHORITY\SYSTEM
Computer: DC
Description:
Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=DOMAIN,DC=LCL. The file must be present at the location <\\DOMAIN.LCL\sysvol\DOMAIN.LCL\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (Windows cannot find the network path. Verify that the network path is correct and the destination computer is not busy or turned off. If Windows still cannot find the network path, contact your network administrator. ). Group Policy processing aborted. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

On the affected machines, when navigating to \\DOMAIN.LCL there were no shares available, however navigating to \\DC shows the NETLOGON and SYSVOL shares. Pinging DOMAIN.LCL and then the DC showed that the IP addresses were not the same as expected, DOMAIN.LCL was resolving to the backup network, whereas DC was resolving to the servers LAN IP.

I checked the DNS records for the server, which were correct. Investigating the adaptor binding settings under Control Panel > Network Connections > Advanced > Advanced Settings showed that the backup network's adaptor was first in the list. I moved the adaptor for the LAN to the top of the list and OK'd my way out. I restarted the NETLOGON service and the issue was solved.

Windows servers have never been particularly good at being multi-homed, especially domain controllers. My advice comes from some bitter experience...

• If you have multiple network adaptors for extra bandwidth/redundancy/resiliance, then I would strongly recommend using Teamed adaptors, most of the major manufacturers' drivers and management software support it. This will eliminate any issues with multi-homing because as far as the server is concerned, it has one adaptor.
• If you have multiple network adaptors for different network segments and you're using RRAS to route between them, I would strongly suggest not using a Domain Controller at all for this purpose. Better yet, buy a hardware router.
• If you have multiple network adaptors for different purpose networks (e.g. a LAN, a backup network and an iSCSI network) then make sure you do the following:
  • Disable "File and Printer Sharing for Microsoft Networks" and "Client for Microsoft Networks" on all but the LAN adaptor.
  • Ensure that your LAN adaptor is the FIRST adaptor in the bindings in the advanced network settings.

 Hope that helps!

Active Directory, Networking, Windows Server 2000, Windows Server 2003, Windows Server 2008 multi-homed, domain controller, 2003, server 2003, server, network

If you’re getting a error on your LAN connection it’s possible that your network connection is attempting 802.11 authentication on your wired network. Unfortunately, it seems that Vista/Server 2008 both attempt it before reverting. As far as I can see, it’s not causing any issues, other than irritating me with a “failed” and a red question mark.

Fortunately, it’s pretty easy to fix! The authentication is handled by the Wired AutoConfig service, so it’s just a case of disabling it. Navigate “Start”, then click “Run” (or just hit Win + r) and type “services.msc”. Click “OK” and the Services console will fire up.

Now if you scroll down to Wired Autoconfig and configure it as below (Stop the service, then select “Disabled” as the startup type).

Alternatively, you can enable 802.11 on your Windows Domain…but that’s another story!

Windows Vista, Windows Server 2008, Networking windows vista, network, windows server 2008