> 1. In a Frame-Relay network, If a router interface / sub-interface is
> configured as "point-multipoint".
There are "point-to-point" and "multipoint". The former is a subset of
the latter. There's no reason that I know of to ever use the former, as
it constrains your subsequent configuration options.
> Does it mean that the FRAD will recieve information on the local as
> well as remote DLCI information on its associated PVC's using the
> LMI interface?
There's no such thing as a "remote DLCI". DLCI's have local significance
only. If you try to think of DLCIs at other sites as being "remote DLCIs"
you'll just confuse yourself in exactly the way you're doing now. So no,
you can't receive information about "remote DLCIs" because they don't
exist.
> in a hub & spoke topology wherein multiple branch offices are
> connected to the central office, Could a single interface on the
> central office router be associated with multiple PVC's to the
> branch offices, wherein the interface would be configured in
> multipoint mode.
Yes. That's what "multipoint" mode allows you to do, that
"point-to-point" does not. However, this is not a trick you want to do
unless you REALLY UNDERSTAND the implications. If you do this, you'll
only be able to put one access list on the whole group of PVCs that
terminate on that logical interface, which is one good reason not to do
it. Also, you'll have to put all but one of your interface's IP addresses
in as "secondary" IP addresses for the interface, which is a little ugly.
Also, some people prefer to use "interface dlci" statements rather than
"frame map" statements, and throwing all the DLCIs onto one logical
interface obviously precludes using an "interface dlci" statement.
> 2. Why are "point-point" interfaces configured explicitedly with
> the local DLCI address?
All interfaces are configured with the DLCI they're supposed to be talking
to. How else would they know what DLCI to talk to?
> 3. On a point-Multipoint interface with connections to more than one
> destination, How does the OSPF adjacency form. Is it similar to a
> broadcast interface, wherein after the InARP process, hello packets are
> replicated to the respective remote IP addresses of the remote routers,
> which are discovered through the InARP process.
> 4. I have heard that OSPF neighbors have to be configured manually in an
> NBMA network. How is this network different from using Frame-Relay in
> either point-point or point-multipoint mode.
This is all sort of one big question. On a frame network, which is
essentially a big batch of point-to-point PVCs, you need to define OSPF
neighbors, which are then treated as though they were across
point-to-point links. There's no broadcasting going on, since frame
doesn't play well with broadcasts, since it's split-horizon by nature.
> 5. I know that DLCI's have only local significance
Keep repeating that to yourself until you believe it, and all your
remaining questions will go away. Then you'll understand frame relay.
:-)
> Customer 1 is associated with a local DLCI number 1
Let's call it 16, actually.
Customer 1 Frame Sw 1
+---+ +---+
| |16 16| |17
| +-----------+ +----->
| | | |
+---+ +---+
> conected to Frame-Relay switch 1. Now if the other end of the PVC
> is numbered as follows DLCI number 2
Let's stick with a real-world example, and make that 16 also.
Customer 1 Frame Sw 1 Customer 2
+---+ +---+ +---+
| |16 16| |17 16| |
| +-----------+ +-----> <-----+ |
| | | | | |
+---+ +---+ +---+
> connected to Frame-Relay switch 2.
Customer 1 Frame Sw 1 Frame Sw 2 Customer 2
+---+ +---+ +---+ +---+
| |16 16| |17 16| |17 16| |
| +-----------+ +-----> <-----+ +-----------+ |
| | | | | | | |
+---+ +---+ +---+ +---+
> Now assume the connection between Frame-Relay switch 1 & 2 is via another
> switch called 3. If switch 3 has a DLCI associated with it called 2.
Customer 1 Frame Sw 1 Frame Sw 3 Frame Sw 2 Customer 2
+---+ +---+ +---+ +---+ +---+
| |16 16| |17 16| |17 16| |17 16| |
| +-----------+ +-----------+ +-----------+ +-----------+ |
| | | | | | | | | |
+---+ +---+ +---+ +---+ +---+
How would you know that, and why would you care? Since it can't have a
DLCI called 2, I'll just give it 16 and 17, which it would have.
> What would happen if switch 1 is forwarding traffic destined to
> remote DLCI 2
No such thing, remember? We're forwarding traffic across the defined PVC
bridging map, between TWO LOCAL DLCIs. Each of the three switches in the
diagram forward from DLCI 16 to DLCI 17, and DLCI 17 to DLCI 16.
> which belongs to switch 2. Now since switch 3 is the transit point, What
> would happen when the traffic reaches switch 3, Will it forward it to its
> locally associated DLCI 2
It'll pass everything that enters on DLCI 16 out DLCI 17, and everything
that enters on DLCI 17 out DLCI 16. It's a switch, it doesn't know about
anything that's not directly attached to it.
> or will it pass it on to the switch 2 which is
> the actual destination.
Yes. That was an inclusive or.
> 6. I understand that many FR switches support layer 2 routing
No such thing. If they supported routing, they'd be routers. If they
supported routing, they'd be operating at layer 3, not layer 2. They're
switches. They operate at layer 2. They switch.
> Now FR switching is based on static entries such as "Incoming port
> / Incoming DLCI switched to Outgoing port / Outgoing DLCI". Now if
> a particular path connected to outgoing port, How will the switch
> reroute the traffic, Just trying to associate the switching
> technique to normal routing, where rerouting is only possible in the
> case of Dynamic routing, & not static tables.
The point of frame relay isn't to dynamically modify layer 2 paths... You
should create redundant layer 2 paths, and use routing to load-balance or
choose between them. Yes, some frame relay service providers use a
hacked-up version of OSPF to try to do dynamic provisioning and rerouting,
but it generally breaks, so most of us would really rather they didn't
try. Note that the WorldCom frame relay outage in the summer of 1998 was
caused by the rerouting algorithm, and took WorldCom's ENTIRE NETWORK down
for TEN DAYS. Not a good thing to do. Many clueless people do, though.
We need better provisioning systems and more clueful telco engineers, not
botched attempts at dynamically routing around damage down at layer 2,
where smart customers don't care about it.
-Bill
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:16 EDT