bgp to eigrp redistribution, block locally originated

[joe.lazzaro]

Long time reader, first time poster..

I redistribute our MPLS eBGP routes into our internal EIGRP process at each site. This action undesirably redistributes locally generated BGP networks (via network command) that are meant from the MPLS cloud into our internal routing process.

I currently have a route-map on my 'redistribute bgp' command that filters each network manually with an ACL. This works but adds obvious administrative overhead; each WAN router advertises different networks, and the ACL must be updated for each new network.

Would it make more sense to simply deny routes from BGP to EIGRP with a metric of 32768? Something like this:

route-map deny-local-bgp deny 10
match metric 32768
route-map deny-local-bgp permit 20

router eigrp 100
redistribute bgp 65104 route-map deny-local-bgp

Are there any caveats using this method, or are there any other suggestions for denying these routes into EIGRP?

Thanks,

Joe

[jgraafmans · Accepted solution]

32768 is the weight not the metric of locally originated routes

I think the best way is to use an as-path access-list to match locally originated routes and deny them from being redistributed

ip as-path access-list 10 permit ^$
!

route-map denylocal deny 10
match as-path 10
!        
route-map denylocal permit 20

router eigrp 10
redistribute bgp 65000 metric 10000 2000 255 1 1500 route-map denylocal

[joe.lazzaro]

Thanks for your response. Brain slip, not sure why I had metric listed. It does not appear you can even match on weight in a route-map, only set. Since weight is locally significant, I guess that makes sense.

Your as-path Regex worked great, but I am still curious as to any other solutions...

[Lei Tian]

Hi Joe,

If you use redistribute static/connect to advertise routes in BGP, then those local originated routes will not be redistributed into eigrp.

HTH,

Lei Tian

[milan.kulik]

Hi,

I'm afraid this would block ALL prefixes with an empty AS-PATH, i.e., also prefixes originated by another router within your AS and received by iBGP.

Which might be not requested in some cases.

What about

route-map denylocal deny 10
match route-type local
!        
route-map denylocal permit 20

?

See http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfindp1.html#wp1019366 or http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfindp1.pdf for details.

BR,

Milan

[joe.lazzaro]

I like that method...we dont have any  iBGP neighborships on these MPLS edge routers now, but may in the future.

Unfortunately I tried denying the local routes per your route-map above, but the networks still made their way into the EIGRP topology table.

There doesnt seem to be a wealth of information on route-type local, still looking around though...

[milan.kulik]

Hi Joe,

are you sure the locally originated prefixes are being redistributed to EIGRP from BGP?

What's their origin?

Static, directly connected, received by another IGP?

IMHO, in any case, your router should know this origin and NOT redistribute them from BGP to EIGRP.

Aren't they getting to your EIGRP table by some other way?

BR,

Milan

[joe.lazzaro]

They are definately being redistributed, tried both directly connected and static Null0 routes. Below is a snippet of my test config and the output of eigrp topology.

interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
!
!
router eigrp 100
redistribute bgp 65100 route-map denylocal
network 192.168.1.0
default-metric 1000 100 250 100 1500
no auto-summary
!
router bgp 65100
no synchronization
bgp log-neighbor-changes
network 10.0.0.0
network 172.16.1.0 mask 255.255.255.0
no auto-summary
!
!
ip route 10.0.0.0 255.0.0.0 Null0
!
route-map denylocal deny 10
match route-type local
!
route-map denylocal permit 20

R1#show ip eigrp top
IP-EIGRP Topology Table for AS(100)/ID(172.16.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.0.0.0/8, 1 successors, FD is 2585600
        via Redistributed (2585600/0)
P 192.168.1.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/1
P 172.16.1.0/24, 1 successors, FD is 2585600
        via Redistributed (2585600/0)

[Lei Tian]

Hi Joe,

As I mentioned in my previous post, use redistribute static/connect instead of network statement. That will prevent local originated routes redistribute into eigrp.

Regards,

Lei Tian

[milan.kulik]

Hi Lei,

I still believe even the prefixes advertised to BGP via network command should not be redistributed to EIGRP from BGP (the router should still treat them as static or connected).

@Joe:

Can you please provide the outputs for

sh ip route 10.0.0.0

sh ip bgp 10.0.0.0/8

sh ip eigrp topo 10.0.0.0/8

?

BR,

Milan

[Lei Tian]

Hi Milan,

When redistribute from RP1 into RP2, the router will do

1, check the RIB, list all routes that marked as RP1 and put them into RP2.

2, check the interfaces that are participated in RP1 and put them into RP2.

Same rules apply when redistributing BGP into IGP. If the interfaces are covered by network statement under BGP, it will be redistributed into IGP.

HTH,

Lei Tian

[milan.kulik]

Hi Lei,

yes, that's the case.

IMHO, the 1) can't apply on the BGP locally originated prefixes (as they are still marked as static or directly connected in RIB)

the 2)  is not applied on BGP as the "network" command has a different meaning in BGP configuration, see http://www.cisco.com/en/US/docs/ios/12_1/iproute/command/reference/1rdbgp.html#wp1020691 for details and compare with the EIGRP one http://www.cisco.com/en/US/docs/ios/12_1/iproute/command/reference/1rdeigrp.html#wp1024859 .

BR,

Milan

[Lei Tian]

Hi Milan,

I agree the function of network statement under BGP is different than network statement under IGP, but I dont think that affects function of redistribution. As I said If the interfaces are covered by network statement under BGP, it will be redistributed into IGP. So, if the local originate routes are marked as connected in the RIB, they will be redistributed into IGP.  That includes aggregate routes and static routes point to null 0,  because those routes are considered as connected routes in the RIB.

Regards,

Lei Tian 

[milan.kulik]

Hi Lei,

I configured one router in my lab to check and realized you were correct!

(Including static routes must point to null 0, if pointing to an IP address, they are not redistributed.)

I was not aware of this BGP "network" command feature so far :-(

Do you have any document describing this behavior?  It's not mentioned in any of BGP books I read.

@Joe:

The "match route-type local"

doesn't work here while it works in a route-map used for "neighbor ... route-map denylocal out" BGP peering.

Thank you,

Milan

[Lei Tian]

Hi Milan,

Thanks for tested it out. A few months ago, my customer went into similar issue, the aggregate routes got redistribute back into ospf. I had the same doubt as you had, but one of the cisco central engineer, Fraza Shamim, confirmed that is expected behavior. I  don't know whether that has been documented on RFC or other books, but I trust the information from our central engineer team:)

Regards,

Lei Tian