From: Alexandre Ribeiro (alexandregomesribeiro@gmail.com)
Date: Tue Apr 29 2008 - 11:50:47 ART
Hello all,
I'm currently studying OSPF over FR with a bit more depth. I configured a
simple FR scenario, with R1 as the hub and R2 and R3 as spokes. I disabled
inarp and I statically mapped R2 and R1's ip address on R3, and R1 and R3 on
R2.
Now, the typical lab scenario would have you configure OSPF over this, with
or without changing OSPF's network type on the interfaces, or with or
without subinterfaces. I've done all possible lab configs and I'm over that.
What I wanted to understand is why the hub MUST have L2 connectivity to the
spokes, even if you're using OSPF's non-broadcast mode on the interfaces,
with neighbor commands for the respective neighbors. In order to reach a
conclusion, I enabled OSPF on R2 and R3 (but not on R1). I verified that
they had connectivity (ping), and I placed a neighbor command from R2 to R3
and vice-versa. Now, the neighbor command causes hello's, DBDs and LSA
updates to be sent as unicast messages, so I figured that these messages
should reach R3 from R2 and vice-versa. But no...
Doing a debug ip packet showed that even though hello's were being sent
between R2 and R3, they we're not arriving at their destination. I
replicated this scenario in Dynamips, captured the traffic, and I saw that
R1 (the hub) was receiving the hellos, but instead of forwarding them (it
should, they're IP packets), it replies with an ICMP TTL exceeded. Why does
this happen? If FR provides connectivity for IP, why doesn't it forward
OSPF's messages when they're being unicasted over IP?
Thanks in advance,
Alex
Pass the CCIE in six weeks, Guaranteed!
http://www.certscience.com/CCIE
This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:52 ART