Control node not advertising inclusive mcast route into EVPN to MX
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
R2.20 |
Fix Committed
|
High
|
Manish Singh | |||
R2.21.x |
Fix Committed
|
High
|
Manish Singh | |||
R2.22.x |
Fix Committed
|
High
|
Manish Singh | |||
R3.0 |
Fix Committed
|
High
|
Manish Singh | |||
Trunk |
Fix Committed
|
High
|
Manish Singh |
Bug Description
Physical servers connected directly to the MX can be made part of a contrail VNs by creating physical/logical interfaces on physical router objects. Once this is done, the physical server should have L2/L3 connectivity to all the other hosts (VMs/BMS) in that VN.
When this setup is first configured, it is seen that the control node will not advertise an inclusive multicast route into the EVPN towards the MX. As a result, ARP requests that are coming from the physical server connected to the MX are not flooded into the VN. Restarting the control node fixes this issue.
Topology:
physical_
ARP request from the physical server for contrail_VM is not flooded by MX into the contrail VN.
root@vibrant# run show evpn instance _contrail_l2_9_MGMT extensive
Instance: _contrail_l2_9_MGMT
Route Distinguisher: 172.16.89.200:73
Encapsulation type: VXLAN
MAC database status Local Remote
MAC advertisements: 2 13
MAC+IP advertisements: 1 13
Default gateway MAC advertisements: 1 0
Number of local interfaces: 1 (1 up)
Interface name ESI Mode Status
ge-0/0/0.2001 00:00:00:
Number of IRB interfaces: 1 (1 up)
Interface name VLAN VNI Status L3 context
irb.9 9 Up _contrail_l3_9_MGMT
Number of bridge domains: 1
VLAN VNI Intfs / up IRB intf Mode MAC sync IM route label
8191 9 1 1 irb.9 Extended Enabled 9
Number of neighbors: 3
172.16.80.10
Received routes
MAC address advertisement: 4
MAC+IP address advertisement: 4
Inclusive multicast: 0
Ethernet auto-discovery: 0
172.16.80.11
Received routes
MAC address advertisement: 4
MAC+IP address advertisement: 4
Inclusive multicast: 0
Ethernet auto-discovery: 0
172.16.80.12
Received routes
MAC address advertisement: 5
MAC+IP address advertisement: 5
Inclusive multicast: 0
Ethernet auto-discovery: 0
Number of peers: 3
Number of ethernet segments: 1
ESI: 05:00:00:
Status: Resolved by IFL irb.9
Local interface: irb.9, Status: Up/Forwarding
Router-ID: 172.16.89.200
Source VTEP interface IP: 172.16.89.200
information type: | Proprietary → Public |
description: | updated |
@asurana-t
Can you check if the CN has a route for the broadcast mac from the
vrouter agent which has the VM in question? CN generates the IM
route based on the broadcast MAC route received from the agent.