From: Toh Soon, Lim (tohsoon28@gmail.com)
Date: Sat Aug 04 2007 - 08:00:21 ART
Hi Brajesh,
I think I got what you mean. The following two configs of R4 should be
functionally equivalent, i.e. to enable broadcast on DLCI 402 without
sending redundant broadcast traffic :
!
int s 0/0
frame-relay map ip 10.10.10.2 402 broadcast
frame-relay map ip 10.10.10.5 402
!
Or
!
int s 0/0
frame-relay map ip 10.10.10.2 402
frame-relay map ip 10.10.10.5 402 broadcast
!
I still need further clarification about your statement "...you are just
sending double broadcast traffic towards hub router". Say R4 has more than
one frame map statements with the "broadcast" keyword and it runs EIGRP over
the FR interface. Is it gonna send two copies of whatever EIGRP packets
(destined to 224.0.0.10) towards R2?
To quote you " In lab they may have mentioned something like "don't
duplicate broadcast traffic when sending data from spoke" ", do the
following two statements mean the same thing?
(1) Do not send any redundant broadcast traffic from the spokes to the hub.
(2) Ensure that Spoke1 and Spoke2 can ping each other's FR interface, but
this config should be performed such that Hub does not receive redundant
routing updates.
Thank you.
B.Rgds,
Lim TS
On 8/4/07, brajesh.thakur@wipro.com <brajesh.thakur@wipro.com> wrote:
>
> Dear Lim,
>
> If you are using 'broadcast' keyword for both map commands on spoke
> router, you are just sending double broadcast traffic towards hub router
> as broadcast is enabled per dlci basis and not per ip address basis. In
> lab they may have mentioned something like "don't duplicate broadcast
> traffic when sending data from spoke"
>
> Warm Regards,
> Brajesh Thakur
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Toh Soon, Lim
> Sent: Saturday, August 04, 2007 2:34 PM
> To: ccielab@groupstudy.com
> Subject: "frame-relay map broadcast" command for spoke-to-spoke
>
> Hi All,
>
> I have a hub-and-spoke frame relay network, the DLCIs are as follows:
>
> R2 (204)------------(402) R4
> (205)------------(502) R5
>
> R2 is the hub whereas R4 & R5 are the spokes.
>
> R2 Config
> ---------
> !
> int s 0/0
> ip add 10.10.10.2 255.255.255.0
> encap frame-relay
> no frame-relay inverse-arp
> frame-relay map ip 10.10.10.4 204 broadcast
> frame-relay map ip 10.10.10.5 205 broadcast
> !
>
> R4 Config
> ---------
> !
> int s 0/0
> ip add 10.10.10.4 255.255.255.0
> encap frame-relay
> no frame-relay inverse-arp
> frame-relay map ip 10.10.10.2 402 broadcast
> frame-relay map ip 10.10.10.5 402 broadcast
> !
>
> R5 Config
> ---------
> !
> int s 0/0
> ip add 10.10.10.5 255.255.255.0
> encap frame-relay
> no frame-relay inverse-arp
> frame-relay map ip 10.10.10.2 502 broadcast
> frame-relay map ip 10.10.10.4 502 broadcast
> !
>
> For the spoke routers, what's the difference if the frame map statement
> pointing to each other has the "broadcast" keyword compared to without
> the
> "broadcast" keyword? Either way, the spoke routers can ping to each
> other.
> I believe it has no bearing on routing protocol neighbor adjacencies.
> Adjacency is only established with the hub router as far as OSPF and
> EIGRP
> are concerned.
>
> My understanding is, the frame map statements are not even required
> between
> spokes when we run EIGRP or OSPF (p2mp) on the frame relay network.
>
> Please enlighten me.
>
>
> Thank you.
>
> B.Rgds,
> Lim TS
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:09 ART