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?

On 4 Apr, 02:03, "mel.chand...@gmail.com" <mel.chand...@gmail.com>
wrote:
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.

On Apr 4, 12:41 am, Bo...@hotmail.co.uk wrote:
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.

What happens if and when 877 completley fails ?

Check and see if both routers support VRRP

What is the make and model of the VSAT router ?

<mel.chandler@gmail.com> wrote in message
news:4146d4b9-249c-411b-9a37-1c568dab377a@m44g2000hsc.googlegroups.com...
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.
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

On Apr 4, 10:40*pm, Merv <merv.hr...@rogers.com> wrote:
I think we have to do it this way because the VSAT router doesn't
support any failover protocols (HSRP, GLBP, or HSRP)

On Apr 4, 11:01*pm, Merv <merv.hr...@rogers.com> wrote:
Mostly it is a DW4020, but some are the newer DW7700.

On Apr 5, 6:42*am, "stephen" <stephen_h...@xyzworld.com> wrote:
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.

On Apr 6, 9:47*am, "mel.chand...@gmail.com" <mel.chand...@gmail.com>
wrote:
Meant VRRP as well.

<mel.chandler@gmail.com> wrote in message
news:4eb828bb-48c2-4d72-8d96-eaaeec37d315@t36g2000prm.googlegroups.com...
On Apr 5, 6:42 am, "stephen" <stephen_h...@xyzworld.com> wrote:
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.
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

OMel,

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 ?

On Apr 6, 11:46 am, "stephen" <stephen_h...@xyzworld.com> wrote:
Thanks Stephen, a lot of good info there.

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.

On Apr 6, 2:51 pm, Merv <merv.hr...@rogers.com> wrote:
Merv,

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.

Thanks for all the help guys.

On Apr 7, 12:54 pm, "mel.chand...@gmail.com" <mel.chand...@gmail.com>
wrote:


Okay thanks for additonal clarificiation.

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
877's

<mel.chandler@gmail.com> wrote in message
news:20d9745b-cecf-478b-905f-fb1b16e5aea2@d45g2000hsc.googlegroups.com...
877 is IOS s/w - so ACLs and policy based routing should be in there, but
might need a higher cost feature set

try the feature navigator to check (although a bench, a couple of boxes and
a few hours of testing time is the only way to be sure) -
http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

- this implies you need advanced ip services, or the adv security

I think
multiple DSLs should be reasonably cheap - but 1000s of sites will multiply
it quickly.
and you would need a bigger cisco - 1841 or 2801 AFAIR.

are you buying a big chunk of VSAT bandwidth shared by all stores, or
running some sort of pt - pt scheme?

if you can handle much bigger downloads than uploads and a shared beam, can
you use multicast, or asymmetric routing?

doing complicated stuff at a hub site just needs 1 (or a few) big routers,
so complications and cost there scale much better over a lot of sites.

I don't
the thing everyone underestimates is the pain of keeping a complex structure
up and running, and the fault finding, and diags.

simple is good....
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Thanks Stephen, a lot of good info there.

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.



--
--------------------------------- --- -- -
Posted with NewsLeecher v3.9 Final
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

On Sun, 29 Jun 2008 13:50:53 GMT, HDFLSTS-2002 <me@my.net> wrote:

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)
http://www.cisco.com/en/US/docs/ios/.../qcpolicy.html
ideally 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.
Regards

stephen_hope@xyzworld.com - replace xyz with ntl