redistribute and distribute-list

Hi folks,

I'd like to know if the distribute-list is used also in preventing
routing loops when redistributing from one routing domain to another
another and when of course there more than one points of redistributions
between two domains.

My understanding is that such tecnique of filtering is not the right
one but others must be used like working on ADs or route-tags.

Am I correct?

Thx Alex

 

Hi,
in my opinion, distribute-list is a perfect tool to preventing problems
related to redistribution.

regards,
marco

 

Thanks Marco,

I meant that when I apply distribute-list I still see that the
the advertised routes on the bad side are installed in the routing table.
I was trying to avoid that but my understnding is that since we have to
deal with the routing table the only way is to play with the
Adiministrative Distance.

I played a bit with the following scenario (within brackets Int and Ext
AD for the protocol)

OSPF(110) --- EIGRP (90 and 170) --- RIP (120)

and I think that the problem of avoiding loops can be split into two
smaller problems:

1) avoid re-redistribution within the domain, for instance ext routes
learned from RIP distributed to OSPF and then learned back to EIGRP;

2) avoid that routers on the border learn routes from the wrong side.

With the 1st scenario I agree with you, with the second I think the
distribute-list filter applies once the route has been already learned
and installed in the routing table.

Would you agree? Or you have something different in mind?

Regards,

Alex

 

I think this is wrong...
Maybe you made a mistake in distribute-lists configuration?

Yes. Once routes from different routing protocols are installed in
routing table, you are forced to change administrative distance value to
modify default behavior in choosing best path.
e.g you have two routes

10.20.30.128/25 learned by EIGRP internal (ad 90)
10.20.30.0/24 learned by OSPF (ad 110)

To 10.20.30.155 router will choose the EIGRP one.

If you want to change this you have to modify Administrative Distance.

No. By using distribute-lists you can prevent installation of routes in RIB.

Kind Regards,
Marco

 

Sounds like it.

Not a good example. The router will always choose the /25 no matter
what the AD because of the longest match rule. If the *same* route were
learned by different protocols then the AD would decide which was
installed in the routing table.

Agree.

Sam

 

Il 20/06/12 16:48, Sam Wilson ha scritto:

Sam you're perfectly right and I was wrong.
I forgot longest match rule.

Kind Regards,
marco

 

Thanks Marco

my comments inline

I can post the conf of the 2 routers I used if it is not a pbl.

Two considerations:

1) using distribute-list with OSPF: I think I cannot filter any LSA
coming from the bad side otherwise the LSDB of the ASBR would not be
consistent with all the other LSDB of the area, hence that LSA is
installed in the DB. The same network is learned from the other side
(the good one where I cannot filter) and hence the AD becomes a tie.
again I have to play with the AD.

2) using distribute-list with EIGRP: I played with dynamips with two
routers (two intfs each) connected over FastEthernet, all of them under
the EIGRP umbrella but one of the router got the other Fa interface in
OSPF area 0.

The core of the filtering rules in my case is the following:

-------------- ROUTER 7 --------------------

hostname R7
!
ip cef
!
multilink bundle-name authenticated
!
interface FastEthernet0/0
ip address 192.168.1.7 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.77.254 255.255.255.0
duplex auto
speed auto
!
router eigrp 23
network 192.168.1.0
distribute-list 1 in FastEthernet0/0
distribute-list 1 in
auto-summary
!
router ospf 2
log-adjacency-changes
redistribute eigrp 23 subnets
network 192.168.77.0 0.0.0.255 area 0
distribute-list 1 out eigrp 23
!
ip forward-protocol nd
!
access-list 1 deny 192.168.88.0
!

R7#sh access-lists
Standard IP access list 1
10 deny 192.168.88.0 (3 matches)

-------------- ROUTER 8 --------------------

hostname R8
!
interface FastEthernet0/0
ip address 192.168.1.8 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.88.254 255.255.255.0
duplex auto
speed auto
!
router eigrp 23
network 192.168.1.0
network 192.168.88.0
auto-summary
!

By clearing the eigrp neighbours I do see the hits on the ACL 1 on
router 7 but still the network 192.168.88.0 is in its EIGRP topology

Am I wrong? And where?

As I said above, speaking about OSPF (and for advertisements back to
the domain of origin, aka advertisements on the bad side), I don't think
so, seen the nature of the protocol (LSDB consistent across all the
routers in area) For EIGRP, I agree with you, but by now I cannot
achieve this simple task.

Many thanks in advance for your help

Alex

 

As you wrote, you cannot prevent route installation in OSPF Database
with distribute-list. But you can prevent installation in RIB.

"Distribute-list only filters routes from entering the routing table"

http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a0080094704.shtml#q12

About access-list 1 on router 7: remember the implicit deny in every acl.

Now, access-list 1 should filter any route,

Please issue this command on router 7 and copy output here...

show ip eigrp topology 192.168.88.0/24

see you soon
marco

 

As you wrote, you cannot prevent route installation in OSPF Database

Many thanks Marco , now it's clearer.

Indeed the ACL denies everything but I do not know why I still saw those
routes in the topology DB of EIGRP.
Anyway I started from scratch the configuration of both,
changed the ACL with the correct fashion and indeed I could control
which route was learned from the EIGRP mate.
Also I have to say that if I use the interface option the ACL is
completely skipped (no hits) in that case and no routes are filtered but
by using just the regular command

distribute-list 1 in

it does work.
The interface I specify (f0/0) is the interface from which R7 gets the
EIGRP updates so I think I used the command correctly. Any idea why it
doesn't work?

Many thanks to all,

Ale

 

It seems somebody else faced the same problem...

http://ieoc.com/forums/p/6821/24109.aspx

Alex

 

Interesting question....
Maybe a bug? Check your IOS version...

regards,
marco

 

I guess it's a bug as with 12.4.17 I don't see this behaviour and I'm
told that with 12.4.15T14 they don't see that either.

Thank you all!