In this continuation of the fourth article, we improve the design with enhanced security, performance, and efficiency. Our configuration consists of two OSPF areas 51 and 52, containing an Anycast DNS server, and pair of Cisco Routers connected to the backbone area 0.0.0.0. The Anycast DNS servers are configured with Quagga, running the OSPF routing protocol engine, this is used to advertise our two (2) Anycast DNS VIPs, 192.168.0.1/32 and 192.168.1.1/32 into the OSPF routed network. The diagram below focuses on our "fictitious" area 51:

anycast-dns-ospf-3

As mentioned, we'll provide additional "recipes" for improving our Anycast DNS design to achieve faster convergence and failover, added security, and better efficiency.

OSPF Authentication

In our previous article, we provided a basic recipe for setting up OSPF Anycast DNS. Now we need to lock it down and provide more and better security. OSPF neighbor adjacencies should be protected with some form of authentication to prevent unauthorized equipment and/or mis-configured equipment to affect routing. This is done using OSPF Authentication. Basically there are three types of supported OSPF authentication between Cisco and Quagga:

  • No Authentication
  • Basic Authentication (plaintext)
  • Cryptographic Authentication (using MD5)

We won't bother with the first two, because no authentication is no security, and Basic Authentication means that passwords traverse the network in the clear. To enable Cryptographic Authentication, ALL routers in the same area must be configured to support authentication.

Cisco:

R1-A(config)# interface FastEthernet0/1
R1-A(config-if)# ip ospf message-digest-key 1 md5 Passw0rd
R1-A(config-if)# exit
R1-A(config)# router ospf 100
R1-A(config-router)# area 0.0.0.51 authentication message-digest
R1-A(config-router)# exit
R1-A(config)# end

Repeat this on router R1-B.

Quagga:

server_a# config terminal
server_a(config)# interface eth0
server_a(config-if)# ip ospf authentication message-digest
server_a(config-if)# ip ospf message-digest-key 1 md5 Passw0rd
server_a(config-if)# exit
server_a(config)# interface eth1
server_a(config-if)# ip ospf authentication message-digest
server_a(config-if)# ip ospf message-digest-key 1 md5 Passw0rd
server_a(config-if)# exit
server_a(config)# end

Make sure our Anycast DNS server is able to build the adjacency with the upstream routers by performing a "show ip ospf neighbor" command. You should see two (2) neighbors that correspond to R1-A and R1-B. The same command can be run from each of the upstream Cisco routers as well.

OSPF Timers

OSPF has a pair of configurable timers that can be tweaked lower to improve stability and/or convergence behavior. This will improve our Anycast DNS failover time. The two parameters are:

  • hello timer - how often the router sends routine messages to its neighbor that indicates it is still up.
  • dead interval - the length of time a neighbor will hang on to a route in the absence of any hello messages.

OSPF defaults for the hello timer and dead interval are 10 seconds and 40 seconds respectively. A rule of thumb is to keep the dead interval 4 times the value of the hello timer. So, buy setting the hello timer to 5 seconds, we can safely set the dead timer to 20 seconds. It is important to set the timers on all directly connected routers.

Cisco:

R1-A(config)# interface FastEthernet0/1
R1-A(config-if)# ip ospf hello-interval 5
R1-A(config-if)# ip ospf dead-interval 20
R1-A(config-if)# exit
R1-A(config)# end

Repeat this configuration on router R1-B as well since its FastEthernet0/1 is directly connected to the same segment as the Anycast DNS server.

Quagga:

server_a# config terminal
server_a(config)# interface eth0
server_a(config-if)# ip ospf hello-interval 5
server_a(config-if)# ip ospf dead-interval 20
server_a(config-if)# exit
server_a(config)# interface eth1
server_a(config-if)# ip ospf hello-interval 5
server_a(config-if)# ip ospf dead-interval 20
server_a(config-if)# exit
server_a(config)# end

Save the configuration. Our upstream Cisco neighbors and our Quagga OSPF interfaces will send out hello packets every 5 seconds indicating they are up. Should either device stop receiving these hello packets, it will keep the routes in place up until the dead interval timer of 20 seconds. This effectively cut our convergence time in half to 20 seconds or less. It's very unlikely that these values would need to be set any lower.

