Comments on ipSpace.net: IP renumbering in disaster avoidance Data Center d...

DNS: Remember that we're discussing cold migra...

2012-02-05T10:04:21.071+01:00

DNS: Remember that we're discussing cold migration here, not the "live worldwide mobility powered by unicorn tears". It usually takes a minute or more for the VM to be shut down and restarted in the other DC, and TTL values in tens of seconds are not unusual.

Long-distance VXLAN: forget it. It's the wrong tool for the problem http://blog.ioshints.info/2011/09/vxlan-otv-and-lisp.html

LISP and VM mobility? Coming soon ... 8-)

Running routing protocols on the servers is a fant...

2012-02-05T01:01:36.000+01:00

Running routing protocols on the servers is a fantastic solution; I don't understand why it isn't done more often.

1) the IP moves elegantly with the service
2) if your application is well written you can now go active active (anycasting)
3) DR testing is also a breeze -- bring up the test scenario on your live network but with the test node's route "slugged" (huge metric) so the local test systems see the DR test environment but nobody else sees it.

And if you're deeply afraid of server guys doing bad things to your routing table, you can always put all the servers into an unrouted vlan and put a "router" VM such as one from vyatta or something similar in front of that vlan and have that do the route advertisements.

I say it's time for datacenter servers to stop having static routes.

I honestly think load balancers are the best appro...

2012-02-04T15:32:47.543+01:00

I honestly think load balancers are the best approach currently. F5 showed a nice functional example during Tech Field Day 3, and it's the only moderately-convincing solution I've seen yet. But it's not optimal, with a massive trombone sometimes added and added latency of the device itself.

As for DNS, I'm really concerned about all the "optimization" that various clients and NAT devices do interfering with a short TTL. And how short practically can the TTL be, anyway? You don't want clients hitting your DNS server for every request, after all. And DNS solutions will still break sessions in progress.

What about some kind of long-distance distributed VXLAN? Have a virtualization-aware gateway in the network that maintains tunnels to the proper location. I guess I just invented a load balancer! :-D

Finally, where can I learn more about LISP? I keep hearing about it but know very little at this point.

Thanks, Ivan!

If you can change the end-device then there are al...

2012-01-27T06:52:25.635+01:00

If you can change the end-device then there are all sorts of other options. Unfortunately most of the time they tell you "NO".

But I was truly braindead yesterday - conversation-based learning is what LISP/NHRP do.

7. Upon the connectivity of an IP device to a clou...

2012-01-26T23:29:03.593+01:00

7. Upon the connectivity of an IP device to a cloud a register message would be required. Then you don't need ARP over the cloud. The nearest edge device could serve as a gateway. Other steps will be similar to FabPath. But c'mon, don't require the full description from me today. I've just started thinking it up. ;)

I am now considering another issue with a default route in such a solution. Whether to use the same mechanism as it is in 6rd or something else. I will get back to you within couple of months.

7. Conversational learning doesn't work @ L3 (...

2012-01-26T21:50:43.172+01:00

7. Conversational learning doesn't work @ L3 (no ARP broadcast ... but I might be braindead).

Also, in a totally masochistic design you could use BGP to propagate BGP next hops O:-)

7. Not exactly MPLS VPN. In Fabric Path there is a...

2012-01-26T21:37:08.685+01:00

7. Not exactly MPLS VPN. In Fabric Path there is a conversational learning and just one control protocol responsible for routing. :)

#2 - Wanted to write "host routes", not ...

2012-01-25T07:51:50.470+01:00

#2 - Wanted to write "host routes", not static (see below). Somehow a deleted comment resurfaced :(

#7 - Now you've reinvented MPLS/VPN 8-) Although we agree it would be a good solution, I don't see it happening for way too many reasons.

http://blog.ioshints.info/2011/04/vcloud-architects-ever-heard-of-mpls.html

2. Static routes are not necessary. A disaster rec...

2012-01-24T20:16:28.002+01:00

2. Static routes are not necessary. A disaster recovery DC can have the same addressing scheme as the primary one so rather connected/dynamic routes. Using LBs in the active/standby scenario is easier comparing to the active/active.

3. In this scenario it is fine if only loopbacks were used.

7. There is a major difference between such a future feature and existing IS-IS. The IS-IS topology is Switch-ID based not IP. It means that a switch in-between does not need to know IPs. All IPs could be divided using additional segment ID to allow virtualization. It doesn't have to be IS-IS. It can be BGP or another protocol which will create a cloud for connected IPs. Another version would be fully routed DC environment and LISP VM Mobility.

#1 - I was talking about cold VM migration. I have...

2012-01-24T19:47:34.066+01:00

#1 - I was talking about cold VM migration. I have stronger opinions about other migration options.

#2 - Think about it. If you have to advertise VIP prefixes, you're advertising host routes (or something similar).

#3 - Server loopback IP = fixed. Server LAN IP = DHCP. OSPF over LAN interface. Default route comes from DHCP or OSPF. What's wrong with this picture?

#7 - You just reinvented IP host routes carried in IS-IS (if you want to stay close to TRILL). Congratulations :-P

#1 - I was talking about cold VM migration. I have...

2012-01-24T19:45:03.317+01:00

#1 - I was talking about cold VM migration. I have stronger opinions about other migration options.

#2 - Think about it. If you have to advertise VIP prefixes, you're advertising static routes (or something similar).

#3 - Server loopback IP = fixed. Server LAN IP = DHCP. OSPF over LAN interface. Default route comes from next-hop router. What's wrong with this picture?

#7 - You just reinvented IP host routes carried in IS-IS (if you want to stay close to TRILL). Congratulations :-P

