Redistributing into OSPF Question

[lamav]

I have a question that was actually addressed some weeks ago on this board. Unfortunately, I didnt pay attention to the final answer. :-)

Here goes.

Let me post the config first:

router ospf 2004

router-id 10.36.127.241

log-adjacency-changes

summary-address 172.19.48.0 255.255.240.0

redistribute static metric-type 1 subnets route-map STATIC_TO_OSPF

redistribute bgp 64512 metric-type 1 subnets route-map BGP_TO_OSPF

passive-interface default

no passive-interface FastEthernet0/1

network 10.36.125.241 0.0.0.0 area 2

network 10.36.127.241 0.0.0.0 area 2

network 138.69.34.5 0.0.0.0 area 2

!

router bgp 64512

no synchronization

bgp router-id 138.69.34.5

bgp log-neighbor-changes

network 10.34.57.0 mask 255.255.255.0

network 10.94.240.0 mask 255.255.255.0

network 64.202.166.210 mask 255.255.255.255

[output omitted]

This is a VPN Hub router running DMVPN. (irrelevant, actually, just letting you know what this router does in case youre going to ask).

This hub learns about two networks that exist on one spoke router.

One address is the loopback interface, the other is the LAN interface.

EXR-VPN-01#sh ip ro 138.69.34.65

Routing entry for 138.69.34.65/32

Known via "bgp 64512", distance 20, metric 500

Tag 65080, type external

Redistributing via ospf 2004

Advertised by ospf 2004 metric-type 1 subnets route-map BGP_TO_OSPF

Last update from 10.34.5.31 01:56:56 ago

Routing Descriptor Blocks:

* 10.34.5.31, from 10.34.5.31, 01:56:56 ago

Route metric is 500, traffic share count is 1

AS Hops 1

Route tag 65080

EXR-VPN-01#

EXR-VPN-01#

EXR-VPN-01#sh ip ro 10.34.129.64

Routing entry for 10.34.129.64/27

Known via "bgp 64512", distance 20, metric 500

Tag 65080, type external

Redistributing via ospf 2004

Last update from 10.34.5.31 01:56:59 ago

Routing Descriptor Blocks:

* 10.34.5.31, from 10.34.5.31, 01:56:59 ago

Route metric is 500, traffic share count is 1

AS Hops 1

Route tag 65080

EXR-VPN-01#

Notice how the 10.34.129.64 route is "redistributing via" but not "advertised by", like the other one is.

Given the manner in which the BGP routes are being redistributed into OSPF, I cant figure out why there is an inconsistency.

The route map BGP_TO_OSPF is irrelevant, as it simply prevents 10.34.0.0/16 prefix from being redistributed.

Also, I thought that the BGP router ID and the OSPF router ID should be the same to have successful redistribution. While one network was not redistributed, the other one - the loopback -- was. Why?

HELP!!!!!

:-)

Victor

[Edison Ortiz]

Hmmm..

The route map BGP_TO_OSPF is irrelevant, as it simply prevents 10.34.0.0/16 prefix from being redistributed

EXR-VPN-01#sh ip ro 10.34.129.64

__

Edison.

[Giuseppe Larosa]

Hello Victor,

as Edison has noted the missing prefix falls into the filtered address block.

Have you used a prefix-list or an access-list to define the filtered block ?

this can make the difference between filtering only 10.34.0.0/16 and filtering any prefix within 10.34.0.0/16

Hope to help

Giuseppe

[lamav]

Hi, Giueseppe:

This filter was created using the old style retarded BGP filer access lists.

ip access-list extended RANGE_10.34.0.0_16

permit ip 10.34.0.0 0.0.255.255 255.255.0.0 0.0.255.255

When I saw this, I interpreted it as saying "do not redistribute any 10.34 prefix with a subnet mask of /16." such as "ip prefix-list 1 deny 10.34.0.0/ge 16 le 16"

So, this access list covers the entire range of subnets in the 10.34 range?

[Giuseppe Larosa]

Hello Victor,

there are two possible warnings here:

a) you are using this extended ACL in a route-map that decides what BGP routes have to be imported into OSPF.

They are usually used for BGP filtering and they are able to emulate prefix-lists (or better prefix-lists have been introduced for doing route filtering).

So I'm not sure they are supported for redistribution into OSPF.

b) the syntax

the extended ACLs have original usage to match source ip address and destination ip address.

The tricky use in route filtering is to say the following:

let's pretend the prefix base address is the source address and that the subnet mask is the destination.

If this is the idea to match only 10.34.0.0/16 you should use:

permit host 10.34.0.0 host 255.255.0.0

for me the syntax you used is equivalent to at least

ip prefix-list 1 deny 10.34.0.0/16 le 32 because you accept any subnet mask from 255.255.0.0 to 255.255.255.255

This should explain why the missing prefix is filtered is matched by this extended ACL.

Hope to help

Giuseppe

[lamav]

Giuseppe:

Great explanation, buddy. I appreciate it.

You know, I never use these BGP filter lists because the syntax is confusing and inefficient. Since the advent of prefix lists, I only use them.

I didnt configure this router, someone else did years ago. Its old, which explains why hes using these BGP filters.

I interpreted the filter a dfferent way, but when the route was not being redisitributed, that should have triggered the idea in my head that I was interpreting it incorrectly.

Last question: dont the router IDs for BGP and OSPF have to be the same to redistribute either routing protocol into the other?

I read that in my Doyle book years ago, but cant find any reference online these days. That is also how I always see it configured.

Thanks

[Giuseppe Larosa · Accepted solution]

Hello Victor,

I also stay away from that kind of ACLs first time a collegue showed me a production router with these strange ACLs we lost a lot of time trying to understand what they do

>>dont the router IDs for BGP and OSPF have tp be the same to redistribute either routing protocol into the other?

I may be wrong on this but I think it is BGP that makes a special check on this so the answer could be: yes for redistributing OSPF into BGP, not needed for BGP into OSPF.

Do you see different router-ids on this dear old router ?

Hope to help

Giuseppe

[lamav]

"Do you see different router-ids on this dear old router ?"

Yes, the routers config is posted in the original message. So, it seems then that you CAN redistribute BGP into OSPF and have the router IDs DIFFERENT, but I guess it does have to be the same for redistributing OPSF into BGP, which if you notice, this router does not do.

I'll research this more. Just couldnt find anything online and my Doyle book is in storage...and thats another story altogether. ;-)

[EDIT] Giuseppe:

Can you check out my "desiging a remote LAN" thread? I really would love to hear some of your insight. Im surprised you havent visited it already. :-) [EDIT]

Victor

[milan.kulik]

Hi Victor,

isn't the identical router ID required only when BGP synchronization is enabled?

See http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml#background

BR,

Milan