OSPF Route Filtering

Now that we're sending hellos every 5 seconds, there's another tweak we could make to cut down on the traffic that is exchanged between our Quagga OSPF interfaces and the upstream Cisco router. Since our Anycast DNS environment ONLY needs to inject the 32-bit Anycast VIPs into the OSPF network, we don't need to fully exchange all OSPF routes that may be passed by the upstream routers.

We'll apply an outbound route filter to the Cisco device that essentially prevents any of the OSPF routes being learned by the Anycast DNS server. All it really needs to know is the default route to get off of its local subnet, and that is already covered through the use of IRDP. We covered that earlier in a prior article.

Cisco:

R1-A(config)# router ospf 100
R1-A(config-router)# neighbor 0.0.0.51 database-filter all out
R1-A(config-if)# exit
R1-A(config)# end

This same command can be applied to router R1-B to prevent OSPF routes from being learned by our Anycast DNS server.

We can also ensure that the only OSPF information that is sent by our Anycast DNS server is the 32-bit Anycast VIP addresses. This will ensure that our Quagga OSPF router doesn't send any additional routes that may cause problems.

Quagga:

server_a(config)# access-list 50 permit 192.168.0.1
server_a(config)# access-list 50 permit 192.168.1.1
server_a(config)# router ospf
server_a(config-router)# distribute-list 50 out connected
server_a(config-router)# exit
server_a(config)# end

This access list limits our Anycast DNS server to route only these two 32-bit host addresses.

Conclusion

In final, we've made our configuration more secure by using cryptographic one-way hashing (MD5) authentication between our upstream neighbors and our Anycast DNS servers. This will help prevent unauthorized routes from being injected into the network as part of our Anycast DNS design. The hello interval and dead interval OSPF timers were lowered to achieve better router convergence and ultimately faster Anycast DNS failover. Additionally, we minimized the amount of information that is exchanged our Anycast DNS servers and their upstream OSPF neighbors to the bare minimum. Additional tweaks can be made to make Anycast DNS using OSPF run even faster and with more resiliency, but it extends beyond our scope for this series. The next article in the series will be Anycast DNS - Part 5, using BGP.

References:

Cisco IOS Cookbook, 2nd Edition By Kevin Dooley, Ian J. Brown ISBN: 0596527225

Comments   

0 #6 C Y Chan 2012-04-10 12:58
Thanks! Great work! Do you have a osdfd.conf for setting up two servers with one Anycast DNS VIP (both servers having a lo:1)? Many Thanks. -CY
Quote
0 #5 CY Chan 2012-04-10 12:54
Nice works on explaining anycast DNS. Do you have an ospdf configuration for setting up two server with only one Anycast DNS VIP? Many Thanks! -CY
Quote
0 #4 Patrick Piper 2010-09-14 18:52
I have not seen DHCP implemented across Anycast addressing for the reasons you have already stated. Synchronization becomes a real problem when attempting DHCP over Anycast. Thanks for the question, it was a good one.
Quote
0 #3 eric cote 2010-09-14 18:47
I'm researching commercial DDI products. Currently, im focusing on BlueCat and plan to begin looking at Infoblox. My question is, im trying to think through a global DHCP design that could leverage anycast. If a DDI product can offer a grid or shared DHCP database, in theory, a request that failed locally could route upstream to the next available, upstream DHCP server. The shared database/ grid should then ensure duplicate IPs were not handed back to the client. Does this idea work and have you seen anycast used successfully for DHCP deployments?
Quote
0 #2 Patrick Piper 2010-06-11 09:13
Quoting Marco Davids:
Nice article, thank you for this.

A small word of advice though: please try to incorporate IPv6 examples along with IPv4 examples as much as possible.


Thanks Marco. I think that's a good idea, seeing that IPv6 is really starting to get traction these days.
Quote
0 #1 Marco Davids 2010-06-11 08:50
Nice article, thank you for this.

A small word of advice though: please try to incorporate IPv6 examples along with IPv4 examples as much as possible.
Quote

Add comment


Security code
Refresh