Task 8.2 RPF breaks multicast testing

Hi,

After configuring the RPF check on R3 in Task 8.2, the multicast testing from R7 will no longer work (as the ICMP echo reply is sourced from 160.1.6.6 and R3 drops this as it does not know about the route in VRF 100).

Strictly speaking this does not matter as multicast is uni-directional but for the purposes of testing (and more importantly the CCIE SP lab itself ) is there anything we can do to resolve this?

I fixed by adding a static route to 160.1.6.6 into the VRF on R3 and pointing it back to R5 to make sure that the RPF check worked, but I know in the real lab static routes are a no-no (unless task allows specifically)

Rgds

Comments

  • Ignore earlier post

     

    RPF ACL does the job and doesnt need any static route:

    Changed task 8.2 to: 

     

    access-list 2 permit 160.1.6.6

    ip verify unicast source reachable-via any 2

     

    this enables R3 to allow source of 160.1.6.6 without need for specific route in VRF and allows echo replies to get back to R7.

     

  • Good catch and thanks for the solution. I added a static route to fix the problem:

    Rack1R3(config)# ip route vrf 100 160.1.6.6 255.255.255.255 172.30.101.5

    But I like your solution better because yours is more elegant.

     

  • I noticed the RPF was failing back to R1 from R3 point of view.

     

    So I added the following on R2:

     

    ip mroute 150.3.1.1 255.255.255.255 Tunnel0

    SPRack3R2#sh ip rpf 150.3.1.1
    RPF information for ? (150.3.1.1)
      RPF interface: Tunnel0
      RPF neighbor: ? (150.3.1.1)
      RPF route/mask: 150.3.1.1/32
      RPF type: static
      RPF recursion count: 0
      Doing distance-preferred lookups across tables
    SPRack3R2#

     

    SPRack3R3#sh ip rpf 150.3.1.1
    RPF information for ? (150.3.1.1)
      RPF interface: Ethernet0/0
      RPF neighbor: ? (150.3.23.2)
      RPF route/mask: 150.3.1.1/32
      RPF type: unicast (isis)
      RPF recursion count: 0
      Doing distance-preferred lookups across tables
    SPRack3R3

     

    That seemed to address the root cause.

     

  • This is not an answer to your question but would lile to mention the following FYI- if it is a Te tunnel then it is unidirectional thretefore you cannot use it for multi-cast RPF failure resolution. Do a debug mpacket and see which one of the intrfaces it originnaly failed on and use that ip for it RPF interface.

    Thanks

    James


     

    Sent from my iPhone 3G

    On 11 May 2009, at 4:52, tacoboy <[email protected]> wrote:

    I noticed the RPF was failing back to R1 from R3 point of view.

     

    So I added the following on R2:

     

    ip mroute 150.3.1.1 255.255.255.255 Tunnel0

    SPRack3R2#sh ip rpf 150.3.1.1
    RPF information for ? (150.3.1.1)
      RPF interface: Tunnel0
      RPF neighbor: ? (150.3.1.1)
      RPF route/mask: 150.3.1.1/32
      RPF type: static
      RPF recursion count: 0
      Doing distance-preferred lookups across tables
    SPRack3R2#

     

    SPRack3R3#sh ip rpf 150.3.1.1
    RPF information for ? (150.3.1.1)
      RPF interface: Ethernet0/0
      RPF neighbor: ? (150.3.23.2)
      RPF route/mask: 150.3.1.1/32
      RPF type: unicast (isis)
      RPF recursion count: 0
      Doing distance-preferred lookups across tables
    SPRack3R3

     

    That seemed to address the root cause.

     




    "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
    "
Sign In or Register to comment.