6.2 Multicast testing "not RPF interface"

RSRack1R6 is configured with two subinterfaces, f0/0.6 is stub and f0/0.26
is connected to the rest of the network.

A neighbor is found through f0/0.26
Address                                                            Prio/Mode
132.1.26.2        FastEthernet0/0.26       02:42:43/00:01:36 v2    1 / S

pinging the group 228.28.28.28 from this neighbor, RSRack1R2, is successfull

RSRack1R2#ping 228.28.28.28

Reply to request 0 from 132.1.17.7, 100 ms

pinging the same group sourced from subinterface f0/0.06 or f0/.26, from R6 fails
each time displaying a message stating that the other sub interface is
"not RPF interface"

RSRack1R6#ping 228.28.28.28 source f0/0.6

Packet sent with a source address of 132.1.6.6

*Oct 24 13:18:22.065: IP(0): s=132.1.6.6 (FastEthernet0/0.6) d=228.28.28.28 id=159, ttl=254, prot=1, len=114(100), mroute olist null
*Oct 24 13:18:22.069: IP(0): s=132.1.6.6 (FastEthernet0/0.26) d=228.28.28.28 id=159, ttl=254, prot=1, len=114(100), not RPF interface.

RSRack1R6#ping 228.28.28.28 source f0/0.26

Packet sent with a source address of 132.1.26.6

*Oct 24 13:35:53.641: IP(0): s=132.1.26.6 (FastEthernet0/0.6) d=228.28.28.28 id=161, ttl=254, prot=1, len=114(100), not RPF interface
*Oct 24 13:35:53.645: IP(0): s=132.1.26.6 (FastEthernet0/0.26) d=228.28.28.28 id=161, ttl=254, prot=1, len=114(100), mroute olist null.

your help is appreciated

