Jitender Arora writes: > Jitender--> Currently we are using this approach (basically using > the redirect and the Mobike). > > This is causing the following issues: > > 1. If the redirect message is handled by the Load Balancer, the > load balancer needs to be IKEv2 aware and also it needs to know the > IP addresses of the Security Gateways for which it is responsible. > This can cause the performance issues as the Load Balancer should > not be application aware and should do the load balancing based on > the layer 3/layer 4 information.
Load balancer by definition needs to know the devices where it is sharing the load to, so I do not consider that a problem. Also if the redirection is done in the IKE_SA_INIT phase then the application support required is very minimal. Also there is no need that the load balancer itself needs to be acting as application gateway, the published IP address for the IKEv2 connections can also be some other IP-address, i.e. that host does not need to be on the path of the real traffic. If this one host is only parsing IKE_SA_INIT packets and sending redirect backs any old 386 box you can find from your junk pile will be able to handle the traffic up to millions of clients (million clients, each connecting for example once per hour means there is 277 connection attempts per second, and any old box can receive 277 udp packets and send 277 udp replies back (in completely stateless manner)). > 2. If the Load Balancer passes this IKEv2 messages directly to the > security gateways using the layer 3 information, the security > gateway will then have to send the redirect to the client back > through the LoadBalancer and telling the client to talk to different > address now. This again causes an extra message exchange to achieve > the load balancing. Those extra messages only happen during the setup phase, and I would expect the load balancer can pass through those less than 300 messages per second. If it cannot, then you have much bigger problems when the real traffic starts to come in... > Jitender--> I think, I did not make this clear, the Load Balancer > will not take care of the IKEv2 traffic, it will just pass through > the IKEv2 traffic to the security gateways without handling them. > But all the IKEv2 traffic will have to go through this load balancer > so that the IKEv2 signaling can take place between the same > addresses. So if the load balancer cannot handle few hundred packets per second to passthrough then I think you should really consider replacing the hardware. For normal IPsec use the IKEv2 packet are not send periodically at all. There is 2+2 packets in the beginning. There might be one DPD exchange over IKEv2 SA when the ESP traffic stops, but after that there shouldn't be anything until the ESP traffic restarts. So there should very little IKEv2 traffic, and in normal case it is limited to about 6 packets in total over the whole lifetime of the IKEv2 SA. > In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together, > and running them on separate machines is very complicated (We just > had long discussion about this on the list, i.e. what kind of > failure models can happen and what cannot happen). > > Jitender--> If this has been captured somewhere, can you please > point us to that link. http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec