Hello Difan,
you should add some details to your initial post.
First of all, what is the platform and network operating system you are using.
I can guess you are using an IOS XR platform because the show command is show bgp ... and not show ip bgp ...
When you use a VRF and multi protocol BGP, the network device prepares everything for VPNv4 NLRI exchange, we still have RD one or more route targets and other ext-communities.
According to your show command in VRF LTE you are redistributing from an IGP spoken with the CE node(s) into BGP. The IGP might be OSPF or EIGRP.
This is the root cause for the additional ext-communities that you see
From your show :
#sho bgp vpnv4 unicast vrf LTE 10.133.0.158/32
BGP routing table entry for 64912:2153:10.133.0.158/32, version 57328
Paths: (1 available, best #1, table LTE)
Advertised to update-groups:
77
Refresh Epoch 1
Local
10.133.132.102 (via vrf LTE) from 0.0.0.0 (10.133.128.153)
Origin incomplete, metric 200, localpref 100, weight 32768, valid, sourced, best
Extended Community: Cost:pre-bestpath:129:4091392 (default-2143392255)
0x8800:0:0 0x8801:100:2841600 0x8802:257:1249792 0x8803:257:1
0x8804:64911:176521370 0x8805:9:200 0x8806:0:176521370
mpls labels in/out 228/nolabel
rx pathid: 0, tx pathid: 0x0
64912:2153 is the RD, the IPv4 prefix in VRF LTE is 10.133.0.158/32.
The fact that is locally injected in the MP BGP VRF LTE ipv4 unicast BGP Table is declared by the line:
>>Origin incomplete, metric 200, localpref 100, weight 32768, valid, sourced, best
origin incomplete means it comes from redistribution of an IGP into MP BGP AF ipv4 unicast VRF LTE as I noted before, the weight 32768 and the word sourced means it is locally generated.
In addition to this the corresponding VPNv4 NLRI is advertised to update-group 77.
>> Advertised to update-groups:
77
You can use
show bgp update-group 77
to see what BGP endpoints are listed I would expect two MP BGP sessions to route reflectors if this is a real world router and not a lab.
Finally, the lines highligheted in blu are used to carry several IGP information over MP BGP in order to have customer CE nodes to speak the IGP of choice in different sites and to have the impression the PE networks is not in the middle.
Extended Community: Cost:pre-bestpath:129:4091392 (default-2143392255)
0x8800:0:0 0x8801:100:2841600 0x8802:257:1249792 0x8803:257:1
0x8804:64911:176521370 0x8805:9:200 0x8806:0:176521370
All the 0x880x:<value>:<value> are extended communities used to carry IGP information within so that the remote PE node can rebuild IGP data structures and send them to the remote locally connected CE node.
see RFC4577 for OSPF as PE-CE
In yur case the PE-CE protocol is EIGRP see the following blog
http://theriker.blogspot.it/2017/01/ccie-spv4-mpls-l3-vpn-eigrp-pe-ce.html
According to the blog author the meaning of the 0x800y ext communities are the following:
0x8800 is route information used for the Route Flag and tag
0x8801 is route metric and AS used for the ASN and dely
0x8802 is route metric and is used for Reliability, next-hop and bandwidth
0x8803 is route metric and is used for Reserve, load and MTU
0x8804 is external route metric and is used for Remote AS and Remote ID
0x8805 is external route metric and is used for Remote protocol and Remote metric
0x8806 is Originating Router ID
As you can see the logic is the one I have explained before this specialized ext-communities are used to carry different information about an EIGRP route within a VPNv4 route so that a remote PE node can rebuild the EIGRP update and send it to the remotely connected CE node.
As a final note OSPF has the sham-link concept and can deal with migration of sites that have direct links between them. EIGRP has not the sham-link concept.
Hope to help
Giuseppe
