NO_CLIENT_SITE: 169.254...

  • 530 Views
  • Last Post 05 May 2016
a-ko posted this 03 May 2016

Would anyone know how I would have seen a 169.254 address show up in my netlogon.log on a DC? The obvious thought that somehow the traffic got routed or the system was directly on the switch—but it seems kind of odd to me that this would show up. Anyone? -Mike Cramer

Order By: Standard | Newest | Votes
gkirkpatrick posted this 03 May 2016

That would be my guess… DHCP lease renewal failed for some reason for a device on the same switch.

 

-gil

 

show

a-ko posted this 03 May 2016

Without digging too much into my network topology—it was an end user workstation that should, in theory, be on a different VLAN/Routed network… So that makes it even scarier… LOL 

show

gkirkpatrick posted this 03 May 2016

<scratches head> hmmmm. Are you sure it was that workstation?

 

-g

 

show

daemonr00t posted this 03 May 2016

Maybe a machine out there with a misconfigured NIC… seen that a few times. ~d 

show

kurtbuff posted this 03 May 2016

Dual NICs in a workstation or server, possibly.

I see them occasionally as well, but have never been able to track
them down for sure.

Kurt

show

Anthony.Vandenbossche posted this 03 May 2016

I think that while booting, the client is trying to get a DHCP lease, but can’t and therefor tries to contact a DC.

 

@Mike: are you saying that the client was on a non-routed subnet? In that case this theory is useless

J.

 



Mvg,

 

Anthony Van den bossche


System Engineer


Anthony.Vandenbossche@xxxxxxxxxxxxxxxx



Direct

+32 (0)2 801 54 59


Description: Description: C:\Users\BJTAF40\AppData\Roaming\Microsoft\Signatures\realdolmen_logo.gif



This e-mail message and any attachment are intended for the sole use of the recipient(s) named above and may contain information which

is confidential and/or protected by intellectual property rights. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s)

is prohibited. If you have received this e-mail in error, please notify the sender either by telephone (+32 2 801 55 55) or by e-mail and delete the material from any computer. Please note that neither RealDolmen nor the sender accept any responsibility for

viruses and it is your responsibility to scan or otherwise check this email and any attachments. RealDolmen is nor responsible for the correct and complete transfer of the contents of the sent e-mail, neither for the receipt on due time.







 

show

a-ko posted this 03 May 2016

I’m not exactly sure where the client was yet. I’m going to guess it wasn’t on the same VLAN as this particular server because the server itself sits in a lights out datacenter. I haven’t ruled out networking issues….but I was wondering if anyone knew for sure. I didn’t think that the clients/servers reported this data itself (that would imply that the client first parses the data and sends some information to the DC)… I would have assumed based on how old this particular piece of code is that it’s just doing a raw read of whatever traffic comes in to the NetLogon service and recording the IP off the wire… Which means that 169.254 would have gotten routed internally somehow… Haven’t had much time to dig into it today, but I will! It’s very intriguing! 

show

rwf4 posted this 03 May 2016

I’ve seen improperly configured NICs cause problems such as  registering the 169.254.x.x APIPA addresses in DNS and have also seen them  show up in netlogon.log.  

 

One case was dual nics, on a new DC,  both enabled in OS but only 1 plugged in if memory serves.

 

That situation is documented here-  http://www.cbfive.com/domain-controllers-register-apipa-address-for-disconnected-nics/

 

 

show

kennedyjim posted this 04 May 2016

Any Hyper V’s in the area…I have seen their virutual nics do that from time to time.

 

show

Batz_10K posted this 04 May 2016

If you’re using IBM gear, the internal RNDIS-over-usb adapter that connects to the management processor (IMM) for the machine can do this too. (it has, by default a 169.254

address).

 

show

venkatsp posted this 04 May 2016

Hi All,
169.254 appeared in Netlogon.log because there is no associated Site configured in subnets. Please configure 169.254 IP range in Sites ans Services Subnet and make sure it is pointing to correct Site. However if this IP address belongs to any workgroup machine connects to network using VPN, thne no need to configure any subnets.
Venkat

show

kurtbuff posted this 04 May 2016

Um, I don't think this statement makes sense for most AD installations, if any.
After all, the 169.254/16 range is autoassigned by Windows to any interface that doesn't get an IPv4 address assigned either statically or dynamically.
Therefore
1) If you have more than one site, it's going to be pretty much impossible to assign that subnet to a site, because those addresses can appear anywhere, and
2) I would bet fairly large money that it's extraordinarily rare for anyone to route that subnet anywhere. Certainly I've never seen it routed. Not only that, most installations I've heard of treat them as bogons, to be squelched wherever they appear.
Generally, the appearance of an APIPA address in your environment means something is amiss.
Kurt


show

mcasey posted this 04 May 2016

I agree.  In my experience it's most often because one of the domain controllers has multiple interfaces and one is on the club but not disabled

show

a-ko posted this 04 May 2016

The DC itself does not have multiple NICs. Only a single NIC :P 

show

kurtbuff posted this 04 May 2016

And I believe you - but some machine in your environment has an active interface that's not getting an address, and it's likely that another interface on that same machine is trying to "help out".   (:-o
Something like this might prove useful to get all of the NICs and their IP addresses in your environment:
https://gallery.technet.microsoft.com/scriptcenter/Get-Network-Information-of-6d07766f/view/Discussions#content
Assuming that the APIPA address hasn't changed due to a reboot on the machine with the problem (or that someone hasn't disabled the NIC, given it an address, put it in a VLAN with access to a DHCP server etc), it shouldn't be too hard to match up the rogue with the output from the above script.
Kurt

show

jeremyts posted this 04 May 2016

A lot bizarre comments on this thread. It really isn’t that difficult.

 

The hostname of the machine giving the errors “should” appear in the same line as the NOCLIENTSITE: 169.254 in the Netlogon.log file.

 

Simply ping that hostname to return it’s real address from DNS. Then go and have a look and see what’s happening and why there’s a NIC without an IP address,

or that should be disabled.

 

Cheers,

Jeremy

 

show

Mahdi posted this 05 May 2016

Beware, there might be VPN connections on those clients in which when they connect, there is no IP pool or DHCP available to assign IP address, therefore they receive APPIPA.








Just a guess.










Sent from my BlackBerry 10 smartphone.















show











And I believe you - but some machine in your environment has an active interface that's not getting an address, and it's likely that another interface on that same machine is trying to "help out".   (:-o





Something like this might prove useful to get all of the NICs and their IP addresses in your environment:


https://gallery.technet.microsoft.com/scriptcenter/Get-Network-Information-of-6d07766f/view/Discussions#content





Assuming that the APIPA address hasn't changed due to a reboot on the machine with the problem (or that someone hasn't disabled the NIC, given it an address, put it in a VLAN with access to a DHCP server etc), it shouldn't be too hard to match up the rogue

with the output from the above script.







Kurt





On Wed, May 4, 2016 at 2:30 PM, Mike Cramer

<mike.cramer@xxxxxxxxxxxxxxxx> wrote:








The DC itself does not have multiple NICs. Only a single NIC :P

 

From:

ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Matt Casey


Sent: Wednesday, May 4, 2016 17:24


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: Re: [ActiveDir] NOCLIENTSITE: 169.254...





 

I agree.  In my experience it's most often because one of the domain controllers has multiple interfaces and one is on the club but not disabled



On May 4, 2016 4:07 PM, "Kurt Buff" <kurt.buff@xxxxxxxxxxxxxxxx> wrote:









Um, I don't think this statement makes sense for most AD installations, if any.



After all, the 169.254/16 range is autoassigned by Windows to any interface that doesn't get an IPv4 address assigned either statically or dynamically.



Therefore


1) If you have more than one site, it's going to be pretty much impossible to assign that subnet to a site, because those addresses can appear anywhere, and


2) I would bet fairly large money that it's extraordinarily rare for anyone to route that subnet anywhere. Certainly I've never seen it routed. Not only that, most installations I've heard of treat them as bogons, to be squelched wherever they appear.





Generally, the appearance of an APIPA address in your environment means something is amiss.





 



Kurt





 



On Wed, May 4, 2016 at 10:04 AM, Venkat Suresh <venkatsp@xxxxxxxxxxxxxxxx> wrote:







