[c-nsp] Need some guidance for T1 / wireless ethernet handoffload balancing/failover setup
Ben Steele
ben.steele at internode.on.net
Tue Aug 19 10:43:50 EDT 2008
omg terrible formatting, apologies everyone! damn webmail client...
----- Original Message -----
From: <ben.steele at internode.on.net>
To: <cisco-nsp at puck.nether.net>; "Scott Lambert" <lambert at lambertfam.org>
Sent: Tuesday, August 19, 2008 1:25 PM
Subject: Re: [c-nsp] Need some guidance for T1 / wireless ethernet
handoffload balancing/failover setup
> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
>
> Hi Scott,
> Try this:
> Seeing as you are working statics over your wireless cloud to
> simplify things a little setup a GRE tunnel from your 7200 over the
> wireless to the 1841 (don’t forget to subtract 24 bytes off the MTU,
> ie if it's a 1500 path put ip mtu 1476 in the tunnel interface and
> also add keepalives so it will actually go down if it is down), and I
> assume your T1 is point to point from the other 1841 to the 7200.
> Now assuming this is going to be a redundant configuration as well
> as load-balanced you need to have a subnet that can float between the
> 2 links that your customer can NAT against (which by the way will
> happen on the ASA they got sold), there are 2 ways you can achieve
> this, 1 is by using ip sla to monitor the next hop of each of the
> customer links from your 7200 with statics, the other is private BGP,
> you sure as hell don't want to start running an IGP to your
> customers(unless it's MPLS VPN).
> Lets say you assign your customer 1.0.0.0/27 as their usable
> floating subnet and the T1 is 2.0.0.1/30 at your end and your GRE
> tunnel(wireless) is 2.0.0.5/30 at your end.
> Setup ip sla with icmp echo to 2.0.0.2 and 2.0.0.6 (each in their
> own rtr group of course, say 1 and 2 respectively).
> Ip route 1.0.0.0 255.255.255.224 2.0.0.2 track 1 Ip route 1.0.0.0
> 255.255.255.224 2.0.0.6 track 2
> Hope that makes sense, essentially traffic will only route to your
> customer if your 7200 can ping their respective 1841, the other
> private BGP option I am going to assume you are already familiar with
> being in an ISP.
> Now for the customer to you.
> AFAIK the ASA cannot load balance it can only forward out 1
> interface at a time.
> So what you need to do is put the ASA and the 2 1841 interfaces into
> a switch so they can all see each other at layer2, now setup hsrp on
> your 1841 interfaces for redundant gateways lets say you use
> 1.0.0.1(t1),1.0.0.2(wireless),1.0.0.3(hsrp), now the next part is a
> little trickier, I am going to assume your T1 is your primary link for
> this example but you can switch it around if you want.
> On your T1 1841 add a static route for the wireless /30 to go via
> the LAN interface of the Wireless 1841(ip route 2.0.0.4
> 255.255.255.252 1.0.0.2, you should now be able to ping the ISP end of
> the wireless link from your T1 1841, you want to setup ip sla to
> monitor the ISP end of the wireless link from your T1 router(ie the T1
> router is monitoring 2.0.0.5) and you also want to monitor its end of
> the T1 link aswell 2.0.0.1
> What this does is let your primary gateway know that it has a
> complete and valid path for both gateways for redundancy.
> Now you add 2 static routes with tracking on your primary 1841
> Ip route 0.0.0.0 0.0.0.0 2.0.0.1 track 1 Ip route 0.0.0.0 0.0.0.0
> 1.0.0.2 track 2
> Your wireless 1841 need only have the 1 gateway via its wireless
> tunnel as it should only ever fall over to that router if there is a
> serious problem on the primary side so you don't want it routing back
> that way anyway, however make sure you enable pre-empt so it fails
> back to the primary once it is back up.
> You can optimise this a little further with the global command "ip
> cef load-sharing algorithm include-ports destination source" or if
> your game you can even do per-packet load sharing however i wouldn't
> recommend it as your 2 paths are going to have different
> characteristics, id probably just try the method i listed first.
> As mentioned previously the ASA config will just be straightforward,
> NAT/PAT against some pool in 1.0.0.0/27 with a default route to
> 1.0.0.3(hsrp), nothing more to it, the 1841's will do all the
> redundancy and load balancing.
> Hope at least some of that made sense, if you need clarification on
> anything let me know.
> Cheers
> Ben
> On Tue 19/08/08 9:06 AM , Scott Lambert lambert at lambertfam.org sent:
> I have a customer who went directly to cisco to ask about how to
> load
> balance two WAN connections to their Cisco PIX 515E. Cisco sold them
> an
> ASA 5510 and two 1841s and suggested VRRP or GLBP for the LAN with
> the
> ASA and 1841s. Apparantly, the customer didn't even mention that the
>
> two connections were to the same ISP, me. The customer just ordered
> the
> equipment and said "Make it work."
> The WANs are T1 (existing) and 4Mbps ethernet delivered via a
> wireless
> network.
> Cisco sales tech guy said:
> > What we discussed was the ASA having a default route to the
> virtual
> > IP address of the routers and they would be running either VRRP or
>
> > GLBP (whatever they decided they wanted to do) going out to the
> > service provider. Then the routers would simply have a default
> route
> > going out to the service provider to hit the 'Net.
> The network design is supposed to be something like :
> Cisco 7204VXR NPE G1 (ISP)
> | |
> T1 Wireless network cloud
> | |
> Cisco 1841 Cisco 1841
> | |
> -+-------+--------+-
> |
> Cisco ASA 5510 (Customer)
> The wireless network cloud is creating logistical issues for me. The
>
> wireless ethernet makes multiple hops through StarOS based routers
> which do not speak OSPF, yet. I have to staticly route traffic to
> the
> wireless cloud. The wireless network is handled by a different group
>
> here and I don't have much influence over how they run it.
> I've been running ISP routers for 10 years, but have not had this
> configuration come up before. 99.9999% of my customers have been
> single
> homed to me. Also, ASA/PIX devices haven't been common for me until
> the
> past couple of years and I keep running into areas where they seem
> to
> try very hard to avoid having common routing features. I'm primarily
> a
> servers guy but when you work in small ISPs, you get to do
> everything.
> I could use some guidence in the best way to make these links load
> balance with graceful degradation if one link should fall down.
> I've been considering bringing up an IPSec VPN from the 7204VXR to
> the
> 1841 handling the wireless ethernet connection, just to bypass the
> need
> for dynamic routing in the wireless network. Then I could run OSPF
> or
> other magic between the 1841s and my 7204.
> Is OSPF going to be enough to load balance the links, or will I need
>
> something else?
> If not, could an MLPPP bundle be brought up which uses the T1 and an
>
> IPSec tunnel? But then, how would I use the 1841s redundantly?
> To keep the 1841s redundant, do I need to use their existing router
> to
> act as a T1 to ethernet bridge?
> Also, on the VRRP front, the customer currently has a /29 LAN subnet
>
> outside their ASA. The current T1 router has one IP and the rest of
> the IPs are in use on the ASA. Will we need to renumber them to a
> /28
> subnet? Or, can the virtual router address be from their current
> subnet
> with the individual routers having their primary IPs from another,
> RFC
> 1918, subnet?
> The 7204VXR is running at 55% CPU load handling about 1800 PPPo(A|E)
>
> connections.
> If I configure the VirtualTemplates to permit CEF, which lowers CPU
> utilization to about 30%, the router hangs in an ininite loop at
> random
> intervals, at least with c7200-ik91s-mz.122-28.SB5.bin. Any of the
> 12.2
> SB series images at the time I last tried CEF did the same thing and
> I
> haven't had enough nerve to try again since.
> Hopefully, that is not important right now. The only reason I
> mention
> it is in case an IPSec tunnel, or whatever the necessary magic ends
> up
> being, might make a significant impact on the CPU.
> --
> Scott Lambert KC5MLE Unix SysAdmin
> _______________________________________________
> cisco-nsp mailing list
> https://puck.nether.net/mailman/listinfo/cisco-nsp [3]
> archive at http://puck.nether.net/pipermail/cisco-nsp/ [4]
>
>
> Links:
> ------
> [3]
> http://webmail.internode.on.net/parse.php?redirect=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-nsp
> [4]
> http://webmail.internode.on.net/parse.php?redirect=http%3A%2F%2Fpuck.nether.net%2Fpipermail%2Fcisco-nsp%2F
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list