Hi Chad,
Hope things are working out.
I like your diagram, and then again I don't.
But maybe it's just me, I don't know, but I can't
understand it as much as I need to. I admire your
attempt, though, because it was properly spaced,
readable, and darn good for what it was.
But what I need is:
1) a box symbolizing each router, switch, hub, and host.
2) then a line into each box for each nic,
(the line representing your CAT5)
3) then the ipaddy/mask of each nic written next to the line.
4) If the internet comes into play, label that too.
I'll make an attempt to redo your drawing, but plz
fix it and then paste in your syslog trail of the packet
and include ip addr show
ip route show
and any other ip tunnel show thing you can think of that's relevant.
Roger.
172.24.8.???/24
__________ \ ______172.24.20.???/22
| | | |
|home agent|------------| LEAF |------------, <--subnet 172.24.20.0/22
|__________| |________| |
172.24.8.99/24 |
|
subnet 172.24.8.0/24 |172.24.20.104/22
_____|_______
| |
|foreign agent|
| (a host) |
|_____________|
| ???.???.???.???/24
?
? <--- What's this link, cat5?
?
?
| 172.24.8.24/24
____|______
| |
Is this another host?---> |mobile node|
|___________|
You said the foreign agent has only one nic. So it's a computer.
Is the mobile node a differnt computer? If so, how does it connect
to the foreign agent. If the link is cat5, then the foreign agent
has to have 2 nics and be a bridge, essentially.
Maybe the the mobile node is a virtual extension of the foreign
agent, and there's only the computers in the scenario:
1) Home computer
2) Leaf router
3) Foreign computer
Is that what's happening???? Well I'll stop for now :)
Plz check the addys/masks and fill in the blanks.
Matthew
Chad Carr wrote:
> On Fri, 27 Sep 2002 08:22:02 -0700
> "Matthew Schalit" <[EMAIL PROTECTED]> wrote:
>
>
>>Chad Carr wrote:
>>
>>>Hello routing and tunneling guys and gals! I have a tunneling quandry
>>>for ye.
>>>
>>>I am doing an implementation of mobile ip and have finally solidified
>>>all of the protocol bits to implement a foreign agent, and have come
>>>to the part where I need to accept ip-in-ip tunneled packets for a
>>>mobile node, detunnel them, and deliver them to him. I am using the
>>>kernel ipip.o module for this, and have configured the tunnel as
>>>follows:
>>>
>>> __________ _____________ ___________
>>> | | | | | |
>>> |home agent|===(router)===>|foreign agent|------->|mobile node|
>>> |__________| |_____________| |___________|
>>>
>>>
>>>home agent ip - 172.24.8.99
>>>foreign agent ip - 172.24.20.104
>>>mobile node ip - 172.24.8.24 (on the foreign network)
>>
>>
>>
>>I question the ip addresses below....
>>
>>
>>
>>
>>
>>>I am not in control of the home agent, but I have verified with a
>>>sniffer that he is sending me well-formed ip-in-ip packets for the
>>>mobile node, plus he works with anothe foreign agent that I have, so
>>>he is not the problem.
>>>
>>>foreign agent configuration:
>>>
>>># bring up tunnel device
>>>ip tunnel add mode ipip # (default tunnel tunl0; local *->remote *)
>>>
>>># add static arp table entry since mobile node can't reply
>>>ip neigh add 172.24.8.24 lladdr 00:00:0d:2f:a0:b0 dev eth0 nud perm
>>>
>>># add static host route
>>>ip route add 172.24.8.24 dev eth0
>>
>>
>>
>>
>>Is 172.24.8.24 really connected to eth0 or is the it eth1?
>
>
> My email was unclear on this. There is really only one interface in the
> foreign agent. The picture should look more like this:
>
> ___________
> | |
> |mobile node|<-----|
> __________ ________|___________| |
> | | | |
> |home agent|===(router)===| _____________ |
> |__________| |=======>| | |
> |foreign agent|----|
> |_____________|
>
>
> subnet 172.24.8.0/24 subnet 172.24.20.0/22
>
> That is, the mobile node and the foreign agent are on the same segment on
> the right-hand side of the router (the foreign agent is on the "right"
> segment, conceptually, and the mobile node is on the "wrong" segment,
> conceptually). There is a unicast ip-in-ip tunnel between the home agent
> and the foreign agent (on different segments; the router is needed to get
> packets back and forth on the tunnel between home agent and foreign agent)
>
>
>>>I have verified the following:
>>>
>>>1) The packets are getting delivered to the foreign agent;
>>>2) The packets are being accepted by tunl0 and processed;
>>>3) They are the expected size (the size of the inner ip packet);
>>>4) They are not being delivered anywhere outside the box.
>>
>>
>>
>>But it seems like you haven't enabled logging all packets on
>>the foreign agent that come from the home agent or are destined
>>for the home agent. I find adding those types of firewall rules
>>essential to these routing jobs. Seriously. Log them packys.
>>
>>Then you'd see if the traffic is even moving out eth0 on the
>>foreign agent on its way to the remote node.
>
>
> Okay, I added the following rules to the firewall:
>
> iptables -A PREROUTING -t mangle -j LOG
> iptables -A INPUT -t mangle -j LOG
> iptables -A FORWARD -t mangle -j LOG
>
> So, new information: I see the tunneled packet coming in on both
> PREROUTING and INPUT on interface eth0, as it should be. I then see the
> _unwrapped_ packet coming in on INPUT on interface tunl0.
>
> The destination address of the unwrapped packet is 172.24.8.24. I figure,
> according to the rules in Rusty's unreliable guide on iptables, that the
> packet should hit the FORWARD chain next (since it is not destined to the
> foreign agent itself), but is somehow failing some internal sanity check
> and getting dropped. After PREROUTING, a packet should hit either INPUT
> or FORWARD, correcto?
I'm sorry I don't know. I would think it would hit the INPUT
chain first (you have to let it in the nic), then PREROUTING
(you decide what to do with it), then FORWARD (route it) if necessary.
>>>I figure the following bits are true:
>>>
>>>The foreign agent is holding a copy of the ip packet addressed to the
>>>mobile node. He may do one of the following: a) assume that the
>>>packet is for delivery on the local link, look up the ip in the
>>>arp table, and deliver it to the mobile node b) hit the routing table
>>>again and see the host route, see that it is directly connected,
>>>look up the ip in the arp table, and deliver it to the mobile
>>>node. c) drop the packet
>>>
>>>Obviously, given the way I have configured the box, I believe that "b"
>>>should be what is happening. However, it seems plain that "c" is the
>>>option that has been chosen by the tunl0 device.
>>>
>>>I am obviously missing something quite overt, so I thought that one of
>>>you guys might be able to see what I can't.
>>
>>
>>
>> If you're running a /16 netmask all over, and you didn't tell
>>us that, then the packets should be accepted unless they are
>>dropped by the firewall rules or the config is wrong. At first
>>glance I don't spot anything wrong, but don't trust that :)
>
>
> Not a /16 netmask. The 172.24.0.0/16 is subnetted. 172.24.8.0/24 on the
> left of the router and 172.24.20.0/22 on the right of the router. I also
> have no firewall rules except for those enabling logging. The chains are
> completely flushed.
>
>
>> If the netmask is not /16 all around, then what have you done
>>on the foreign agent to tell it that it's bridging the two networks,
>>namely > foreign agent ip - 172.24.20.104
>> > mobile node ip - 172.24.8.24
>
>
> The foreign agent is not a bridge; there is a router between the home
> agent and foreign agent.
>
>
>> It'd help if you pasted in any relevant messages in from the foreign
>>agent syslog showing the trail of the packets being accepted and moving
>>in and out eth cards. Any masqing/forwarding enabled on the Foreign
>>Host?
>
>
> I don't have the logs at home this weekend, but hopefully the description
> above of the packets I am receiving and their devices clarifies this.
>
> I have done:
>
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
>
>>Well, got to walk the pooch. Hope I brought something up
>>that might be useful, Matt
>>
>
>
> Thanks for your help and input. I appreciate your time ready my hairy
> (and somewhat inaccurate) diagrams.
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
