Mdef cons get failed for VRF - Lab 4 - Task 6.1,2

Guys,

I hit a possible bug on IOS-XR 3.9.1 (CSCti89409) while trying to configure MVPN for Full Scale Lab 4 Task 6.1-2

I hit it on XR1 and XR2 both, but after removing the configuration, commit, and then reapplying the multicast-routing config on XR2, the problem went away on XR2. However, on XR1 the problem persisted due to which I couldn't achieve end to end mcast traffic. I just want to know if thats the case, then how is Cisco testing MVPN on IOS-XR?

 

RP/0/0/CPU0:XR1#show run multicast-routing

Thu Dec 12 05:32:01.259 UTC

multicast-routing

 address-family ipv4

  mdt source Loopback0

  interface all enable

 !

 vrf FOO

  address-family ipv4

   mdt data 232.255.255.0/24

   mdt default ipv4 232.0.0.1

   interface all enable

  !

 !

!

 

RP/0/0/CPU0:XR1#show run router pim

Thu Dec 12 05:32:06.063 UTC

% No such configuration item(s)

 

RP/0/0/CPU0:XR1#ping vrf FOO 239.0.0.3

Thu Dec 12 05:32:38.558 UTC

Mdef cons get failed for VRF 0x60000058 - No such process

RP/0/0/CPU0:XR1#

Comments

  • Here are a couple of other "weird" things that I've seen on IOS-XR while going through Lab 3 and Lab 4:

     

    1) (Lab 3) IOS-XR behavior where SAFI 4 is running between eBGP neighbors, then the IOS-XR is passing the routes

    to an iBGP neighbor. IOS-XR automatically changes the next-hop, IOS does NOT automatically change the next hop.

    http://ieoc.com/forums/p/27009/226995.aspx#226995

     

     

    2) (Lab 4)  2 IOS-XR boxes peering via ISIS and LDP. XR1 is ASBR and XR2 is just inside the AS. This is Inter-AS Option-C setup. XR2 is the VPNV4 RR inside the AS that will eventually peer via VPNv4 eBGP with the RR in the other AS. Since XR1 is redistributing the prefixes into the AS, not only is it passing the routing information to XR2 but its also passing labels (LDP). XR2 receives the labels (as shown in the LIB) but unless the VPNv4 eBGP peering includes "next-hop-unchanged" then it will NOT use the label assigned by the ASBR to get to the eBGP peer, but instead it will use "imp-null" label. This same thing does not occur in IOS. 

    http://ieoc.com/forums/t/27055.aspx

     

     

  • Thanks for sharing.

    I have some inputs...

    1.

    For IOS-XR behavior with SAFI 4, Its working as expected for me (e.i NH is not changing). Take a look at here http://www.akbintel.com/mediawiki/index.php/BGP/Labs/Lab19#Goal3 ... I have the logs there.

    RP/0/0/CPU0:XR1#show bgp ipv4 labeled neighbors 2.0.0.1 advertised-routes | i $

    Thu Dec 12 13:31:44.056 UTC

    3.0.0.1/32         10.3.19.3       10.3.19.3       3000i

    RP/0/0/CPU0:XR1#


    R2#show ip bgp | i 3.0.0.1

     *>i 3.0.0.1/32       10.3.19.3                0    100      0 3000 i

    R2#


    But in anycase, in my opinion this is a good thing what IOS-XR does. That way, there always exists a label (learned through IGP+LDP) for the NH-self. e.i because R6 will always have route to XR2's lo0, but more likely it won't have route to the XR2-R8 link. Also, if you think about IOS, there isn't a separate "address-family ipv4 labeled-unicast" section, due to which whatever config you apply to af "ipv4 unicast" gets applied to "ipv4 labelel-unicast" (e.i send-label)... But a good catch.

    2. EBGP VPNv4 - You are spot on. I hit the same issue (documented in the above link)

    3. Regarding "Mdef cons get failed for VRF", you will not get it when you ping with source

    RP/0/0/CPU0:XR1#ping vrf FOO 232.0.0.3

    Thu Dec 12 14:58:54.778 UTC

    Mdef cons get failed for VRF 0x60000002 - No such process

    RP/0/0/CPU0:XR1#ping vrf FOO 232.0.0.3 source lo1

    Thu Dec 12 14:59:00.947 UTC

    Type escape sequence to abort.

    Sending 1, 100-byte ICMP Echos to 232.0.0.3, timeout is 2 seconds:

    .

    RP/0/0/CPU0:XR1#

Sign In or Register to comment.