[qpimd-users] self as a neighbor

[Andrew Lunn]

Hi folks

Is the daemon supposed to have itself as a neighbor?



uml1> show ip pim neighbor
Recv flags: H=holdtime L=lan_prune_delay P=dr_priority G=generation_id A=address_list
T=can_disable_join_suppression

Interface Address Neighbor Uptime Timer Holdt DrPri GenId Recv
eth1 192.168.1.1 192.168.1.1 00:16:12 01:23 01:45 1 9c78d487 HLPG
eth1 192.168.1.1 192.168.1.2 00:15:58 01:28 01:45 1 a36abc15 HLPG
eth2 192.168.1.5 192.168.1.5 00:16:12 01:18 01:45 1 9dfcfa51 HLPG
eth2 192.168.1.5 192.168.1.6 00:15:32 01:18 01:45 1 a9dda562 HLPG

Looking at the logs, i think it is receiving its own multicasted Hello
message and not discarding it.

2009/04/14 15:17:36 PIM: Rescheduling 30 sec hello on interface eth1
2009/04/14 15:17:36 PIM: hello_send: to 224.0.0.13 on eth1: holdt=105 prop_d=500 overr_i=2500 dis_join_supp=0 dr_prio=1 gen_id=2625164423 addrs=1
2009/04/14 15:17:36 PIM: pim_tlv_append_addrlist_ucast: number of encoded secondary unicast IPv4 addresses: 0
2009/04/14 15:17:36 PIM: pim_msg_send: to 224.0.0.13 on eth1: msg_size=34 checksum=a562
2009/04/14 15:17:36 PIM: Recv IP PIM pkt size=58 from 192.168.1.1 to 224.0.0.13 on fd=12 on ifindex=3 (sock_ifindex=3)
2009/04/14 15:17:36 PIM: Recv IP packet from 192.168.1.1 to 224.0.0.13 on eth1: size=58 ip_header_size=24 ip_proto=103
2009/04/14 15:17:36 PIM: Recv PIM packet from 192.168.1.1 to 224.0.0.13 on eth1: ttl=1 pim_version=2 pim_type=0 pim_msg_size=34 checksum=a562
2009/04/14 15:17:36 PIM: pim_hello_recv: from 192.168.1.1 on eth1
2009/04/14 15:17:36 PIM: pim_hello_recv: parse left_size=30: PIM hello TLV type=1 length=2 from 192.168.1.1 on eth1
2009/04/14 15:17:36 PIM: pim_hello_recv: parse left_size=24: PIM hello TLV type=2 length=4 from 192.168.1.1 on eth1
2009/04/14 15:17:36 PIM: pim_hello_recv: parse left_size=16: PIM hello TLV type=19 length=4 from 192.168.1.1 on eth1
2009/04/14 15:17:36 PIM: pim_hello_recv: parse left_size=8: PIM hello TLV type=20 length=4 from 192.168.1.1 on eth1
2009/04/14 15:17:36 PIM: pim_hello_recv: PIM hello option from 192.168.1.1 on interface eth1: holdtime=105
2009/04/14 15:17:36 PIM: pim_hello_recv: PIM hello option from 192.168.1.1 on interface eth1: propagation_delay=500
2009/04/14 15:17:36 PIM: pim_hello_recv: PIM hello option from 192.168.1.1 on interface eth1: override_interval=2500
2009/04/14 15:17:36 PIM: pim_hello_recv: PIM hello option from 192.168.1.1 on interface eth1: can_disable_join_suppression=0
2009/04/14 15:17:36 PIM: pim_hello_recv: PIM hello option from 192.168.1.1 on interface eth1: dr_priority=1
2009/04/14 15:17:36 PIM: pim_hello_recv: PIM hello option from 192.168.1.1 on interface eth1: generation_id=2625164423
2009/04/14 15:17:36 PIM: neighbor_timer_off: cancelling timer for neighbor 192.168.1.1 on eth1
2009/04/14 15:17:36 PIM: pim_neighbor_timer_reset: starting 105 sec timer for neighbor 192.168.1.1 on eth1

maybe related, the next line in the log is:

2009/04/14 15:17:36 PIM: pim_neighbor_update: internal error: trying to replace same prefix list=0

Andrew

[Everton Marques]

Hi,

Post by Andrew Lunn
Hi folks
Is the daemon supposed to have itself as a neighbor?

(...)

Post by Andrew Lunn
Looking at the logs, i think it is receiving its own multicasted Hello
message and not discarding it.

Yes, the issue you spotted remains to be fixed. Since as far
as I can tell it is not harmful, I've been postponing its fix in
favor of pursuing other problems from the pimd/TODO list.

If you feel that such a bogus neighboring is causing trouble
and thus should be handled sooner, let me know.
Or please contribute a patch. :)

Post by Andrew Lunn
2009/04/14 15:17:36 PIM: pim_neighbor_update: internal error: trying to replace same prefix list=0

The log message is unrelated to the self-neighboring issue.
Please ignore it, as it is a stale debugging hook I am supposed
to clean-up...

Cheers,
Everton

[Andrew Lunn]

Post by Everton Marques
Hi,

Post by Andrew Lunn
Hi folks
Is the daemon supposed to have itself as a neighbor?

(...)

Post by Andrew Lunn
Looking at the logs, i think it is receiving its own multicasted Hello
message and not discarding it.

Yes, the issue you spotted remains to be fixed. Since as far
as I can tell it is not harmful, I've been postponing its fix in
favor of pursuing other problems from the pimd/TODO list.

O.K. At the moment i'm i don't know what is stopping pimd
working. This was just the first thing i noticed. More issues will follow
soon....

Andrew

[Everton Marques]

Hi Andrew,

Post by Andrew Lunn
O.K. At the moment i'm i don't know what is stopping pimd
working. This was just the first thing i noticed. More issues will follow
soon....

Whenever qpimd seems not to be working the first command I verify is:
show ip mroute
Note that it should reflect the output of: cat /proc/net/ip_mr_cache

If "show ip mroute" result differs from what you expected, I suggest
to check other commands in the following sequence:

! On last-hop router (attached to mcast receiver)
!
show ip mroute (kernel mcast cache is correct?)
show ip pim upstream (we joined our upstream?)
show ip pim neighbor (upstream is neighbor?)
show ip pim interface (pim enabled on both receiver interface and
upstream interface?)
show ip igmp sources (receiver joined on interface?)
show ip igmp interface (igmp enabled on receiver interface?)
show ip multicast (multicast enabled at all?)

! On first-hop router (attached to mcast source)
!
show ip mroute (kernel mcast cache is correct?)
show ip pim join (downstream joined us?)
show ip pim neighbor (downstream is neighbor?)
show ip pim interface (pim enabled on interfaces?)
show ip multicast (multicast enabled at all?)

Hope this helps.

Everton