MTI source manipulation

You cannot manually configure MTI interfaces. The way the MTI works is the MTI should be sourced off the loopbacks that create the MP-BGP sessions. However, in the situation that you have multiple MP-BGP sessions on the same router (R1), say, one is for MP-iBGP (update-source loopback0, with IP address 5.5.0.1), another is for MP-eBGP (via directly connected interfaces with other AS, IP add is 5.5.15.1), I found the MTI on this router (R1) is always sourced off the highest IP address from the MP-BGP (no matter iBGP or eBGP) sessions. In this example, the MTI will always choose 5.5.15.1 as the source. This causes the mVPN not working, the PIM neighbor via the MTI cannot come up at all.

So my current solution is, in this situation, change the MP-eBGP from directly connected session to loopback to loopback multihop session. This can resolve this issue, but the problem is, usually when I realize this, I am doing multicast tasks, and the previous tasks have been done long time ago, if I change the configuration at this point, it's pretty risky, and the previous tasks didn't ask to create the MP-eBGP via loopbacks.

So I am wondering, is there any way to manipulate the MTI source? I guess the answer might be NO, but still want to check with you guys.

Thanks,

Bo

Comments


  • I believe you can modify the MTI source like this:

    ip vrf red
    bgp next-hop loopback 33

    Not sure if it is supported in the lab IOS versions though. 

    M



    On Feb 16, 2010, at 1:43 AM, bozhang wrote:

    You cannot manually configure MTI interfaces. The way the MTI works is the MTI should be sourced off the loopbacks that create the MP-BGP sessions. However, in the situation that you have multiple MP-BGP sessions on the same router (R1), say, one is for MP-iBGP (update-source loopback0, with IP address 5.5.0.1), another is for MP-eBGP (via directly connected interfaces with other AS, IP add is 5.5.15.1), I found the MTI on this router (R1) is always sourced off the highest IP address from the MP-BGP (no matter iBGP or eBGP) sessions. In this example, the MTI will always choose 5.5.15.1 as the source. This causes the mVPN not working, the PIM neighbor via the MTI cannot come up at all.

    So my current solution is, in this situation, change the MP-eBGP from directly connected session to loopback to loopback multihop session. This can resolve this issue, but the problem is, usually when I realize this, I am doing multicast tasks, and the previous tasks have been done long time ago, if I change the configuration at this point, it's pretty risky, and the previous tasks didn't ask to create the MP-eBGP via loopbacks.

    So I am wondering, is there any way to manipulate the MTI source? I guess the answer might be NO, but still want to check with you guys.

    Thanks,

    Bo




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx




  • I believe you can modify the MTI source like this:



    ip vrf red

    bgp next-hop loopback 33



    Not sure if it is supported in the lab IOS versions though. 



    M



    Thank you very much mfierbaugh, this does resolve the issue. :) And I verified it works on both 12.3T and 12.2(25)S

    Bo

  • is there anyway that we don't use bgp next-hop under VRF configuration, but the tunnel can still work?

  • The key feature of MTI (or MDT or PMSTI) interface is that it should be sourced off the interface used as vpnv4 next-hop in vpnv4 updates. This is needed to successfully perform RPF checks on the MTI interface. Therefore, the MTI source is automatically set by Cisco IOS to match the vpnv4 update source for a given VPN. Thus, the "bgp next-hop" command is probably the only way to manipulate the source.

    Notice however that Inter-AS mVPNs pose additional challenges, that could be resolved by using additional BGP attributes. But the MTI source should still be set to PE's vpnv4 update interface. This behavior could be changed with the introduction of segmented inter-AS MTI tunnels, but those are in development by now.

Sign In or Register to comment.