in

IEOC - Internetwork Expert's Online Community

Welcome to Internetwork Expert's Online Community - IEOC - a place for CCIE and CCENT candidates to connect, share, and learn. Our Online Community features CCIE forums and discussions for all tracks including Routing & Switching, Voice, Security, Service Provider, and Storage. Through these online communities you can discuss your questions with thousands of your peers, hundreds of CCIE's and Internetwork Expert's own team of world renowned CCIE instructors and authors, Brian Dennis - Quintuple CCIE #2210, Scott Morris - Quad CCIE #4713, Brian McGahan – Triple CCIE #8593, Petr Lapukhov - Quad CCIE #16379, Anthony Sequeira - CCIE #15626, Keith Barker - Dual CCIE #6783, and Marvin Greenlee - Triple CCIE #12237.
Forums » Internetwork Expert Products » CCIE Service Provider Lab Workbook Volume II Version 1.0 » IEWB-SP Volume 2 Version 1.0 Lab 3 » Task 8.2 RPF breaks multicast testing
Latest post 05-10-2009 9:50 PM by ciscokid. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next

  • 03-16-2009 7:39 AM

    Task 8.2 RPF breaks multicast testing

    Reply Contact

    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

    CCIE R&S #17416
    • Post Points: 5

  • 03-16-2009 7:43 AM In reply to

    Re: Task 8.2 RPF breaks multicast testing

    Reply Contact

    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.

     

    CCIE R&S #17416
    • Post Points: 20

  • 04-19-2009 8:30 PM In reply to

    Re: Task 8.2 RPF breaks multicast testing

    Reply Contact

    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.

     
    • Post Points: 20

  • 05-10-2009 7:50 PM In reply to

    Re: Task 8.2 RPF breaks multicast testing

    Reply Contact

    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.

     
    • Post Points: 20

  • 05-10-2009 9:50 PM In reply to

    Re: Task 8.2 RPF breaks multicast testing

    Reply Contact
    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 <bounce-tacoboy@ieoc.com> 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
    "

    Kind regards

    James R. Yeo

    CCIE#11676 R&S+Security+Service Provider

     
    • Post Points: 5
Page 1 of 1 (5 items)
IEOC CCIE Forums Internetwork Expert CCIE Training
About IEOC | Terms of Use | RSS | Privacy Policy
© 2010 Internetwork Expert, Inc. All Rights Reserved