On 29/12/2013 20:48, Lorenzo Colitti wrote: > Is the size an issue here? Is there something about having tens of > thousands of IPv6 hosts that makes RAs unsuitable?
yes, size is an issue: it means that tweaking ns-interval is not feasible as a mechanism for dropping failover times. It also means that whatever solution is put in place needs to scale well Separate to this, it would be ideal to have host autoconfiguration both centrally managed and have a single configuration mechanism because doing it any other way is a pain. For me, that is. If you want to run medium-scale deployments like this with host autoconfiguration stuff in multiple places, then I'm ok with that because it's your network and I don't mind. > The alternative is to advertise RAs at the rfc-specified minimum interval > of 3s, giving a failover time of 10s. This isn't compatible with many > business cases. > > Why 10s? Have two routers send out RAs every 3 seconds and give them a > lifetime of 5 seconds. That should give you maximum 5s failover (average > 2.5s), because after 5s the RA will expire. and if your hosts miss a packet, you get traffic swinging to your other default. You may like to debug this sort of thing, but I operate in companies with non-telephone number cost constraints and have a strong need for operational simplicity and consistency. In other words, I don't want to set my network up with a default gateway that times out by policy every 5s because that is not a stable configuration. There's another issue: my intended deployment scenario is medium-scale third party vm hosting. If you have routers churning out RA packets, each host needs to process these packets simultaneously across all vms, network wide. This will increase cpu usage and resident memory requirement, maybe not by much per host, but bear in mind that this is intended to scale across tens of thousands of hosts. > The operator can drop a protocol, but the host implementer needs to > handle yep, exactly, but please bear in mind that networks are provisioned by operators for end-users. Network stacks are not written by host implementers for their own gratification. > 4. there is no way for RAs to deploy different gateways to different > hosts: > all hosts on the network must be configured in the same way. > > You can use unicast RA replies for that. doesn't scale. Routers are routers, not policy management engines. DHCP is for policy management and there is just no scalable way of handling this on routers. > 5. there is no way to specify anything other than a default gateway. > > What do you mean? If you mean there's no way to configure more specific > routes, RFC 4191 has allowed that since 2005. As Phillipp Kern kindly pointed out, I got this wrong. > 6. the failover characteristics of RAs are very poor by modern standards. > > > DHCP doesn't help there. If you want better than that, you need to use > something like VRRP anyway. Yes, I know: DHCPv6 + a first-hop routing protocol. This is the scenario I am interested in deploying. You know what? It works really well in practice. Nick
