O E2 10.183.161.64/27 [110/1000] via 22.214.171.124, 00:03:12, Vlan101
When it learns the same route from BGP, I would expect OSPF route to be replaced by the BGP route. However, this doesn't happen. The route exists in the BGP routing table but not flagged as the best route and hence not replacing the OSPF route.
* 10.183.161.64/27 10.188.63.1 5171 0 64513 ?
If I manually remove the OSPF route, I will eventually get:
B 10.183.161.64/27 [20/5171] via 10.188.63.1, 00:05:36
And when I manually put the OSPF route back, the BGP route will stay, but OSPF route will appear in the OSPF database.
just thinking it loud. How is the next-hop 10.188.63.1 learnt here? BGP is not installing 10.183.161.64/27
as the best route as it looks like the next-hop is not reachable. Once you remove the ospf the next hope becomes reachable and BGP installs in the routing table. Once it installs in the routing table and ospf comes to replace it then the AD wins and ospf route doesnt get placed in the RIB . However it doesnt explain why it would loose the prefix in the ospf database..ummm
Yes, OSFP is also redistributed to BGP. However, this route should have been filtered out by a route-map. The idea is to have the route learnt from a different AS. But there is also a floating static on the local AS (ISDN headend router) which redistributes it into the OSPF. Does it fit your scenario?
Without a diagram of all routers involved, redistribution route-maps, next-hops, sh ip route and sh ip bgp x.x.x.x for the problematic subnets I'm lost here.
I can only say a general opinion:
When redistributing between OSPF and BGP mutually, it's often necessary to think which prefix comes first.
When redistributed from OSFP to BGP, the BGP prefix gets the weight attibute value 32768 by default.
And when the same prefix is received from BGP later on, the higher weight value of the redistributed prefix wins and the new prefix received from BGP is not considered to be the best one (as you might expect).
I agree with Kishore, in most cases the BGP learned prefixes don't install in routing-table because of problems with next-hop reachability, you should just have a look how the ip 10.188.63.1 is reached in both cases - with and without OSPF.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...