Archive

Posts Tagged ‘server’

DNS netmask ordering

March 19th, 2014 No comments

One customer has two physical locations. Here is following IP setting for both locations:

Location 1 – IP range 10.0.0.0/23 and wpad server is 10.0.0.22

Location 2 – IP range 10.0.2.0/24 and wpad server is 10.0.2.22

When you create two same A records in DNS you get two IP addresses on DNS query. Order of DNS record is changing, because we have Round Robin enabled on our DNS servers. This is default behaviour.  Here is some testing with nslookup:

Same results were in both locations. What we wanted to achieve was that we need DNS servers to return IP address 10.0.0.22 in location Location 1 on first place and IP address 10.0.2.22 in location Location 2 on first place. To make it work we need to look on feature called netmask ordering on DNS servers. You can read more here.

Let’s transfer IP addresses in each location into binary:

10.0.0.0/23

00001010.00000000.00000000.00000000 — 00001010.00000000.00000001.11111111

10.0.2.0/24

00001010.00000000.00000010.00000000 — 00001010.00000000.00000010.11111111

Networks in both locations are same to 22 bit from begging. First different bit in 23rd. So we need to change netmask ordering on DNS server to use first 23 bits to compare when returning results to client. It means our netmask ordering has to be set to:

00000000.00000000.00000001.11111111 — 0x000001FF

We need to set it on all DNS server and restart DNS service:

Once we do this on server we can see following result in Location 1:

and following result in Location 2:

So now it’s all set and ready to go.

Have a great day,

News in DHCP client since Windows 7

September 26th, 2013 No comments

Imagine you have DHCP server on network. You have all Windows XP and older clients. When DHCP server was not accessible on network during client’s startup, client computer couldn’t get IP address and it assigned APIPA address. This was a problem. So let’s look what’s new since Windows 7.

I prepared following scenario:

  • One DHCP server Windows Server 2012 – 192.168.0.10
  • One DHCP server Windows Server 2012 acting as default gateway – 192.168.0.11
  • One Windows 8 client – DHCP assigned
  • One Windows 7 client – DHCP assigned

When I client wants to get TCP/IP settings from DHCP server, there are four DHCP packets (DISCOVER, OFFER, REQUEST and ACK) going on network. Network dump on DHCP server:

This is normal behaviour even in old clients. Now I shutdown client and stop DHCP server. When I started client computer I found out that client computer has IP address it received from DHCP server before reboot.

So let’s restart client again and see what happends. Client computer has same TCP/IP settings, it had before reboot (TCP/IP settings received from DHCP server before I stopped DHCP server). Client computer keeps asking DHCP server to renew TCP/IP settings (using DHCP REQUEST):

So how client computer knows if it has to set cached TCP/IP settings before DHCP server stopped to respond? I assume it depends on gateway and its IP or MAC address. So let’s disconnect gateway from network and reboot client computer. Now client has APIPA TCP/IP settings and it looks for DHCP server by DHCP DISCOVERY:

It means it depends on health of gateway if client keeps TCP/IP settings assigned by DHCP or not. I haven’t seen any ICMP packet to check network healt of gateway so I assume it check MAC address. So let’s look for ARP packets from client to gateway. Looks like client asks for MAC address of saved default gateway IP address. When it received answer, it sets TCP/IP settings to cached TCP/IP settings:

Question is if client computer compares MAC address to some saved one or it just waits for ARP response and doesn’t care of MAC address. Let’s change MAC address of default gateway. Client keeps asking via ARP for MAC address. MAC address is different and client doesn’t set its saved TCP/IP settings (it sets APIPA settings):

So where client computer saves MAC address of default gateway?

Yes, in registry. 🙂 It’s saved under registry key:

and there are subkeys for each interface and under this key there is binary value called DhcpGatewayHardware which contains MAC address:

When client starts it checks for MAC address of its saved default gateway IP address. Then it compares to saved MAC address from registry. If these two MAC addresses don’t match, client deletes all saved TCP/IP settings from registries and uses APIPA (if there is not Alternate Configuration). In background it still looks for DHCP server by sending DHCP DISCOVER packets.

So now we have smaller problem on Mondays when DHCP server is down (of course by accident 🙂 ) and everyone is trying to get to network resources 🙂

I haven’t find any article about this new behaviour on oficial Microsoft websites.

That’s all folks,

 

Very very bad support from Meinberg getting better?

November 23rd, 2012 No comments

Last two weeks I had to update some NTP servers from one German company. When I requested new firmware I received following e-mail:

Dear Sir,
 unfortunately, I cannot provide a new firmware since your compact flash card is too small and the action might end up in a system’s inconsistency.
Thus, you are also not the only customer who is affected by this, we offer bigger compact flash cards for 65€ each. Please let me know whether this is of interest for you and if you need an official offer.
Mit freundlichem Gruß / With kind regards
 

So this made my very upset. To be able to upgrade to the newest version of firmware I had to pay 65EUR for new flashcard. So I wrote couple e-mail to this company. I wanted to know the reason why I need to invest more to NTP server. I found out that firmware got big and it cannot be uploaded into flash which came with NTP server. This looked weird to me. Why would I have to invest into device if manufacter’s engineers made a mistake. I already decided not to sell manufacter’s devices. And I though that was end of the story.

Today I received following e-mail:

Dear Ondrej,
 
I just wanted to let you know that we dramatically improved our update procedure and, after an intensive clean-up, released
the new firmware version 5.34h which can be installed on 64MB compact flash cards without any problems. The new release is 4 MB (~25%) smaller (!) than the previous version without removing any features.
 
Although you already expressed your extreme dissatisfaction with our products and decided for yourself to not recommend or
buy Meinberg products in the future, your feedback helped us to improve our software and I sincerely thank you for that.
 
Best Regards,
 Heiko
 

So it’s funny how some angry and mad e-mails can change such a things. Now we can upgrade our devices. But I don’t think we will offer them anymore to customers 🙂