VXLAN EVPN Standard Communities

[shados]

Hi,

Here is the premise

Leaf 1 sends a route type 2 update with standard community to leaf 2 (border leaf) and then this /32 is redistributed into ipv4 vrf and advertised outside of EVPN fabric. The issue is with standard community, it's being stripped when advertising outside of evpn fabric. Why is that and how to fix this issue? Thanks!

Imported from 11.11.11.11:4:[5]:[0]:[0]:[32]:[192.168.10.11]/224
AS-Path: NONE, path sourced internal to AS
11.11.11.11 (metric 81) from 1.1.1.1 (1.1.1.1)
Origin incomplete, MED 0, localpref 100, weight 0
Received label 100
Community: 65001:70
Extcommunity: RT:65000:100 ENCAP:8 Router MAC:520f.505d.1b08
Originator: 11.11.11.11 Cluster list: 1.1.1.1

from an external pov:

BGP routing table entry for 192.168.10.11/32, version 29
Paths: (2 available, best #1, table default)
Advertised to update-groups:
4 5
Refresh Epoch 1
65000
10.99.99.1 from 10.99.99.1 (192.168.10.1)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on Sep 18 2024 10:59:16 UTC

I have send community configured of course. packet capture shows BGP update without standard community too. Meaning it's being lost somewhere on the LEAF 2.

[MHM Cisco World]

type 5 use to advertise prefix into external device not type 2

MHM

[shados · Accepted solution]

That is not correct. When leaf receives evpn routes both 5 and 2 they are being redistributed into IPv4 vrf and advertised to peers in that vrf. I already found an answer. The community was dropped because it was applied to hmm redistribution and leaf selected as best path route type 2 vs 5 and imported it into IPv4 vrf and advertised it to external peers. 

[MHM Cisco World]

• Route type 1 – This is an Ethernet Auto-Discovery (EAD) route type used to advertise Ethernet segment identifier, Ethernet Tag ID, and EVPN instance information. EAD route advertisements may be sent for each EVPN instance or for each Ethernet segment.

• Route type 2 – This advertises endpoint reachability information, including MAC and IP addresses of the endpoints or VTEPs.

• Route type 3 – This performs multicast router advertisement, announcing the capability and intention to use ingress replication for specific VNIs.

• Route type 4 – This is an Ethernet Segment route used to advertise the Ethernet segment identifier, IP address length, and the originating router's IP address.

• Route type 5 – This is an IP prefix route used to advertise internal IP subnet and externally learned routes to a VXLAN network.

So I am sure it type5 even what you share is type5

Imported from 11.11.11.11:4:[5]:[0]:[0]:[32]:[192.168.10.11]/224

MHM

[shados]

I already told you that what you suggesting is not correct. I've tested this in a lab and on production.

Here is Cisco Live on the same topic

They advertise type 2 host route /32 which is being imported into vrf and advertised to external peers.

What I've pasted was partial output from sh bgp l2vpn evpn 192.168.10.11

Because I had HMM redistribution and EVPN Type 2 I had two routes in my routing table but I didn't see that the best was type 2 route and thus it was advertised to external peers without community.

Here is the output without redistributing hmm

and it's being advertised to ipv4 ebgp peer in vrf.