1. DNS can be an option for active/standby DCs but...

2012-01-24T18:19:25.448+01:00

1. DNS can be an option for active/standby DCs but it is not perceived as a fast solution for active/active DCs.

2. The only way to go? What about load-balancers? With a disaster recovery DC it is also an option. The secondary LB + edge router start advertising VIP prefixes after a switchover button is pushed.

3. It is not an option not because there is no routing on servers but because IPs of GWs are fixed.

6. The funny thing Proxy ARP is shown by the Cisco BU as a part of the LISP solution in the case of IP address movement. That's right that Proxy ARP solves only to-GW problem but from this point there is pure L3 network with the conditional advertisements/IP SLA/PfR and so on.

7. By saying 'Fabric-Path/TRILL for IP' I did not mean the existing feature. I will rephrase it in an another way. Imagine that a network of switches compose a topology based on Switch-IDs. This network behaves like L3 not STP. After connecting a host/server with IP this address will be advertised to other participants which require a connectivity. In such a way we could achieve a full mobility of IPs which will have /128 address. Hosts do not need to use GWs as all links could be point-to-point to the nearest SW.

Excluding some solutions flavors we are on the sam...

2012-01-24T18:17:32.077+01:00

Excluding some solutions flavors we are on the same page in terms of DC.

BTW, 'I might get invited' is not a case. You must be invited. 8-)

I forgot how many times I've been ranting agai...

2012-01-24T17:42:48.414+01:00

I forgot how many times I've been ranting against stretched subnets citing exactly these reasons.

BTW, I might get invited to PLNOG, in which case we can continue our discussion in a more pleasant environment.

#1 (DNS): use low TTL. The "only" proble...

2012-01-24T17:40:52.896+01:00

#1 (DNS): use low TTL. The "only" problem is that the web visitors might have to restart the browser session (even though DNS pinning is not as aggressive these days at is used to be).

#2 - if you want to retain IP addresses without stretching L2 subnets, host routes (or LISP) are unfortunately the only way to go.

#3 - We had routing protocols on servers 30 years ago. Come on ;)

#6 - I used to believe in Proxy ARP. No longer. Anyhow, it solves only server-to-GW problem, nothing more.

#7 - Don't even try to go there. Either you solve the problem on L3, and then you're back to LISP or host routes, or on L2, where you could easily use VXLAN (but we don't want split subnets anyway).

Ivan, this issue with a hard-coded IP it is not a ...

2012-01-24T12:44:48.193+01:00

Ivan, this issue with a hard-coded IP it is not a big deal in a disaster recovery data center. A bigger issue is with an active/active scenario. Even with load-balancers there will be problems with asymmetric routing which increases latency (it is very undesirable in mobile networks) and it is hard to manage on a firewall.

Hi Ivan, In terms of the listed solutions: 1. DNS...

2012-01-24T12:37:16.892+01:00

Hi Ivan,

In terms of the listed solutions:
1. DNS - customers complain about the reaction time. On the other hand disaster recovery does not require fast detection and a DNS refresh.
2. Hosts routes - harder to manage. LISP will be a good choice but it is emerging technology and more time is required.
3. Routing protocols on servers not an option at this moment but in the virtualized DC it is feasible. We can have not only firewalls, load-balancers, switches but also routing protocols running on the hipervisor.
4. Load-Balancers seem to be the best option listed. The global director or simply a router with a conditional route advertisement can do a prefix insertion.
5. NAT harder to manage and consumes resources unless the stateless translation is used. NAT is better to avoid not because it will not work but to leave it as the last resort solution in the case of problems to IPv6 migration.

Another options:
6. Proxy ARP + L3 Edge. There are some security drawbacks especially if a firewall is in between but it is considerable.
7. Fabric-Path/TRILL for IP. In this option DC is fully L3 routed. There is no such standards nowadays but we could create it. ;)

"zoning" is the key term to firewalling ...

2012-01-23T09:18:26.529+01:00

"zoning" is the key term to firewalling there, you simply don't create any per host rules. You can have firewalls that are aware of networks on your other sites. State table handling is different box of worms.

#1 - Seems we're continuously running around i...

2012-01-22T10:59:51.623+01:00

#1 - Seems we're continuously running around in circles, eventually landing at http://blog.ioshints.info/2009/08/what-went-wrong-socket-api.html

#2 - Absolutely agree.

Don't blame Apache for utilizing the OS socket...

2012-01-22T03:44:05.721+01:00

Don't blame Apache for utilizing the OS socket library and having the same limitations. Besides, if you bind to * and run one IP per VM it should be a non-issue.

Simply had to check Apache documentation: * Virtu...

2012-01-21T20:15:12.409+01:00

Simply had to check Apache documentation:

* Virtual hosts can use DNS FQDN
* Listen directives seem to use only IP addresses, not interface names or DNS FQDN.

No comment :( ... and I thought Apache web server was a shining example of good programming.

Hey Ivan, I'm working on a large scheme like ...

2012-01-20T17:30:06.465+01:00

Hey Ivan,

I'm working on a large scheme like this now.

Moving the subnet without re-numbering as you suggest seems natural, but makes DR *testing* really complicated, so my customer is on the "change IP numbers" track.

Here are some complications that DNS can't solve:
- multiple security zones in the data center? DNS doesn't help the firewalls much.
- reconfiguring the VM's IP is easy (VMware SRM does this), but reconfiguring application listen directives (think apache config file) is not easy. lots of custom per-application scripting work is required.

Vendors like to claim their offerings are turn-key DR. Customers who believe it will be disappointed :-)