Frame Relay - can't get the clear picture of it yet!

2001-01-02 Thread Jaeheon Yoo

Hi,

Before I bother you about this, I searched the archives, but I
can't get it clear to me. Sorry but this has been constantly irritating me.
I quess there's a big BUG in my understanding.

This example is roughly from Jeff Doyle's Routing TCP/IP pp.557~565

There is a star topology frame relay network. HQ is a hub router
with three branch routers BR1 , BR2 and BR3. Branch routers have only one
PVC each to HQ(This is a partially meshed FR network).
(point-to-point subinterfaces are not configured)

Please correct me if I'm wrong!

CASE 1  - UNICAST packet: Can BR1 ping to another branch router BR2?(I
believe so)  If it's YES, HQ is responsible for "relaying" ping to BR2.
What's happening is as follows:

1. BR1 originates a ping packet and encapsulates it with its own locally
significant DLCI number (for example, 200)

2. It is propagated via the established PVC through F/R Cloud to HQ with
HQ's local DLCI number (for example, 100: I understand there's no direct
correspondence between two DLCI numbers),

3. HQ's layer 2 (ie,F/R) strips F/R header off the received frame and
examines its destination IP, then decides it doesn't belong to HQ itself.

4. HQ's layer 2 looks up its frame relay maps configured statically or
dynamically(through Inverse ARP). If there is a matching entry for it,
It is properly encapsulated and propagated to BR1. If there's no matching
entry for it, HQ just drops it.

5. Finally BR2 receives the frame.


CASE 2 - BROADCAST packet: Can BR1 send RIPv1 updates to all other branch
routers BR2 and BR3 as well as to HQ. (I believe so)

1. BR1's RIP delivers RIPv1 updates to lower layer F/R, and if F/R is not
configured to propagate broadcast traffic, the packet is dropped,
Otherwise, if it is configured so through frame-relay map command)
It is propagated to HQ as explained step 1 of case 1. But in this case
destination ip is set to broadcast address 255.255.255.255.

2. In this case, HQ recognizes it as broadcast packet, so HQ replicates and
propagates the broadcast traffic to each PVC except originationing PVC

3. BR2 and BR3 receives the frame.

CASE 3 - BROADCAST revisited: If BR2 and B3 are directly connected,
from my understanding of CASE 2, there might be a broadcast storm like
what happens on LAN Switching.

All of this probable misunderstanding is due to my lack of field experience.
So I always try to read widely, which is the only way I can do now.
Please correct my ignorance.

Thanks in advance.

Jaeheon Yoo



_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]



Re: Frame Relay - can't get the clear picture of it yet!

2001-01-02 Thread Jaeheon Yoo


Hi,

I have revised it myself through some more research.

- Original Message -
From: "Jaeheon Yoo" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 02, 2001 6:38 AM
Subject: Frame Relay - can't get the clear picture of it yet!



 Hi,

 Before I bother you about this, I searched the archives, but I
 can't get it clear to me. Sorry but this has been constantly irritating
me.
 I quess there's a big BUG in my understanding.

 This example is roughly from Jeff Doyle's Routing TCP/IP pp.557~565

 There is a star topology frame relay network. HQ is a hub router
 with three branch routers BR1 , BR2 and BR3. Branch routers have only one
 PVC each to HQ(This is a partially meshed FR network).
 (point-to-point subinterfaces are not configured)

 Please correct me if I'm wrong!

 CASE 1  - UNICAST packet: Can BR1 ping to another branch router BR2?(I
 believe so)  If it's YES, HQ is responsible for "relaying" ping to BR2.

"Relaying" is actually "Routing".

 What's happening is as follows:

 1. BR1 originates a ping packet and encapsulates it with its own locally
 significant DLCI number (for example, 200)

Step 1 needs some enumeration. After BR1's IP layer decides BR2 is directly
connected on its F/R interface, it delivers the ping packet to layer 2(F/R)
for encapsulation. Then F/R looks up frame-relay maps (in this case, the
same DLCI number for BR2 MUST be "statically" mapped, because Inverse ARP
only
provides DLCI for HQ), if a matchng entry is found, it is properly
encapsulated and propagated to HQ. If not, the ping packet is just dropped.

  http://www.cisco.com/warp/public/125/15.html#15-A


 2. It is propagated via the established PVC through F/R Cloud to HQ with
 HQ's local DLCI number (for example, 100: I understand there's no direct
 correspondence between two DLCI numbers),

When it is sent, the frame has a DLCI configured at BR1, when received it
has
a DLCI configured at HQ.
Through the F/R cloud a F/R switch changes it as preprogrammed.


 3. HQ's layer 2 (ie,F/R) strips F/R header off the received frame and
 examines its destination IP, then decides it doesn't belong to HQ itself.

   In this part, what is actually examing its destination ip is NOT layer
2(F/R) BUT layer 3(IP), it consults routing table for its destination. And
it decides it's directly connected on the same coming interface, therefore
it decrements TTL by one and delivers the packet to layer 2(F/R)


 4. HQ's layer 2 looks up its frame relay maps configured statically or
 dynamically(through Inverse ARP). If there is a matching entry for it,
 It is properly encapsulated and propagated to BR1. If there's no matching
 entry for it, HQ just drops it.

 5. Finally BR2 receives the frame.


 CASE 2 - BROADCAST packet: Can BR1 send RIPv1 updates to all other branch
 routers BR2 and BR3 as well as to HQ. (I believe so)


I guess I was wrong on this. In some how, update routing information could
be delivered to other branch routers, but the same original broadcast packet
never get to other branch routers, even if broadcast is enabled. So
following step 2 and step 3 is totally wrong.

 1. BR1's RIP delivers RIPv1 updates to lower layer F/R, and if F/R is not
 configured to propagate broadcast traffic, the packet is dropped,
 Otherwise, if it is configured so through frame-relay map command)
 It is propagated to HQ as explained step 1 of case 1. But in this case
 destination ip is set to broadcast address 255.255.255.255.

 2. In this case, HQ recognizes it as broadcast packet, so HQ replicates
and
 propagates the broadcast traffic to each PVC except originationing PVC


But the packet is self originated, it replicates and propagates the
broadcast traffic to each broadcast enabled PVC. And what is responsible for
"replicating" is HQ's layer 2(F/R). Am I right?

 3. BR2 and BR3 receives the frame.

 CASE 3 - BROADCAST revisited: If BR2 and B3 are directly connected,
 from my understanding of CASE 2, there might be a broadcast storm like
 what happens on LAN Switching.

I guess this is totally wrong.

Please confirm my understanding. From this I concluded that what is
important is: What type of the network it is viewed as, NBMA,
point-to-point, or
point-to-multipoint.

My next question: Does branch router BR1 have the same routing table when it
is configured as just NBMA and when as point-to-multipoint under OSPF?


 All of this probable misunderstanding is due to my lack of field
experience.
 So I always try to read widely, which is the only way I can do now.
 Please correct my ignorance.

 Thanks in advance.

 Jaeheon Yoo



 _
 FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
 Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]



_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]