[Xorp-users] Endless PIMv2 Register messages

[Jeff Mitchell]

On 06/28/2010 05:33 PM, Garry Peirce wrote:
> It seems you have 3 routers in mesh (?)

Yes.

> with all acting as BSRs for the
> entire mcast block.

They're supposed to all be acting as candidates. The bootstrap process 
does seem to work though, given that the end result is two candidates 
and one elected:

Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.1      1 Candidate            87        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.1      1 192.168.20.1      1 Init                 -1        -1


Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.2      1 Candidate            80        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.2      1 192.168.20.2      1 Init                 -1        -1


Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.3      1 Elected              59        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.3      1 Init                 -1        -1

> You may have an RP-RPF/DR issue given that.
> I'll assume that .3 is likely the DR (highest IP) and perhaps the basis for
> your symptom.
>
> First hop (20.1) unicast encapsulates to .2
> Join from .2 is ignored by .1 as .3 is the DR (as all are RPs covering the
> same group).
> .3 creates state but it would not be seen by .1 (which would then initiate
> the reg-stop.)
> Therefore join/reg-stop never occurs from .2 and .1 continues to send via
> encaps-unicast.
>
> 1) Can you post 'sh ip pim int' for each of them?

Sure:

Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0.501     UP       Sparse 2 DR              1 192.168.51.254          0
rtrs         UP       Sparse 2 NotDR           1 192.168.20.3            2
register_vif UP       Sparse 2 DR              1 192.168.20.1            0

Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0.502     UP       Sparse 2 DR              1 192.168.52.254          0
rtrs         UP       Sparse 2 NotDR           1 192.168.20.3            2
register_vif UP       Sparse 2 DR              1 192.168.20.2            0

Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0.503     UP       Sparse 2 DR              1 192.168.53.254          0
rtrs         UP       Sparse 2 DR              1 192.168.20.3            2
register_vif UP       Sparse 2 DR              1 192.168.20.3            0

> 2) Do you need all routers to be RPs? You might select just one to simply
> this.

Not sure. I may want to have multicast traffic flowing from behind each 
one...would it be better to break up the zones in this case?

> 3) Also, I noticed this from your initial config (is this from 20.1?)
> static {
>           disable: false
>           route 192.168.51.0/24 {
>               next-hop: 192.168.20.2
>               metric: 1
>           }
>           mrib-route 192.168.51.0/24 {
>               next-hop: 192.168.20.2
>               metric: 1
>           }
> ...
>
>
> And later (from 20.1 output)
>
> DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
> 192.168.20.0/24    192.168.20.1    rtrs    1                 0      0
> 192.168.51.0/24    192.168.51.254  eth0.501 0                 0      0
>
>
> This would seem to show that 192.168.51.0/24 is known via both eth0.501
> along with an
> static mrib route to it via 20.2. Perhaps this static mroute is
> misconfigured?

Sorry, those bits were posted at different times, and I did in fact 
change the configuration between the two times. (I had had the routers 
have the 91, 51, and 52 subnets behind them; now it's the 51, 52, and 53 
subnets corresponding to 192.168.20.1/2/3 respectively.)

Thanks,
Jeff