From: Jason Guy \(jguy\) (jguy@cisco.com)
Date: Thu Jul 05 2007 - 12:54:15 ART
Ben,
I would say that sounds right. I would recommend, however, that you
make sure you know the function of the broadcast keyword and the way the
protocols function on this link. OSPF is the main gotcha in these
scenarios. So many modes and methods make it the most "interesting".
Be sure you know the OSPF types and how they work on the link. The
next-hop processing and the way links are advertised are also very
important concepts. I remember OSPF over FR being a big problem for me
a month or so ago. :-) In case you have not seen this, look at page 9
of this link. Someone was nice enough to send it to me when I was
learning this.
http://www.netmasterclass.net/doit/DOIT-Appendices.pdf
Cheers,
Jason
________________________________
From: Ben [mailto:bmunyao@gmail.com]
Sent: Thursday, July 05, 2007 11:39 AM
To: Jason Guy (jguy)
Cc: John Jones; Cisco certification
Subject: Re: FR static P2P mapping on physical interfaces
Thank you guys for your input.
The task requires the frame-relay connection between two routers to be
configured using the main interfaces, with no inverse-ARP.
I always use "broadcast" when creating static mappings for such a task.
From your suggestions, I gather that I should scan the IGP tasks for
this link, as well as the multicast tasks, to determine the way forward:
1. If the IGP is RIPv2, EIGRP, OSPF (all modes except NMBA), use the
"broadcast" keyword.
2. If the multicast topology will include this link, use the "broadcast"
keyword.
3. If neither of the above two applies, then don't use it, else you lose
points.
I hope I got this right.
Ben
On 7/5/07, Jason Guy (jguy) <jguy@cisco.com> wrote:
Ben,
I believe the broadcast keyword is only needed if the interface is going
to send multicast packets. So it depends on if the protocol running on
the interface needs to send multicast or unicast.
In your examples, OSPF in NBMA/P2MP-NMBA mode sends hellos as unicast.
In the case of RIP and EIGRP, by default they send everything as
multicast (broadcast for RIPv1). I think it is ok to add the broadcast
keyword to be safe, but that is probably not right for the lab and you
may lose points if the map is not correct for the situation. Obviously
if PIM is enabled for that FR link, you will need the broadcast keyword.
HTH,
Jason
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Ben
> Sent: Thursday, July 05, 2007 5:45 AM
> To: John Jones
> Cc: Cisco certification
> Subject: Re: FR static P2P mapping on physical interfaces
>
> John, Shiran
>
> Thank you for responding.
> I understand the use of "broadcast" in a hub and spoke scenario, and
why
> you
> need not send duplicate broadcasts from the spokes.
>
> In scenarios with point-to-point (P2P) connections, where the
requirement
> is
> to use main interfaces, no inverse-ARP, I do not understand when to
use
> the
> "broadcast" keyword with the "frame-relay map ip" command, and when
not to
> do so.
>
> The following situations come to mind:
>
> 1. If the IGP is OSPF in NBMA/P2MP-NMBA mode, do not use "broadcast"
> keyword.
>
> 2. If the IGP is OSPF in NBMA/P2MP-NMBA mode, use "broadcast" keyword.
>
>
> Are the above summations correct?
>
> If you use the "broadcast" keyword in situation 1. above, would you be
> penalised?
>
> Thanks
>
> Ben
>
>
>
>
>
> On 7/5/07, John Jones <acer0001@gmail.com> wrote:
> >
> > The "broadcast " keywork only needs to be used on one of the
mappings to
> > that DLCI. This avoids multiple broadcast packets from being
generated
> to
> > the same destination. Some labs have this as a requirement as well.
> >
> > John
> >
> >
> > On 7/5/07, Ben <bmunyao@gmail.com> wrote:
> > >
> > > Hi Group
> > >
> > > Some IE labs solution guides use the broadcast keyword on FR
static
> > > mappings
> > > for P2P FR on physical interfaces, while others do not.
> > >
> > > How do we determine when to use this keyword?
> > >
> > > Thanks
> > >
> > > Ben
> > >
> > >
>
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:39 ART