Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Frame relay hub-and-spoke question

4 views
Skip to first unread message

Learner

unread,
Jun 20, 2007, 12:50:37 PM6/20/07
to
I'm a frame-relay beginner (I'm studying for my CCNA).
All the sources I have read say that, in a hub-and-spoke frame relay
configuration using multipoint interfaces, spokes cannot communicate
directly unless static maps are configured, which tell the routers to
send traffic for the other spokes down the DLCI to the hub. And, of
course, this method works.
Now, my question is: why does this work? It seems that the hub acts as
a sort of frame-relay L2 "router", or switch, forwarding the inter-
spoke traffic. Or is this done by the FR switch inside "the cloud"?
Can someone clear up the process?

Also, since this trick provides full connectivity, does it turn the
hub-and-spoke effectively into a full mesh (eg, for OSPF etc.)?

Thanks in advance
Learner

stephen

unread,
Jun 20, 2007, 5:26:02 PM6/20/07
to
"Learner" <sun...@katamail.com> wrote in message
news:1182358237.4...@n2g2000hse.googlegroups.com...

> I'm a frame-relay beginner (I'm studying for my CCNA).
> All the sources I have read say that, in a hub-and-spoke frame relay
> configuration using multipoint interfaces, spokes cannot communicate
> directly unless static maps are configured, which tell the routers to
> send traffic for the other spokes down the DLCI to the hub. And, of
> course, this method works.
> Now, my question is: why does this work? It seems that the hub acts as
> a sort of frame-relay L2 "router", or switch, forwarding the inter-
> spoke traffic.

yes it does.

If you were to model it as a LAN, then direct paths between the spokes are
blocked, so the hub acts as a relay.

The idea is that the IP layer doesnt see the logical VC map between sites -
so that isnt exposed to L3 mechanisms that "cost" (CPU power, hello packets,
routing protocol adjacencies etc).

The L2 drivers deal with it and in some senses are more efficient than
driving each VC as if it was a separate subnet (mind you i never did agree
this is such a good tradeoff - but since F/R is dying and routers get bigger
/ faster / cheaper, the argument is academic these days).

Packets between 2 spokes cross the cloud once, go the the central hub
router, then go back across the cloud on a different VC.

>Or is this done by the FR switch inside "the cloud"?

No - the F/R "cloud" only sends packets across VCs - and if there was a
direct VC between 2 points then the packets wouldnt need to go to the
hub....

Note from a customer point of view a big chunk of F/R cost is from the
bandwidth of the access circuits - so traffic crossing the cloud 2 times
between spokes is not very efficient, and should be avoided for major
traffic flows.

> Can someone clear up the process?
>
> Also, since this trick provides full connectivity, does it turn the
> hub-and-spoke effectively into a full mesh (eg, for OSPF etc.)?

No - logically it is a star at IP layer (but remember that the F/R cloud may
have its own structure at a lower layer).
>
> Thanks in advance
> Learner
>
--
Regards

stephe...@xyzworld.com - replace xyz with ntl


Learner

unread,
Jun 22, 2007, 8:56:37 AM6/22/07
to
On 20 Giu, 23:26, "stephen" <stephen_h...@xyzworld.com> wrote:
> "Learner" <sun...@katamail.com> wrote in message
>
> news:1182358237.4...@n2g2000hse.googlegroups.com...
>
> > Now, my question is: why does this work? It seems that the hub acts as
> > a sort of frame-relay L2 "router", or switch, forwarding the inter-
> > spoke traffic.
>
> yes it does.
>[cut]

> > Also, since this trick provides full connectivity, does it turn the
> > hub-and-spoke effectively into a full mesh (eg, for OSPF etc.)?
>
> No - logically it is a star at IP layer (but remember that the F/R cloud may
> have its own structure at a lower layer).

Many thanks, makes more sense now.
Learner

0 new messages