Hello @robert.gillen ,
you have provided an initial post with many details that describes a different behaviuor between current devices in production running IOS XE and devices tested in the design and simulation phase based on NX-OS ( Nexus switches of some type).
This is not the first or only one thread where diffferences in routing protocols and redistribution are described between IOS/ IOS XE and NX-OS devices.
You have already found a workaround that uses a modified version of the route-map used to filter BGP routes redistribution into OSPF using a route-tag in the static routes and then denying routes having that route tag value.
If we review the more current documentation about redistribution in IPv4 unicast between two dynamic protocols we find that the conditions for prefixes to be passed from protocol A to protocol B are:
a) the prefix is installed in the IP routing table by protocol A ( BGP in your case)
b) a special case exists for connected routes that appear in the routing table as connected routes but they are also matching a network statement.
Now, you have static routes to null0 that match a network statement under router bgp. These network statements inejct the corresponding prefixes in BGP table as locally originated routes with next-hop 0.0.0.0 and weight 38,768.
As noted by @Richard Burts this type of configuration leads these static routes to be treated as similar to connected routes.
What is really interesting in your scenario is that in router OSPF configuration you have also a redistribute connected , but you have fixed the route leakage by changing the route-map applied to BGP into OSPF redistribution with no route-map applied to redistribute connected.
On the other hand, we know that BGP has its own BGP tables or RIB and the locally injected routes / prefixes are part of this and they are considered best path and advertised to BGP peer(s).
So this is probably the "grey zone of implementation": the corresponding routes are installed in IP routing table as static routes with exit interface null0 ( it would be interesting to test using a static route to a physical interface to see if there is any change) but they are also prefixes in the BGP table locally injected and best path advertised to BGP peer(s).
From the BGP configuration point of view you could use aggregate-address ..... summary-only instead of static to null0 + network command, but you would need network commands in BGP for component subnets to trigger the advertising.
I personally prefer to use aggregate-address now instead of the combo static route to null0 + network command.
So I would suggest to try this way to see if you see any changes.
Warning : when using aggregate-address you will need BGP network commands for some component subnets so you may need to filter them in redistribution of BGP into OSPF, in other words the problem can just shift to the component subnets of each aggregate.
Hope to help
Giuseppe
