5.0: Granular Routing policy. MED and local-pref not advertised correclty from left to right vrf

Bug #1757396 reported by Shashikiran H
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
Trunk
Invalid
Critical
Nikhil Bansal

Bug Description

Version: 5.0
Picked up the latest build.

Topo:
10.204.217.7 cfgm control ui openstack
10.204.216.68 cfgm control
10.204.216.72 cfgm control
10.204.217.16 vrouter
10.204.217.17 vrouter

mx -- left-vn --- si1(ecmp, in-network) --- right-vn

I have a routing policy to mark interface routes with MED 312 on left VN for left VRF originated routes(4.1.1.9,which is VMI ip of VM sitting on left VRF). The routes in left VRF correctly get updated with MED value I configure. But those values do not reflect on the right VRF. The same route 4.1.1.9, shows up with MED as 100(default) in right vrf. Same behaviour for LP. LP as 213 gets updated in left vrf, but does not reflect on right vrf for left originated routes. However, the routes mx receives(say 4.1.1.9) have MED as 312 and LP as 213 correctly.

If, instead of modifying MED or LP, it I add community however, right VRF correctly has the newly added community and even mx receives the community correctly.

from protocol interface then local-preference 312 action default

<iq>
 <routing-policy-entries>
  <term>
   <term-match-condition>
    <protocol>interface</protocol>
    <community></community>
    <community-match-all>false</community-match-all>
   </term-match-condition>
   <term-action-list>
    <update>
     <as-path>
      <expand />
     </as-path>
     <community>
      <add />
      <remove />
      <set />
     </community>
     <local-pref>312</local-pref>
     <med>0</med>
    </update>
    <action></action>
   </term-action-list>
  </term>
 </routing-policy-entries>
</iq>

Shashikiran H (skiranh)
description: updated
Revision history for this message
Nikhil Bansal (nikhilb-u) wrote :

This is by design, we don’t pick med and local_preference from the original route but based on the destination route.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.