From: Justin Menga (Justin.Menga@xxxxxxxxxxxxxxxxxx)
Date: Sun Feb 11 2001 - 23:42:24 GMT-3
You are talking about split-horizon issues - indeed what you describe below
will work, but much better way is:
On R3:
int s0
ip split-horizon
You only will need this if R3 is using a PHYSICAL frame-relay interface, if
using a VIRTUAL interface, split-horizon is enabled.
Regards,
Justin Menga CCIE #6640 MCSE+I CCSE
WAN Specialist
Computerland New Zealand
PO Box 3631, Auckland
DDI: (+64) 9 360 4864 Mobile: (+64) 25 349 599
mailto: justin.menga@computerland.co.nz
web: http://www.computerland.co.nz
-----Original Message-----
From: Kurt E. Radecki [mailto:kradecki@cisco.com]
Sent: Monday, 12 February 2001 3:47 p.m.
To: Justin Menga; CCIEList; Simon.Baxter@au.logical.com
Subject: RE: router filtering
I disagree, so I have to beat a dead horse. If you have the following
scenario:
| 10.10.10.0
--
|
r1
|10.1.1.1
-------
/ \
|Frame|
-------
| |
----- ----
| 10.1.1.2 | 10.1.1.3
r2 r3
| |
-- --
| 10.2.2.0 | 10.3.3.0
r1, the hub, is configured on it's physical interface. r2 and r3 are remotes
(for simplicity, we'll assume it doesn't matter how they're configured).
Since r1 is a physical, the subnet is the same on r1, r2 and r3.
In the distribute-list below, change the ip address to 10.1.1.2. Make it a
distribute-list in and apply it on the hub. That would block any routes from
coming from r2. r1 and r3 wouldn't learn 10.2.2.0.
I'm trying to keep r3 from advertising 10.2.2.0 when r2's Ethernet interface
goes down. In other words, apply a filter that keeps...
I figured it out as I was typing. Why not put a distribute-list on each
remote filtering the updates it sends to the hub to only those networks that
it sources. It's not clean, but I believe it works.
Thanks.
-----Original Message-----
From: Justin Menga [mailto:Justin.Menga@computerland.co.nz]
Sent: Sunday, February 11, 2001 9:07 PM
To: 'Kurt E. Radecki'; Justin Menga; CCIEList
Subject: RE: router filtering
See below (blocks updates from 10.1.1.1)
router rip
distribute-list gateway ROUTERS {in | out}
ip prefix-list ROUTERS deny 10.1.1.1/32
ip prefix-list ROUTERS permit 0.0.0.0/0 le 32
Regards,
Justin Menga CCIE #6640 MCSE+I CCSE
WAN Specialist
Computerland New Zealand
PO Box 3631, Auckland
DDI: (+64) 9 360 4864 Mobile: (+64) 25 349 599
mailto: justin.menga@computerland.co.nz
web: http://www.computerland.co.nz
-----Original Message-----
From: Kurt E. Radecki [mailto:kradecki@cisco.com]
Sent: Monday, 12 February 2001 2:45 p.m.
To: Justin Menga; CCIEList
Subject: RE: router filtering
Agreed. I didn't explain it well, but that's my question. How do I apply
this route-map? In routing protocol config, I can add a distribute-list
in|out. I cannot find a way to tie a route-map to a distribute-list and also
cannot find a way to apply a route-map by itself.
I know it's something straightforward. What am I missing?
Thanks.
-----Original Message-----
From: Justin Menga [mailto:Justin.Menga@computerland.co.nz]
Sent: Sunday, February 11, 2001 7:05 PM
To: 'Kurt E. Radecki'; CCIEList
Subject: RE: router filtering
Filtering PVCs in IP routes?? - PVCs are Layer 2 concepts - so to translate
that to Layer 3 (routing) the only mechanism I can see are the update source
of the routes (as this is the other endpoint of the PVC).
To do this you would need to use route maps with your distribute lists....
Regards,
Justin Menga CCIE #6640 MCSE+I CCSE
WAN Specialist
Computerland New Zealand
PO Box 3631, Auckland
DDI: (+64) 9 360 4864 Mobile: (+64) 25 349 599
mailto: justin.menga@computerland.co.nz
web: http://www.computerland.co.nz
-----Original Message-----
From: Kurt E. Radecki [mailto:kradecki@cisco.com]
Sent: Sunday, 11 February 2001 2:49 p.m.
To: CCIEList
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:45 GMT-3