The topo is: RouterA---Core Router----RouterB.
When customer config Layer 3 VPN service in RouterA and RouterB, for example:
ip vpn-instance signal
vpn-target 64803:400 export-extcommunity
vpn-target 64803:400 import-extcommunity
When apply IP VPN at sub-interface of RouterA and RouterB, 2 router can not learn sub-net of each other.
If customer create the same VPN instace in Core Router. RouterA&B can learn sub-net of each other.
1. Check BGP in 2 Router: Established, it mean OK
2. Check config of RT in both router: OK
3. Check AC side: The link is up
4. Check BGP configuration: Seeing that, routerA&B and Core Router have configuration:
This config mean that the router will learn the route base on RT, if the same RT then Routers will include in routing table. However, in core router, taking the function forwarding service (not terminating service), so if enable policy vpn-target in core router, it will check RT of every VPN come to it, leading to effect to it's CPU and useless operation. In this case, if we don't config IP VPN instance in Core router with RT the same with RouterA&B, the VPN service will be rejected in core router.
After undo policy vpn-target in core router and delete all config "ip vpn-instance...", the VPN service in routerA&B can communicate normally.
There are some reasons make 2 routers can not learn route of each other:
1. The BGP session was down
2. BGP was up but VPN-target is different
3. one of 2 subnet is down
4. There are some other reasons related to policy.
At the first time, customer did not know the meaning of command: policy vpn-target, so they have to create hundred of commands "ip vpn-instance..." in core router, it lead to the config so long and can lead to CPU high when processing RT value. After undo RT checking and deleting these unless commands, the configuration and CPU of router is better.