Comments

  • Im getting the same thing, anyone have any ideas?

  • check your routing to 132.1.26.6 on R1 and see if you going to R2 or R3 ... need to make sure traffic going via R2 also .. did you configure static RP on R6?

     

    HTH

    Dmitriy

  •  

    Hi,

     

    I am having exactly the same issue, been looking at it for a while now. When I do a ping from R2 its fine:

    Sending 1, 100-byte ICMP Echos to 228.28.28.28, timeout is 2 seconds:
    Packet sent with a source address of 132.1.26.2

    Reply to request 0 from 132.1.17.7, 392 ms
    Rack1R2#

    When I send from R6 it fails..  when I do an clear ip mroute on sw1  it works from r6 for one ping but not all the time (I have static mroutes on r1 to both vlan 6 & 26 via R2 serial interface:

    Mtrace from 132.1.6.6 to 132.1.17.7 via group 228.28.28.28
    From source (?) to destination (?)
    Querying full reverse path...
     0  132.1.17.7
    -1  132.1.17.7 PIM  [132.1.6.0/24]
    -2  132.1.17.1 PIM/Static  [132.1.6.0/24]
    -3  132.1.0.2 PIM/Static Reached RP/Core [132.1.6.0/24]
    -4  132.1.26.6 PIM  [132.1.6.0/24]
    Rack1SW1#

    Not sure whats going on....?!?!   if I do ping from rt6 i still get the following:

    Rack1R6#ping 228.28.28.28 source 132.1.6.6 repeat 10

    Type escape sequence to abort.
    Sending 10, 100-byte ICMP Echos to 228.28.28.28, timeout is 2 seconds:
    Packet sent with a source address of 132.1.6.6

    *Mar  1 07:24:32.266: IP(0): s=132.1.6.6 (Ethernet0/0.6) d=228.28.28.28 (Ethernet0/0.26) id=545, ttl=254, prot=1, len=100(100), mforward
    *Mar  1 07:24:32.274: IP(0): s=132.1.6.6 (Ethernet0/0.26) d=228.28.28.28 id=545, ttl=254, prot=1, len=114(100), not RPF interface....

     

    Bizarre...    i have static mroutes nailed down just to be careful and have full pim neighbor relationships...  if I source a ping from vlan 26 on r2 it works, anything on r6 nope...

    Looks to have traced all the way from sw1 again, but still don't work:

     

    Rack1SW1#mtrace 132.1.6.6 228.28.28.28
    Type escape sequence to abort.
    Mtrace from 132.1.6.6 to 132.1.17.7 via group 228.28.28.28
    From source (?) to destination (?)
    Querying full reverse path...
     0  132.1.17.7
    -1  132.1.17.7 PIM/Static  [132.1.6.0/24]
    -2  132.1.17.1 PIM/Static  [132.1.6.0/24]
    -3  132.1.0.2 PIM/Static Reached RP/Core [132.1.6.0/24]
    -4  132.1.26.6 PIM  [132.1.6.0/24]
    Rack1SW1#

    Anyone have any ideas I am pretty much exhausted on  this now?

     

    Thanks

    Matt

     

     

  • did you configure "ip pim spt-threshold infinity?

     

  • no i didn't  do you think I need it?

    2009/3/8 nydimka23 <[email protected]>

    did you configure "ip pim spt-threshold infinity?

     



    --
    View this message online at: http://ieoc.com/forums/p/4297/18590.aspx#18590

    Please note my email address has changed to [email protected]
  • My guess is .. your first packets is always going towards RP and since you have mroute statements configred based on that it is working but the rest of the traffic gets switched to shortest path ... check your mroute table and you should see "T" (as to SPT mode) .... your traffic after that will be taking shortest path and no longer flow towards RP.... by configuring "ip pim spt-threshohld infinity" you will force all traffic to flow through RP thus making it work ...

  • Hi,

    Thanks for the response makes sense, will give it a go.

    Matt

    2009/3/8 nydimka23 <[email protected]>

    My guess is .. your first packets is always going towards RP and since you have mroute statements configred based on that it is working but the rest of the traffic gets switched to shortest path ... check your mroute table and you should see "T" (as to SPT mode) .... your traffic after that will be taking shortest path and no longer flow towards RP.... by configuring "ip pim spt-threshohld infinity" you will force all traffic to flow through RP thus making it work ...



    --
    View this message online at: http://ieoc.com/forums/p/4297/18623.aspx#18623



    Please note my email address has changed to [email protected]
  • You shouldn't have to change the SPT settings. I just enabled pim nbma on the R2 serial interface. I also changed the pim dr-priority to 2 on R2. The second part wasn't really necessary, but the rules didn't say minimum configuration was required. I just figured that since I had the ability, R2 would make a better pim DR since it was also the RP.

    Did you account for your potential routing loop between R2 and R3? R6 injected fa0/0.6 as an external route via redistribution so the RPF will keep changing based on whether or not you stopped the loop from happening.

    RSRack1R6#ping
    Protocol [ip]:
    Target IP address: 228.28.28.28
    Repeat count [1]: 1000
    Datagram size [100]:
    Timeout in seconds [2]:
    Extended commands [n]: y
    Interface [All]: FastEthernet0/0.26
    Time to live [255]:
    Source address or interface: 132.1.6.6
    Type of service [0]:
    Set DF bit in IP header? [no]:
    Validate reply data? [no]:
    Data pattern [0xABCD]:
    Loose, Strict, Record, Timestamp, Verbose[none]:
    Sweep range of sizes [n]:
    Type escape sequence to abort.
    Sending 1000, 100-byte ICMP Echos to 228.28.28.28, timeout is 2 seconds:
    Packet sent with a source address of 132.1.6.6

    Reply to request 0 from 132.1.17.7, 28 ms
    Reply to request 1 from 132.1.17.7, 36 ms
    Reply to request 2 from 132.1.17.7, 36 ms
    Reply to request 3 from 132.1.17.7, 32 ms
    Reply to request 4 from 132.1.17.7, 28 ms
    Reply to request 5 from 132.1.17.7, 32 ms
    Reply to request 6 from 132.1.17.7, 32 ms
    Reply to request 7 from 132.1.17.7, 40 ms
    Reply to request 8 from 132.1.17.7, 36 ms
    Reply to request 9 from 132.1.17.7, 8 ms
    Reply to request 10 from 132.1.17.7, 36 ms

Sign In or Register to comment.