From: Alexandre Ribeiro (alexandregomesribeiro@gmail.com)
Date: Tue Apr 29 2008 - 16:02:49 ART
Thanks everyone. I didn't remember the TTL of 1 of OSPF messages. And even
though I was being hit in the head with TTL exceeded messages, I was dumb
enough not to figure it out. Oh well, at least this helps me to keep my ego
in check :-)
P.S- ">without L2 connectivity, there is no circuit... If your laptop was
plugged
into a lan, and I used scissors to cut the cat5 cable, could you get online?
Well, what does the fr switch do with no pvc?
"
Oh come on Joe, do I really sound like such a newbie? I guess that teaching
CCNA classes makes you dumb down your answers :-P
On Tue, Apr 29, 2008 at 4:36 PM, Joseph Brunner <joe@affirmedsystems.com>
wrote:
> What I wanted to understand is why the hub MUST have L2 connectivity to
> the
> spokes
>
> >without L2 connectivity, there is no circuit... If your laptop was
> plugged
> into a lan, and I used scissors to cut the cat5 cable, could you get
> online?
> Well, what does the fr switch do with no pvc?
>
> so I figured that these messages
> should reach R3 from R2 and vice-versa. But no...
>
> >not without a pvc from r3 -> r2 and in your case of NBMA (default for
> physical frame relay) more neighbor statements... regarding your design,
> A Router in any more does not "reflect" the ospf traffic between spokes...
>
> >Hence why its called NBMA. If you are going to reach someone, you had
> better have a pvc built... if not, well sorry...
>
>
> 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?
>
> >No it shouldn't... if the TTL is 1, no ip packet is ever forwarded...
> Again, R3 and R2 will need a DIRECT PVC between them... build on and give
> R3
> or R2 the other's address. They will go "FULL/" without R1.
>
> -Joe
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Alexandre Ribeiro
> Sent: Tuesday, April 29, 2008 10:51 AM
> To: ccie forum
> Subject: A simple OSPF question (but perhaps a not so simple answer)
>
> 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
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
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