Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Mac route in agent was having invalid label and destination NH.
Problem: Two issues were seen - 1) Label was wrongly interpreted as MPLS though it was VXLAN and never got corrected. Sequence of events was that EVPN route was received before global vrouter config. Encapsulation priorities was absent in agent, so evpn route was programmed with Mpls-gre(control-node had sent Vxlan). Since Mpls encap was chosen, label was interpreted as mpls label and not vxlan. When global vrouter config was received resync was done for route. Resync also failed to rectify encap to Vxlan(since vxlan is now available in priorities) because this decision to rectify is based on vxlan id(i.e. if vxlan id is 0 default to mpls as its invalid). In this case vxlan id was 0 as explained above and hence encap continued to be Mpls. 2) Nexthop was different between evpn route and derived mac route. This happened because in path sync of evpn route return was false even though NH change was seen which resulted in avoidance of mac route rebake. Return was false because value set by ChangeNh as true was overridden by MplsChange. Solution: For case 1) - If encap is Vxlan only in the message sent by control-node then put label as vxlan id and mpls label as invalid, even though tunnel type is computed as Mpls(encapsulation prioirties is not received). In case of Mpls encap sent use label as Mpls and reset vxlan to invalid. In case both Vxlan and Mpls are sent in encap then fallback to old approach of interpreting label on computed tunnel type. For case 2) - Fix the return value. Change-Id: Ibeeb3de16d618ecb931c35d8937591d9c9f7f15e Closes-bug: 1457355
- Loading branch information