We have a production network utilizing a couple of core switches running BGP AS 65000. There are distributions switches running AS's 65001-65003 which each run VRFs (vrf-lite). The core switches do NOT run VRFs. There is address aggregation to limit the number of routes being sent to the core from each "block." These /12 aggregates (chunks of 10/8) are advertised from the core to all of the "blocks" so that they have more specific routes than just default. Each block has a 10/8 null route to keep it from forwarding traffic to the core which is destined for unkown 10.x addresses. All is working OK. Here is the problem:
In our lab, I am trying to mock up everything as much as possible because we have a lot of migrating to do as we move to this new network and I want to be able to thoroughly test each stage. Due to space and equipment restrictions, I consolidated all of the 3 "blocks" into one. There is a 4th block (AS 65004) which mocks up the internet and generates the default, which is separate equipment. I have all of the VRFs and address families configured, separate fiber uplinks, etc.
But because one can only have 1 instance of BGP, all of the routes have to source from AS 65001. the core receives them fine. but of course, the VRFs don't see each other's routes because they are all from the same AS. But since we are currently employing those null routes, VRFs can't communicate with each other.
An ideal solution would be to somehow change the source AS being advertised. I'm expecting to be disappointed but is there any way to do this?
Another solution is to remove the null routes and move that function to the core, letting traffic follow the default there. This moves me another step further from the production configuration but maybe we could do that in production too.
Any thoughts? Is this clear as mud?
your topology is not clear, one diagram would say more than hundreds words.
Generally, you could use the neighbor x.x.x.x remove-private-as command on your core routers, see
Possibly with some sophisticated as-prepending or communities used to keep the info from which VRF the original prefix was sent?
Or you could use neighbor ip-address allowas-in [number]
command to permit the local as number within the incoming prefix attributes on your distribution routers.
Or neighbor as-override possibly?
Those commands are designed for PE routers, but might work in VRF-lite environment, too.
You should always be careful when using them and test in your lab before configuring your productive network.