From: Cielieska Nathan (ncielieska@gmail.com)
Date: Sat Jan 05 2008 - 01:21:59 ARST
The way i understand it is this:
As long as you have a "broadcast" keyword attached to either
statement you are good. To add the broadcast statement to both (on a
spoke) breaks the requirement
Scenario 1
Routers A (1.1.1.1) , B (2.2.2.2) , C (3.3.3.3) with B being the hub
Router B (s0/0.2 - ip add 2.2.2.2)
frame map ip 1.1.1.1 201 broad
frame map ip 3.3.3.3 203 broad
Router C (s0/0.3 - ip add 3.3.3.3)
frame map ip 2.2.2.2 302 broad
frame map ip 1.1.1.1 301
This will send the broadcast traffic to the HUB on your 302-203
mapping. The Hub will have another broadcast command on its other
frame map statement and forward the traffic (being broadcast) out to
the other neighbor (whether it reaches to destination is irrelevant..
its a broadcast). This will reach the hub and any established frame
mapping the hub has with the broadcast keyword.
Scenario 2
Routers A (1.1.1.1) , B (2.2.2.2) , C (3.3.3.3) with B being the hub
Router B (s0/0.2 - ip add 2.2.2.2)
frame map ip 1.1.1.1 201 broad
frame map ip 3.3.3.3 203 broad
Router C (s0/0.3 - ip add 3.3.3.3)
frame map ip 2.2.2.2 302
frame map ip 1.1.1.1 301 broad
This will send a broadcast to the other spoke, but will need to
traverse the hub.. so again.. this hits both of the neighbors
LONG STORY SHORT.. as long as you have the broadcast command on the
end of one of your frame map statements on the spoke and the frame
map broadcast on all of your frame map statements at the hub, the
broadcasts should flow throughout and in a non-redundant fashion.
Regards,
Nate
On Jan 4, 2008, at 7:01 PM, Ben Holko wrote:
> Hrm, I can't say I've seen that done before, but that would seem to
> send broadcasts to the spoke, which means they would transit the hub.
>
> So what you have put would be functionally the same (I think) as:
>
> frame map ip 1.1.1.1 101 broadcast
> frame map ip 1.1.1.2 101 broadcast
>
> Whereas to answer the original question and not send any broadcast
> to the spoke(s) from the other spoke(s), you need the following
> where 1.1.1.1 is the hub and 1.1.1.2 is the other spoke:
>
> frame map ip 1.1.1.1 101 broadcast
> frame map ip 1.1.1.2 101
>
> In relation to OSPF, in a hub and spoke frame-relay environment
> your two spokes are NOT adjacent. Adjacencies only occur with
> directly connected neighbours, and the spokes are not directly
> connected (they must map through the hub). For this reason, if you
> are using an OSPF network type which uses DR/BDR such as the
> network type broadcast, you need to make sure your spoke interface
> OSPF priorities are set to 0, else one of the spokes can become DR/
> BDR, and the other spoke(s) will not be able to access it - this
> breaks OSPF.
>
>
> Ben
>
>
> From: YourPal [mailto:dearprudence28@gmail.com]
> Sent: Saturday, 5 January 2008 1:58 AM
> To: Ben Holko
> Cc: Peter; ccielab@groupstudy.com
> Subject: Re: Statically mapping broadcasts
>
> Hi Ben,
> Is the following config functionally the same?
> !
> interface Serial1/0
> encapsulation frame
> no fram inv
> frame map ip 1.1.1.1 101 <- to the hub
> frame map ip 1.1.1.2 101 broadcast <- to the spoke
> !
> I understand the "broadcast" keyword is per protocol per DLCI.
> Correct me if I'm wrong.
>
> Thank you.
> BR,
> Emil
>
> On 1/4/08, Ben Holko <ben@holnet.net> wrote:
> They mean do not map to the spoke with the broadcast keyword, like
> this
> on the spokes:
>
> !
> interface Serial1/0
> encapsulation frame
> frame map ip 1.1.1.1 101 broadcast <- to the hub
> frame map ip 1.1.1.2 101 <- to the spoke
> !
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf Of
> Peter
> Sent: Friday, 4 January 2008 11:48 PM
> To: ccielab@groupstudy.com
> Subject: Statically mapping broadcasts
>
> Experts,
>
>
>
> Working in IEWB VOL2,
>
>
>
> Reading in the task:
>
> "Do not send any redundant broadcast traffic from the spokes to the
> hub"?
>
>
>
> I understood not to "statically map" broadcast traffic from spokes to
> the
> hub.
>
> However, when configuring OSPF later, not to use neighbor, requires
>
> broadcast to be correctly mapped for the 224.0.0.5 hellos to flow.
>
>
>
> Any comment what they mean by: "Do not send any redundant broadcast
> traffic
> from the spokes to the hub"?
>
>
>
> Cheers,
>
> Peter
>
> ______________________________________________________________________
> _
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Feb 01 2008 - 10:37:57 ARST