HP3000-L Archives

June 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Patrick Santucci <[log in to unmask]>
Reply To:
Patrick Santucci <[log in to unmask]>
Date:
Thu, 21 Jun 2001 10:00:11 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
Jeff Kell after me:

>> When our WAN router (172.18.0.20) loses connectivity with the
>> router at the other end of the connection, it tries to reroute
>> the packets through the Internet router (172.18.1.80).
>
> Then your network is broken, sir.

Actually, you're right. I left out a key piece of information (shame on
me!), which is that our network folk have some public IP addresses
configured on our WAN. So yes, from a configuration standpoint, our network
is definitely "broken."

> The primary router appears to be functioning correctly; if it
> loses connectivity with another router, it drops the link. But
> it sounds as if the 2nd router may have a static default link
> which is not so dynamic. And you should never leak RFC1918
> private address space like 172.18.x.x onto the public network
> anyway. If the second router cannot reach your WAN, at least
> one of your routers is leaking route advertisements that it
> cannot support (which is the broken part).

It's the aforementioned public IP addresses configured on the first router
that are supposed to be static. When we lose that connectivity, the second
router, seeing that they are public IP addresses, tries to contact them. But
of course it can't reach them because they're configured to be reachable
only on our WAN. It's a real mess. I've asked our WAN guy to see if he can
get AT&T to configure/assign 172.18.x.x NATted addresses to the remote sites
on our WAN. There are a lot of them, though, and it would take some doing.

> Granted that the 3000 had problems when the defualt gateways
> fail, but when it receives a redirect it get's cached into
> your gateway pool, which isn't 100% kosher either.

Exactly my point. I *ought* to be able to "permanently disable" a gateway.

Taking another approach, perhaps I should configure the 1.80 gateway on our
system with no routes defined for it. Would that have the desired effect?

Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Patrick Santucci
HP e3000 Systems Administrator
Cornerstone Brands, Inc.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2