Hi All,



 





169.254 appeared in Netlogon.log because there is no associated Site configured in subnets. Please configure 169.254 IP range in Sites ans Services Subnet and make sure it is pointing to correct Site. However if this IP address belongs

to any workgroup machine connects to network using VPN, thne no need to configure any subnets.





 





Venkat










From:

pbatchelor@xxxxxxxxxxxxxxxx



To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...


Date: Wed, 4 May 2016 12:42:35 +0000





 



If you’re using IBM gear, the internal RNDIS-over-usb adapter that connects to the management processor (IMM) for the machine can do this too. (it has, by default a 169.254 address).

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Kennedy, Jim


Sent: 04 May 2016 12:58


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...





 

Any Hyper V’s in the area…I have seen their virutual nics do that from time to time.

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Mike Cramer


Sent: Tuesday, May 3, 2016 4:41 PM


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...





 

I’m not exactly sure where the client was yet. I’m going to guess it wasn’t on the same VLAN as this particular server because the server itself sits in a lights out datacenter.

 

I haven’t ruled out networking issues….but I was wondering if anyone knew for sure. I didn’t think that the clients/servers reported this data itself (that would imply that the client first parses

the data and sends some information to the DC)…

 

I would have assumed based on how old this particular piece of code is that it’s just doing a raw read of whatever traffic comes in to the NetLogon service and recording the IP off the wire…

 

Which means that 169.254 would have gotten routed internally somehow…

 

Haven’t had much time to dig into it today, but I will! It’s very intriguing!

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Anthony Van den bossche


Sent: Tuesday, May 3, 2016 16:36


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...





 

I think that while booting, the client is trying to get a DHCP lease, but can’t and therefor tries to contact a DC.

 

@Mike: are you saying that the client was on a non-routed subnet? In that case this theory is useless

J.

 



Mvg,

 

Anthony Van den bossche


System Engineer


Anthony.Vandenbossche@xxxxxxxxxxxxxxxx



Direct

+32 (0)2 801 54 59


Description: Description: C:\Users\BJTAF40\AppData\Roaming\Microsoft\Signatures\realdolmen_logo.gif



This e-mail message and any attachment are intended for the sole use of the recipient(s) named above and may contain information which is confidential and/or protected by

intellectual property rights. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have

received this e-mail in error, please notify the sender either by telephone

(+32 2 801 55 55
) or by e-mail and delete the material from any computer. Please note that neither RealDolmen nor the sender accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. RealDolmen

is nor responsible for the correct and complete transfer of the contents of the sent e-mail, neither for the receipt on due time.



 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Danny CS


Sent: dinsdag 3 mei 2016 21:52


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...





 

Maybe a machine out there with a misconfigured NIC… seen that a few times.

 

~d

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Gil Kirkpatrick (gilkirkpatrick.com)


Sent: Tuesday, May 03, 2016 1:07 PM


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...





 

<scratches head> hmmmm. Are you sure it was that workstation?

 

-g

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Mike Cramer


Sent: Tuesday, May 3, 2016 12:07 PM


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...





 

Without digging too much into my network topology—it was an end user workstation that should, in theory, be on a different VLAN/Routed network…

 

So that makes it even scarier…

 

LOL

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Gil Kirkpatrick (gilkirkpatrick.com)


Sent: Tuesday, May 3, 2016 14:03


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] NOCLIENTSITE: 169.254...





 

That would be my guess… DHCP lease renewal failed for some reason for a device on the same switch.

 

-gil

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Mike Cramer


Sent: Tuesday, May 3, 2016 11:35 AM


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: [ActiveDir] NOCLIENTSITE: 169.254...





 

Would anyone know how I would have seen a 169.254 address show up in my netlogon.log on a DC? The obvious thought that somehow the traffic got routed or the system was directly on the switch—but it seems kind

of odd to me that this would show up.

 

Anyone?

 

-Mike Cramer



---------------------------------------------------------------------


BlackBerry UK Limited


Registered in England and Wales. Registered No. 04022422, with registered office at 200 Bath Road, Slough, Berkshire, SL1 3XE, United Kingdom



This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information

by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission

by unintended recipients is not authorized and may be unlawful.

















 

Close