Management IP also follows learned/default routes and is not affected by route-maps. Actually, the name of the feature here isn't "route-maps" per-se, it's "policy-based routing for reverse slb traffic".
>From my experience, management and ICMP to a VIP both follow the learned/default routes. Only reverse SLB traffic actually follows the route-map. Thanks, Jared -----Original Message----- From: Lazuardi Nasution [mailto:[email protected]] Sent: Monday, December 14, 2009 1:26 PM To: Jared Valentine Cc: Jack Stewart; [email protected] Subject: Re: [f-nsp] Multiple VIPs with Different Subnets Hi Jared, I think you are right regarding to ICMP. I have tried but failed. What about Management IP. It seem to be failed too. Best regards, On Tue, Dec 15, 2009 at 3:18 AM, Jared Valentine <[email protected]> wrote: > ICMP to the VIP won't work if the VIP uses a route-map, even if it's > included in the ACL. It's just a limitation of the ServerIron. It should > continue to work for VIPs that aren't affected by the route-map and are > following the default and/or dynamic routes. > > Jared > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jack Stewart > Sent: Monday, December 14, 2009 12:55 PM > To: Lazuardi Nasution > Cc: [email protected] > Subject: Re: [f-nsp] Multiple VIPs with Different Subnets > > > Congratulations! In sounds like you are beginning to get route-maps. > This is no small think. Every book that I've read so far says > "route-maps are beyond the scope of this book but here are some neat tricks" > > Hmm. I'm going to have to lab both of these tomorrow to be 100% sure. > > ICMP should be pretty straight forward, you should just need to add an > ACL to your route map to premit ICMP (all you are letting through is IP). > > Cookie Switching looks interesting and it is on my to do list to look at > - I'll have to consult with my web guru. My guess is that the cookie is > getting used by the switch to tell it which which to go to. It looks > like cookie switching is trumping route maps on a first match basis. > > You've probably already thought of this but what about forcing this data > to be ssl and then using session-id-switch for future connections? It is > a unique client/server keypair. If the customer you are worried about > comes from the big NAT/Proxy box, you can force their connections to be > written into SSL (mod_rewrite on the server) > > Just a thought. > > Ciao, > > ---Jack > > > Lazuardi Nasution wrote: >> Hi Jack, >> >> I have implemented route-maps. It is OK until I do cookie switching. >> When I put cookie-switching, the second VIP never response the HTTP >> request. The connection is OK but no response. If I remove the >> cookie-switching, the traffic is normal again. I need the >> cookie-switching for handling the clients behind big NAT/Proxy and >> make sure that the request switched to the same server on the event of >> link state changes. >> >> Beside that, it seem that route-map cannot work for ICMP. I still >> cannot Ping to second VIP. >> >> Best regards, >> >> On Mon, Dec 14, 2009 at 6:57 AM, Jack Stewart <[email protected]> > wrote: >>> Hi Lazuardi, >>> >>> Setting up a DNS response strategy seems like a good option - the idea is >>> sound and it is the foundation for GSLB for many vendors. I've read about >>> GSLB but never implemented it. >>> >>> I applied route-maps to the management IP subnet for giggles and removed > the >>> default route. It works but I suspect it isn't a best practice. A > route-map >>> is more like pre-routing table. If you get a match in the route-map, then >>> the specific action is applied. Otherwise, it goes to the routing table. >>> Another way of thinking about it is that route-maps (or policy routing) > have >>> the better metric but you still have your default and static routes. >>> >>> Your setup isn't something that I've done but as long as it works, stick >>> with it. In my situation I have two class C subnets that are part of a >>> larger class B and default routes couldn't do the job. >>> >>> Route maps are pretty cool and now that I understand them, I'm currently >>> exploring PBR as a mechanism for handling Email flows differently based > on >>> source. Load balancing using DNS is way down the road for me. >>> >>> Cheers, >>> >>> ---Jack >>> >>> >>> Lazuardi Nasution wrote: >>>> Hi Jack, >>>> >>>> Is this route-map can be applied to Mangement IPs ? >>>> >>>> Currently, I have put two default gateway with different distance for >>>> both subnet. For avoiding the access to non default gateway VIP, I >>>> have put different set of DNS for each VIP. This way can push the >>>> clients to always use VIP A if the DNS come to VIP A (lower distance >>>> subnet) by using VIP A IP for all DNS records bound with VIP A and >>>> vice versa. If DNS query is coming to VIP B (higher distance subnet), >>>> the reply will never acknowledged by the clients since it will be >>>> routed through the VIP A. This way can make only VIP A will do the >>>> good reply as long the ISP A link is good. >>>> >>>> Best regards, >>>> >>>> On Sun, Dec 13, 2009 at 8:18 AM, Jack Stewart <[email protected]> >>>> wrote: >>>>> Hi Lazuardi, >>>>> >>>>> You are correct in saying that you need VIP's on both subnets. Only a > VIP >>>>> subnet A can use ISP A and only a VIP on Subnet B can use ISP B. >>>>> >>>>> With ISP A as your default route, VIPs on Subnet A work just fine. The >>>>> load >>>>> balancer sees the destination address of the client and sends it to the >>>>> default route. But when the real server sends return traffic for a >>>>> traffic >>>>> that came in from VIP B, the routing table tells it to go to the > gateway >>>>> for ISP A. Somewhere along the path the return traffic will get dropped >>>>> into >>>>> the bit bucket. A route-map can fix this. >>>>> >>>>> A route-map with the "ip policy route-map" command applies a set of > ACL's >>>>> and route related actions to traffic before the load balance looks at > the >>>>> routing table. Route-maps have precedence. In an earlier example below, > I >>>>> took advantage of using an extended ACL in order to force the return >>>>> traffic >>>>> for a VIP on subnet B to go out through the Gateway B. The load > balancer >>>>> changes the source address of the real server to the VIP, my route map >>>>> saw >>>>> that the source address of the VIP was on subnet B, and so it set the >>>>> next >>>>> hop to Gateway B. The destination address and default gateway did not >>>>> matter >>>>> for this traffic. >>>>> >>>>> This is a pretty terse description, let me know if it is along the > right >>>>> track and we can get into details off line if needed. >>>>> >>>>> The web is a can of worms. Is the content dynamic or static? Is the >>>>> traffic >>>>> encrypted or is it not encrypted? There are a lot of different tricks. > I >>>>> would start with the basics - don't worry about it unless it is a > problem >>>>> or >>>>> you know will be a problem. For the most part the client will cache the >>>>> destination IP for a period of time and most web content is static. > Also, >>>>> are we talking encrypted or unencrypted traffic? If it is encrypted you >>>>> can >>>>> go off of the ssl session id. If this is really a problem, I'll put on > my >>>>> sysadmin thinking cap but I'll need to know O/S, http. For example, >>>>> Apache >>>>> 2.2 has a mod_header module so that you can set the particular server. >>>>> This >>>>> only applies to unencrypted traffic as the load balancer can't decrypt >>>>> it. >>>>> >>>>> Lazuardi Nasution wrote: >>>>>> Hi Jack, >>>>>> >>>>>> I'm interested with route-maps. Can you tell me more about that ? >>>>>> Currently I just using static route for two default gateway with >>>>>> different distance. >>>>>> >>>>>> My requirements is simple, just to do server load balancing no matter >>>>>> where the traffic come in. Since I have two ISPs which give me two >>>>>> subnets, so I think I must have two VIPs on different subnets too. I >>>>>> need Cookie Switching since some of clients are behind the proxy or >>>>>> NAT. I cannot use Source NAT since I have to preserve clients source >>>>>> IP for logging purpose on the real server. Since I don't have to do >>>>>> the link load balancing, I do static routing for default gateway, so >>>>>> only single link will be bidirectional on the same time. But I don't >>>>>> have any idea how to make those VIPs share the session table or at >>>>>> least threat the request not as first request if there is related >>>>>> cookie inside (ex. ServerID). If I can do that I'm sure I can switch >>>>>> the request to the same real server no matter which VIP the request >>>>>> come in. >>>>>> >>>>>> Any idea ? >>>>>> >>>>>> Best regards, >>>>>> >>>>>> On Fri, Dec 11, 2009 at 4:19 AM, Jack Stewart <[email protected]> >>>>>> wrote: >>>>>>> Hi Lazuardi, >>>>>>> >>>>>>> I'm running the routing code. To the best of my knowledge, route-maps >>>>>>> apply >>>>>>> only to the routing code. >>>>>>> >>>>>>> route-maps allow you to set the gateway by source address, > destination >>>>>>> address, or port #. Static routes allow you to set gateway by >>>>>>> destination. >>>>>>> The VIP is the source address of the outgoing traffic. So in the >>>>>>> example >>>>>>> below, gateway for a VIP is based on its address (and not the >>>>>>> destination >>>>>>> client). This was a really hard concept for me to wrap my head > around. >>>>>>> >>>>>>> It isn't clear to me that your case is the same. My setup is very >>>>>>> atypical. >>>>>>> I had a lot of trouble debugging it (traffic would leave the client > but >>>>>>> never come back to it). You might be able to get at it by looking at >>>>>>> the >>>>>>> interface traffic of the gateways. >>>>>>> >>>>>>> Let me know the solution you come up with, I'm curious. >>>>>>> >>>>>>> ---Jack >>>>>>> >>>>>>> Lazuardi Nasution wrote: >>>>>>>> Hi Jack, >>>>>>>> >>>>>>>> I think this solution is for Switch Code since with Router Code I > can >>>>>>>> have many Management IP even with different subnets. The default >>>>>>>> gateway can be specified statically on the routing table or by using >>>>>>>> routing protocol from the routers. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> On Fri, Dec 11, 2009 at 2:25 AM, Jack Stewart <[email protected]> >>>>>>>> wrote: >>>>>>>>> Hi Lazuardi, >>>>>>>>> >>>>>>>>> I ran into similar issues - this is what ultimately work in my >>>>>>>>> environment. >>>>>>>>> It may not be the same but hopefully there are some takeaways. > Please >>>>>>>>> let >>>>>>>>> me >>>>>>>>> know how much of this makes sense - that feedback will be helpful >>>>>>>>> with >>>>>>>>> my >>>>>>>>> documentation. >>>>>>>>> >>>>>>>>> First, DNS is special and the following is generic. >>>>>>>>> >>>>>>>>> You can only have one management IP and one default route. The >>>>>>>>> management >>>>>>>>> IP >>>>>>>>> should live on the same subnet that has the default route. The > first >>>>>>>>> public >>>>>>>>> subnet with the management IP & default route (Pub_Subnet_1) was > not >>>>>>>>> a >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> All of my real servers are on a different private subnet that the > two >>>>>>>>> public >>>>>>>>> subnets and they all have the Load Balancer defined as their > default >>>>>>>>> gateway. >>>>>>>>> >>>>>>>>> To get subnet 2 (pub_subnet_2), I needed to define a router > interface >>>>>>>>> for >>>>>>>>> that subnetwork (ve2) and policy routing/route-maps. The route-maps >>>>>>>>> are >>>>>>>>> for >>>>>>>>> making sure that the return traffic goes out via the same gateway >>>>>>>>> that >>>>>>>>> it >>>>>>>>> came in for non directly attached subnets. The way the mapping > works >>>>>>>>> for >>>>>>>>> me >>>>>>>>> in the configuration is: >>>>>>>>> >>>>>>>>> ! >>>>>>>>> ip access-list extended match_pub_subnet_2 >>>>>>>>> permit ip match_pubsub2/24 any >>>>>>>>> ! >>>>>>>>> route-map more_default_routes permit 10 >>>>>>>>> match ip address match_subnet_2 >>>>>>>>> set ip next-hop subnet_2_gateway >>>>>>>>> ! >>>>>>>>> ip policy prefer-direct-route >>>>>>>>> ip policy route-map more_default_routes >>>>>>>>> >>>>>>>>> In route-maps, the 'permit #' is just the precedence order. You can >>>>>>>>> add >>>>>>>>> additional entries to a route-map. Route-maps are processed before >>>>>>>>> static >>>>>>>>> routes. >>>>>>>>> >>>>>>>>> Lastly, I defined an outside NAT policy on Public_Subnet_1 for >>>>>>>>> traffic >>>>>>>>> originating private subnet traffic (i.e. directly attached > servers). >>>>>>>>> I'm >>>>>>>>> not >>>>>>>>> 100% sure this is a requirement but it helps with traceroute, etc. >>>>>>>>> >>>>>>>>> In my case it was necessary to add VRRP but that is because I've > more >>>>>>>>> than >>>>>>>>> one box and it isn't clear you need that. >>>>>>>>> >>>>>>>>> Once this was done, everything worked nicely from outside to > inside. >>>>>>>>> >>>>>>>>> This is a global static approach. Most people seem to route-maps to >>>>>>>>> filter >>>>>>>>> routing protocols, but I'm not allowed to exchange LB routing >>>>>>>>> protocols >>>>>>>>> with >>>>>>>>> our routers by policy. >>>>>>>>> >>>>>>>>> For VIPs and real servers on the same private subnet, I found that >>>>>>>>> either >>>>>>>>> DSR or source-nat with ACL's works well. If you are using DSR with >>>>>>>>> Linux >>>>>>>>> (it >>>>>>>>> seems to apply to other 2.6 kernels), you'll probably want to look > at >>>>>>>>> the >>>>>>>>> brocade wiki). >>>>>>>>> >>>>>>>>> With DNS, source-nat with ACL's is probably the simplest and easier >>>>>>>>> way >>>>>>>>> to >>>>>>>>> go. >>>>>>>>> >>>>>>>>> ---Jack >>>>>>>>> >>>>>>>>> Lazuardi Nasution wrote: >>>>>>>>>> Hi Jack, >>>>>>>>>> >>>>>>>>>> Yes, there is different router per subnet and I have done the > static >>>>>>>>>> routing for that. VIP1 is in the same subnet with Management IP > and >>>>>>>>>> the Router1 is connected to eth1, so I just simply put Management > IP >>>>>>>>>> on eth1. Since Router2 is connected to eth2, should I do something >>>>>>>>>> on >>>>>>>>>> eth2, ex. put another management IP on the eth2 which is in the > same >>>>>>>>>> subnet with VIP2 ? The other ethernet ports are for Real Server so > I >>>>>>>>>> have give ve1 for those ports. >>>>>>>>>> >>>>>>>>>> There is another weird problem. I have made DNS binding from VIP1 >>>>>>>>>> and >>>>>>>>>> RE1 and I have put ve1 IP in the same subnet with RE1. RE1 default >>>>>>>>>> gateway is ve1 IP. I can query the DNS through VIP1 but RE1 cannot >>>>>>>>>> do >>>>>>>>>> traceroute to the Internet, stuck on the ServerIron. What's happen >>>>>>>>>> here ? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> On Thu, Dec 10, 2009 at 3:41 AM, Jack Stewart > <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> Hi Lazuardi, >>>>>>>>>>> >>>>>>>>>>> Yeah! A question that might be up my alley. I've done this > however >>>>>>>>>>> I >>>>>>>>>>> need >>>>>>>>>>> some more details. >>>>>>>>>>> >>>>>>>>>>> Do these VIPs need different "static" default gateways on a per >>>>>>>>>>> subnet >>>>>>>>>>> basis? It's possible with the routing code and I can send out the >>>>>>>>>>> details >>>>>>>>>>> if >>>>>>>>>>> you are interested. >>>>>>>>>>> >>>>>>>>>>> Otherwise the main trick with subnet A to subnet B traffic is to >>>>>>>>>>> make >>>>>>>>>>> sure >>>>>>>>>>> that the return traffic goes though the load balancer. The client > & >>>>>>>>>>> server >>>>>>>>>>> need to see the Load Balancer as the gateway between subnet A & >>>>>>>>>>> subnet >>>>>>>>>>> B. >>>>>>>>>>> DSR and source NAT are also options. >>>>>>>>>>> >>>>>>>>>>> So more details, please. Depending on what you need to do it > might >>>>>>>>>>> help >>>>>>>>>>> knock out some of my documentation. >>>>>>>>>>> >>>>>>>>>>> ---Jack >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Lazuardi Nasution wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Is it possible to have multiple VIPs with different Subnets on >>>>>>>>>>>> ServerIron 4G or ServerIron ADX1000 ? How can I do that ? I'm >>>>>>>>>>>> using >>>>>>>>>>>> router code of firmware. >>>>>>>>>>>> >>> -- >>> Jack Stewart >>> Academic Computing Services, IMSS, >>> California Institute of Technology >>> [email protected] >>> 626-395-4690 office / 626-437-6035 cell > > -- > Jack Stewart > Academic Computing Services, IMSS, > California Institute of Technology > [email protected] > 626-395-4690 office / 626-437-6035 cell > _______________________________________________ > foundry-nsp mailing list > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp > > _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
