04-02-2009 07:26 PM - edited 03-04-2019 04:12 AM
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
Solved! Go to Solution.
04-05-2009 05:23 AM
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
04-02-2009 09:14 PM
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.
04-03-2009 12:10 AM
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
04-03-2009 12:26 PM
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?
04-05-2009 04:16 AM
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
04-05-2009 05:17 AM
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
04-05-2009 05:23 AM
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
04-05-2009 07:54 AM
"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
04-07-2009 09:47 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide