inter-as option B, can i summary vpnv4 route at asbr boundary.
i create VRF at boundary asbr, and summary vpnv4 route from upstream PE, but i can't ping destination vrf pc.
i trace,the traffic end at ASBR VRF interface. and ASBR vrf can't forward traffic back to destion PE.
is there any solution i can summary vpn route at boundary ASBR.
I don't think you can do it at the MPLS forwarding plane this cannot work
from the local PE the FEC is for the vpnv4 subnet component not for the summary route.
So at the ASBR the fowarding from one LSP to the other LSP in the other AS fails
Hope to help
But huawei engineer said they can do summary vpnv4 route at asbr router.
i can't do it on cisco router, i can summary vpnv4 route , and i can see summary route at remote site, but i can't ping it.
or the VPNv4 summary route exists end-to-end from PE to PE or you cannot forward traffic over the MPLS LSP associated to it because it will not be end-to-end.
localPE ----- mpls ISPA --- ASBR === ASBR --- mpls ISPB --- remotePE
This is how MPLS VPN traffic forwarding works.
Verify if on the huwaei side the ASBR and the remote PE are not the same node.
Also it is possible they have developed some feature for this.
Hope to help
does cisco 7609 RSP720 has this feature, i can see summary route at remote AT, but trace traffic from remote AS end at ASBR vrf interface, ASBR router can't forward traffic to destination PE.
customer ask us to summary vpn routes at option B ASBR.because huawei can do this.customer don't want all vpn routes to be distributed across many AS.
I think summary vpn route at ASBR broke mpls vpn LSP,this is not a desire behaviour, is that right?
summarization applies to IPv4 update not VPNv4.
If you want to generate aggregate route into your VPN, you have to do it inside the VRF :
1- Do it on the upstream PE of the remote AS
2- Do it at the ASBR but you need to fallback to option A
This will only be possible if you configure a VRF context on the ASBR, which will turn this ASBR into a PE as well. This would cause the ASBR to create an aggregate label for the summarized route at the control plane level. At the data plane level the ASBR would receive the aggregate label, lookup the LFIB, pop it, lookup the FIB, push a new label and then forward the packet to the peer ASBR in the other AS.
As Laurent mentioned, it would probably be better to go with option A in this case.
i have test summary vpnv4 route as you said.
i can see summary route, but i can't ping destination CE.
i trace destinace CE, and i see traffic lost at ASBR vrf interface.
it seem ASBR doesn't lookup FIB and forward back to the network.
platform is 7609
I am not sure what you mean by VRF interface. You don't really need a VRF interface. You only need to create a VRF context with the same RT import export as the VPN in question. The aggregation would be done at the "address-family ipv4 vrf xxx" level, not at the vpnv4 level. The aggregate will cause an aggregate label to be installed in the LFIB and advertised to the remote PEs via BGP vpnv4. The more specific routes will be installed in the FIB for the specific VRF context. When packets arrive at the ASBR with the aggregate label, the label will be removed and a second lookup will be performed against the FIB for the VRF context.
i test it, but on 7609 rsp720 pfc3c, I can't ping remote PE.
If i aggregate vpnv4 route, how about route target.
huawei engineer said he must create a vrf of same vpn at ASBR, and ip address of this VRF must be include in summary route. if this vrf ip address is not a subnet of smmary route. he can't ping remote CE(this CE connected to remote PE,not conntected to ASBR) from remote AS.
Huawei support Hierarchy of Provider Edge Device in BGP/MPLS VPN(HoPE),it can summary vpn route at SPE,But this internet draft was submit by Huawei company, does cisco support HoPE(Hierarchy of Provider Edge Device in BGP/MPLS VPN).