From: Kurt E. Radecki (kradecki@xxxxxxxxx)
Date: Wed Feb 14 2001 - 11:50:49 GMT-3
Hello,
I responded the night before when I was swamped, so I didn't have much time
to elaborate. Someone described the situation well earlier, but here's a
recap.
What enables a distance vector routing protocol to run over an NBMA network?
Assuming that no point-to-point subinterfaces are used, disabling split
horizon on the hub is the only way to pass routing updates to the spokes.
But, split horizon was designed to eliminate routing loops, so you open your
network to problems by disabling it. You can enable split horizon (if it
isn't already) on the spokes to eliminate part of the problem, that of the
spokes advertising networks they don't source. But what about the hub? If
one of the networks connected to a spoke goes down, the hub (running a
distance vector RP) will advertise that same network as if it has a path.
*That* is the problem I see.
Erick, I think you nailed it when you said the only way to fix it is with an
inbound filter on all the spokes. With this filter, keep a spoke router from
learning from other routers the networks that it sources. That'll fix the
routing loops.
I hope this helped someone. True, never do this in the real world. But,
since the CCIE lab is designed to test your knowledge of most technologies
in IOS, you never know what you'll see.
-Kurt
-----Original Message-----
From: Erick B. [mailto:erickbe@yahoo.com]
Sent: Monday, February 12, 2001 2:26 AM
To: David Ankers; Simon Baxter; Kurt E. Radecki; Dan; CCIEList
Subject: Re: router filtering
Hi,
I've been reading the replies to the original message
and I don't think this can be done on the hub router
with current IOS features. It's defiantly something
you don't want to do in a production environment.
If I understood the original message correctly, the
only way I see this being done is with a inbound
filter on the spoke the routes are originating from
(similar to smurf attack filters) denying those routes
back in.
I also think a outbound filter on each spoke
permitting only the local routes is needed to avoid
nasty routing problems. Ie: Spoke5 will announce a
route it learned from Spoke3 and Spoke2 will get this
with a hop to Spoke5 when that route isn't on Spoke5.
The way I read the original message is he is disabling
split-horizon thus the routes a spoke is advertising
are getting sent back from the other spokes and he is
looking to learn other routes from the other
spokes+hub but just not the ones he is advertising.
I hope this helps.
--- David Ankers <d.ankers@chello.nl> wrote:
> He wanted to deny _sending_ packets on a multipoint
> link (distribute list
> out) to only certain hosts. Even if you treated the
> link as non broadcast by
> adding neighbours to rip I can't see a way to do
> this with distribute lists.
> Actually *I* can't see a way to do this at all,
> route-maps would work very
> well with BGP for example but where would you asign
> then in rip? rip was
> designed to be a broadcast protocol so I doubt it
> even has these knobs to
> turn. The only way *I* can think of doing this is
> with an inbound filter on
> the actual host that you don't want to see the
> particular route with a
> distri-list in and an extended access list that
> says: access-list 100 deny
> host <source interface of sending router> host
> <route>
>
> The rate limit example would deny all inbound
> traffic from 192.168.33.3, and
> is the same as doing this:
>
> int eth0
> ip access-class 100 in
> !
> access-list 100 deny host 192.168.33.3 any
> access-list 100 permit any any
> !
>
> Where did eigrp come from? I must be missing
> something....
>
> D.
>
>
> On Monday 12 February 2001 02:47, Simon Baxter
> wrote:
> > Why not just :
> >
> > router rip
> > distribute-list 1 in atm6/0.1
> >
> > or
> >
> > interface ATM6/0.1 multipoint
> > ip address 192.168.1.1 255.255.255.0
> > rate-limit input access-group 100 8000 4470 4470
> conform-action drop
> > exceed-action drop
> > !
> > access-list 100 permit host 192.168.33.3 any
> > !
> >
> >
> > (I don't know if this second one would work, but
> it should deny eigrp
> > packets from a specific host out the multipoint
> interface)
> >
> > ???
> >
> > -----Original Message-----
> > From: Kurt E. Radecki [mailto:kradecki@cisco.com]
> > Sent: Monday, February 12, 2001 11:44 AM
> > To: Dan; CCIEList
> > Subject: RE: router filtering
> >
> >
> > Dan,
> >
> > That would deny all updates out of that interface.
> I only want to deny
> > certain updates to certain remotes. In a situation
> where the hub is a
> > physical or a point-to-multipoint subinterface,
> the subnet is the same for
> > routers.
> >
> > Thoughts?
> >
> > -Kurt
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> > Dan
> > Sent: Sunday, February 11, 2001 6:37 PM
> > To: Kurt E. Radecki; CCIEList
> > Subject: Re: router filtering
> >
> >
> > Kurt,
> >
> > Did you figure this out?
> > If you want to filter the RIP update on a physical
> or subinterface it
> > shouldn't be too difficult.
> >
> > Put this on the hub router
> > router rip
> > distribute-list 1 out (frame-relay interface)
> >
> > access-list 1 deny x.x.x.x (frame-relay net you
> want to filter from being
> > advertised out).
> > access-list 1 permit any
> >
> > Dan Pontrelli
> >
> > ----- Original Message -----
> > From: "Kurt E. Radecki" <kradecki@cisco.com>
> > To: "CCIEList" <ccielab@groupstudy.com>
> > Sent: Saturday, February 10, 2001 8:48 PM
> > Subject: router filtering
> >
> > > How does one filter routes based on a PVC? If
> I'm running RIP over Frame
> > > Relay, and my hub interface is either a physical
> or point-to-multipoint
> > > subinterface, I want split-horizon disabled so
> that routing updates will
> > > pass to all remotes. But, with that, I don't
> want to advertise out the
> > > PVC from which a routing update came.
> Distribute-lists don't seem to give
> > > the granularity needed.
> > >
> > > Thoughts? Thanks.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:48 GMT-3