[c-nsp] Injecting Routes Remotely

[Payton, Zack]

Hello all,
I'm pretty new to this list (yesterday).  But I think this should work:
use nat to convert the destination multicast address from the usual
224.0.0.9 to the unicast address of your destination router... And then
back again whenever that router recieves packets that are IP protocol
88.  This will allow your EIGRP packets to traverse the network as far
as you wish... However if this is over a public network, or any
broadcast based network with hosts beside the routers then I would
highly recommend protecting the exchange via some kind of tunnel
(IPSec,L2TP, PPTP whatever...)

I use this technique to sometimes remotely troubleshoot multicast issues
instead of doing debug ip packets....

BTW as a good question for list: is it ever feasible to use 'debug ip
packet' with an access-list to limit the printed packets in a production
environment.... Throughout all books I've ever read they say never use
debug in a production environment but I can see how using this with an
access-list could leverage the router like a packet sniffer and would
enable you to view some traffic in some pretty tough areas of the
network to get to... another thing possible would be selectively briding
traffic to something like a gre interface (is that even possible?) for
remote troubleshooting...
Sorry if this question is a little bit off topic for this list or
thread.

Zachary Bell Payton
It's my birthday!!!!! Feb 26th, 1982
Hi mom I'm on puck!


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Crist Clark
Sent: Friday, February 25, 2005 6:32 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Injecting Routes Remotely

We are trying to come up with a way to inject routes into an IGP
remotely. The problem is that there is a device in the midst of the
network which does not speak any routing protocols, which really doesn't
do routing, but is really a bridge for that matter. Here are some more
details of the simple setup:

                        [ leaf nodes ]
                            __|__
                           |     |
                           | RAS |
                           |_____|
                              |
                            __|__
                           |     |
                           |  C  |
                           |_____|
                              |
                         [ network ]

The RAS is the dumb device. We are stuck with this device. We can make
no changes to this device. It usually assigns a IP addresses to its leaf
IP nodes from a known IP network pool (via PPP). So router C (a Cisco
router), just has a static route to this network and distributes this
route into EIGRP. We actually have several of these setups. That is, "[
network ]" has several of these nets hanging off of it. Each RAS has its
own unique range, so each C router advertises that range into EIGRP, and
all is good.

Now, the problem is that special leaf nodes will be getting IP addresses
that are not within the uinque range to each RAS. Each special node will
get a fixed IP address no matter which RAS it attaches to. We need to
somehow get these routes into EIGRP or else things don't work for the
fixed-IP hosts.

As I stated, the RAS is not up to the task. Instead, there is an server
external to all of this that will know when and where a special leaf
node connects and that node's fixed-IP address. Now, how do I get the
information off of this remote server, and inject it into the routing
table? I guess I should rephrase that. There are many, many unthinkably
kludged up ways to do that, so what I am really asking is, what is the
most simple, cleanest, with as little administrative overhead as
possible way to inject these routes into the EIGRP? Some sub-optimal
thoughts we've already had are to do a scripted interactive CLI session
to C to add and delete static routes. Or insert an extra host, like a
*nix system, on the network between the RAS and router C that can talk
to the remote server with leaf node information and then inject routes
to C using RIPv2 or the like. Or a variation of that where instead of
physically putting a host between each RAS and C, we have a few with GRE
tunnels to C to pass RIP through.
We've also have had evil thoughts about using BGP, since BGP peers need
not be adjacent, which is our whole problem here, but haven't developed
those past the "what if we tried..." stage.

I'm hoping someone else out there has had to deal with dumb devices like
our RAS or for some other reason, inject routes into EIGRP from a remote
host that is not a router. I also thought network engineers might find
this a fun little challenge. We did until we saw how painful it was
going to be to maintain all of the nifty hacks we thought up.
I'm hoping we're missing some glaringly obvious way to do this easily,
but I'm not counting on it. Thanks for any help.
-- 
Crist J. Clark                               crist.clark at globalstar.com
Globalstar Communications                                (408) 933-4387
_______________________________________________
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/