I work for a company that has several thousand stores and in an effort to get them off of dialup, we've designed a configuration that would make a Cisco 877 the default gateway, but on the same network would be a VSAT router. If the DSL connection goes down on the 877, a floating route is inserted to route back out the same ethernet interface on the same IP subnet to the VSAT router. I know it should work, but it seems like it's not an optimal design, but I don't know what to say if I go back to management other than it's a clunky design. Any ideas?
Sound simple and effective to me. I guess you propose to use SAA (pings or somethng) to check that the satelite route is up. One thing to be aware of is that by default when the router detects that it is routing back out of the same interface it will send an ICMP redirect to the source. This will (permanently? - well until reboot) modify the source's routing table and the satelite link will be unavailable.
The fix is no icmp redirect or is is "no ip icmp redirect":-) on the inside interface of the 877.
You could equally well run a dynamic routing protocol over the sat link. If you pay for traffic then check how much that will cost.
We use SLA to verify VSAT route is there. And we are using a routing protocol, RIP I think, but I'm trying to verify that. I'm just wondering what valid reason I could give that routing in and out of the same interface would be considered a bad design. I had thought we wanted to aggregate the bandwidth at some point, but that no longer seems like the goal. The goal is only redundancy. I don't even think we could aggregate the bandwidth in this configuration.
if it is cisco then HSRP between the 2 routers would protect against 877 failure as well (see other posters suggestion for VRRP - this is a similar protocol, but not as flexible in most implementations).
there is no reason you have to use VSAT for backup everywhere (for example cabling up an aerial might be difficult in say some big shopping centres, or you might not have line of sight to the satellite in some locations).
any alternate transport will do - 3G is now 1 possibility, or your old dialup link, or ISDN BRI, or IPsec across a broadband internet feed.
the other thing worth checking is that your apps will still work with the latency you get from VSAT - a shared channel system may mean round trip delays of several seconds.
I was more so looking for an argument against the 877 routing out to the same ethernet interface as its local LAN for the fail over route. I think it would more beneficial to use a VLAN for a backbone between the two routers. Also, with a dedicated VLAN between them I think they could aggregate the bandwidth. Although I'm not sure how we'd accomplish that except by static routes with a slightly lower cost for the DSL route. I'm starting to believe the vendor uses RIP and that's going to complicate things somewhat.
VSAT is used everywhere, because you can get it everywhere. Most technologies aren't available so diversely as VSAT. That's why the majority of our stores, whether they're in downtown LA or rural Alabama have VSAT. The lucky ones that could get it have DSL because one of two vendors offer it nation wide where its reach has extended. We're also using a private DSL, that's a Point to Point Link to the Vendor's NOC and then it is filtered at that point and allowed out to the internet or up to above store.
3G/EVDO from our tests looks good most places except densely pack urban areas, especially beside huge freeways that fill up at rush hour. ISDN is too expensive for our needs. We've used IPSec where we couldn't get our private DSL. We're trying to get away dial up now because of the sizes of packages we're pushing to our stores are just too large for dialup over POTS.
We're aware of the latency issue with VSAT. Reaching earth orbit and then coming back down takes a huge amount of time. That's been worked out with TCP ACK spoofing. The issue we're trying to get around now is failover and adding bandwidth, as well as keeping costs down for our franchisees.
A VLAN makes the logical structure look different, but physically the packets go back out the same Ethernet on the router - no practical difference for performance, or resilience.
Only thing that would be different is you may not send out redirects to the source.
you will struggle to get useful thruput from aggregating a terrestrial link and VSAT as the difference in delay will confuse many apps.
The old joke about load balancing is that what you want is thruput of the set of links at the minimum delay, and what you sometimes get is thruput of the slowest link combined with the highest delay........
Maybe if you can use the cisco to be selective about which protocols use which link that would work?
i am not sure that is true - for example here in the UK Sat TV "only" has coverage of 98% or so. The few exceptions are those where there is a building, or a steep hillside blocking the view.
So if you have a site on the north site of a big office complex you wont have a shot at a geosync satellite without roof access.
That's why the
OK - and you could always make it part of the property selection...
i think if you have a sime sliced data service, then calculate it a lot of the time is waiting for a transmission timeslot
That's been worked
ACK spoofing doesnt reduce the streaming delay, it just cuts connection set up time.
i strongly suggest you test this with your apps in a realistic setup (ie correct b/w etc) before you go live.
if getting a dummy VSAT link is too painful, then you can get delay simulators to pretend to be the space segment.
I want to clarify something - are your stores on VSAT currently and you are trying to come up with a redundant design that adds DSL if available and uses it as the primary path ?
Just to clarify, the majority of our stores are on VSAT. Barring any natural barrier or man made one, all stores have been able to get VSAT, with the exception of Alaska stores (evidently the earth is in the way to hit the Clarke belt). We want to add DSL for speed and lower latency, but still keep the VSAT for redundancy and to eliminate the cost of a dial up line which is not usable any way since the size of transfers is too large for it. Aggregating bandwidth would had been a plus. Our applications have been working find with TCP spoofing enabled, it actually prevents the connection from timing out. Routing based on protocol sounds interesting, but I don't think the 877 is a smart enough device to accomplish this. I'd only heard of the Enterasys SSR that could do that. I imagine Cisco has a comparable device to it, but I don't think the 877 is it. I think using the terrestrial link and the satellite link together with the deviation in latency is going to be a challenge, even though they both go back to the same service provider's NOC. We had hope to add bandwidth for the non-critical apps (ie. Video, eLearning/LMS, Customer WiFi, eMail, Internet access), but the original plan had called for another DSL line, only public for these services. I don't know how we're going to leverage the new plan of private VSAT & private DSL for redundancy AND aggregated bandwidth. I don't think there's a silver bullet here.
ICMP redirects seems to be something we should stay mindful of, although I'm not so sure it would be a bad idea of the host learned of the new route.
Yes, most, damn near all stores are on VSAT, thousands... The ones on DSL I could count on my hands. The latency and bandwidth is an issue for video so we're trying to add DSL and get rid of dial up to keep costs down. Yes, the DSL would be the primary. An 877w with the VSAT DW4020 or DW7700 plugged into the same LAN as all the store hosts, so when the DSL goes down, the 877w will insert a floating route to the VSAT. The 877w and VSAT routers are on the same IP subnet and VLAN as all the hosts for the store network.
So you obviously already know about some or all of issues with using VSAT ...
I do not see an issue with rerouting packet back out same interface in the event that ADSL has gone away. I would not put it on a separate VLAN as you want the downstream devices to see and make use of the ICMP redirects that should be sent by the Cisco 877 when it reroutes packet to the VSAT router.
BTW as far as the insertion of the floating static routes - I would suggest that this not be based solely on the DSL interface going down
- it is not unheard of for an ISP's POP to becoming partitioned from the rest of the ISP's network. Are you going to use dynamic routing protocol for the ADSL link or IOS SLA object tracking ?
BTW I would THROUGHLY test that IOS on 877 will route packets back out the same-interface - just to ensure that there are not any IOS bugs that would interfere will this working correctly.
Let us know what your current or target IOS release is for the Cisco
Just to clarify, the majority of our stores are on VSAT. Barring any natural barrier or man made one, all stores have been able to get "VSAT, with the exception of Alaska stores (evidently the earth is in the way to hit the Clarke belt). We want to add DSL for speed and lower latency, but still keep the VSAT for redundancy and to eliminate the cost of a dial up line which is not usable any way since the size of transfers is too large for it. Aggregating bandwidth would had been a plus. Our applications have been working find with TCP spoofing enabled, it actually prevents the connection from timing out. Routing based on protocol sounds interesting, but I don't think the 877 is a smart enough device to accomplish this. I'd only heard of the Enterasys SSR that could do that. I imagine Cisco has a comparable device to it, but I don't think the 877 is it. I think using the terrestrial link and the satellite link together with the deviation in latency is going to be a challenge, even though they both go back to the same service provider's NOC. We had hope to add bandwidth for the non-critical apps (ie. Video, eLearning/LMS, Customer WiFi, eMail, Internet access), but the original plan had called for another DSL line, only public for these services. I don't know how we're going to leverage the new plan of private VSAT & private DSL for redundancy AND aggregated bandwidth. I don't think there's a silver bullet here.
ICMP redirects seems to be something we should stay mindful of, although I'm not so sure it would be a bad idea of the host learned of the new route."
The 877 will allow you to route by protocol with no issue. As for routing out the same interface on failure. Why not bring your VSAT to a seperate FE on the 877? You could then route certain protos out that interface on a regular basis and also reroute all traffic in the event of the failure of the DSL link.
policy based routing is in just about all IOS flavours now, so the main Q is whether the box has the performance to do it.
note from an old IOS version to get you started (easiest way is to let routing take case of "most" traffic and override for you special case
- set the next hop to be your terrestrial path is VSAT is the default, or vice versa)
formatting link
you have a spare router and a simulated branch to test things in - in which case time for a trial....
Note you are only overriding "next hop" routing, so it needs implementing at both the edge & centre.
or if you have system design control, split the central services across boxes on different subnets, and set up the routing so the path depdns on which central subnet you hit - that will work with standard routing as long as you are careful with costings....
I'd only heard
this became a standard bit of IOS a fair time back, so should be in most IOS boxes.
I think
the behavour you usually get with load balancing is that the combined set of flows gives you the worst of latency and thruput x no of links, less any overhead.
big disparities in bandwidth and latency will not be easy to sort out.
We had hope to add
using HSRP or VRRP on the 1st hop routers will suppress ICMP redirect
- the cost is sometimes packets cross the LAN twice, and extra CPU load on the 877 etc. Given limited WAN bandwidth that usually isnt a problem.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.