[Xorp-users] Traffic over the same interface

[Daniel Camara]

 Hi people,

  I am with a problem here, and I would like to ask your opinion about it. I
am really sorry if this a well known problem/limitation. However, I searched
through the list and I didn't find any thing that was quite exactly the
same.

 I have a configuration that is:

        Server  <-------------------> Node2 <-----------------> Node2
<-------------> Node3 <--------------------> Client
 eth0=192.168.13.53   eth2=192.168.13.1       mesh0=10.0.1.1
eth2=192.168.14.1   eth0=192.168.14.53

mesh0=10.0.1.2                                          mesh0=10.0.1.3

 Node 1 and 3 have two interfaces configured and all the other nodes have
just one interface configured. I guess this is exactly the problem. Even
Node2, that work as a bridge for between Node1 and Node3, has just one
interface.  It makes sense because the scenario I am trying to build is in a
Wireless network, where Node1 and Node3 can not reach each other.

What happens, when I start the client  is that the join/prune reach Node1,
the data traffic starts, but stops in Node2. Is it possible that when a data
traffic cames through one interface it can not be forwarded over the same
interface?

For the regular case I even agree that it makes sense, but in this scenario
Node1 and Node3 use Node2, that has just one interface.   The traffic is
registered and the data arrives up to node2 and when the client is killed
the join/prune passes through and the data flow stops.

I am trying to debug the code to see if what is happening is this, the node
is ignoring the data traffic, but I guess gdb doesn' t like me very much, it
is saying that "No source file named pim_mre_join_prune.cc", for example if
I try to put a break point there  :)

If it can help in some way, the log output of the join, is the following:
[ 2010/10/11 15:57:05 TRACE xorp_pimsm4 PIM ] RX PIM_JOIN_PRUNE from
10.0.1.3 to 224.0.0.13 on vif nasmesh0
[ 2010/10/11 15:57:05 TRACE xorp_pimsm4 PIM ] TX PIM_JOIN_PRUNE from
10.0.1.1 to 224.0.0.13 on vif nasmesh0
[ 2010/10/11 15:57:05 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V3_MEMBERSHIP_REPORT from 10.0.1.3 to 224.0.0.22 on vif nasmesh0
[ 2010/10/11 15:57:05 TRACE xorp_igmp MLD6IGMP ] Notify routing add
membership for (192.168.13.53, 232.0.0.1) on vif nasmesh0
[ 2010/10/11 15:57:05 TRACE xorp_pimsm4 PIM ] Add membership for
(192.168.13.53, 232.0.0.1) on vif nasmesh0
[ 2010/10/11 15:57:05 TRACE xorp_fea MFEA ] RX kernel signal: message_type =
1 vif_index = 0 src = 192.168.13.53 dst = 232.0.0.1
[ 2010/10/11 15:57:05 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from MFEA_4:
vif_index = 0 src = 192.168.13.53 dst = 232.0.0.1
[ 2010/10/11 15:57:05 TRACE xorp_pimsm4 PIM ] Add MFC entry: (192.168.13.53,
232.0.0.1) iif = 0 olist = .. olist_disable_wrongvif = OO
[ 2010/10/11 15:57:05 TRACE xorp_pimsm4 PIM ] Add dataflow monitor: source =
192.168.13.53 group = 232.0.0.1 threshold_interval_sec = 210
threshold_interval_usec = 0 threshold_packets = 0 threshold_bytes = 0
is_threshold_in_packets = 1 is_threshold_in_bytes = 0 is_geq_upcall = 0
is_leq_upcall = 1
[ 2010/10/11 15:57:05 TRACE xorp_fea MFEA ] Add MFC entry: (192.168.13.53,
232.0.0.1) iif = 0 olist = ..

Thanks in advance and best regards...

                     Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20101011/8497a15d/attachment.html