From: Jon Carmichael (jonc@xxxxxxxxxxx)
Date: Fri Sep 07 2001 - 20:42:23 GMT-3
The "frame" aspects seem to be most of the discussion of this thread and
probably helps everybody who participates, --even those who only read.
There is another side to this question that seems to me to have been
neglected, beyond the "frame" aspects, there is also the "OSPF" aspect.
The basic problem is that "frame" and "OSPF" come from two entirely
different histories and two different standard committees and do not play
together well. This is what creates the complexities we need to know for
the CCIE lab test where we need to know four different ways to make them
work together. When you take the lab test for real, --you will be given a
hint as to which flavor of ospf over frame is expected and it's important
that you know all four, --and more important: when it's broken can you "spot
the issue" that keeps it from working.
Flavor one... BROADCAST (very unusual)
If you try to get OSPF to treat the frame cloud as a broadcast (like
Ethernet), you can use inverse-arp without any problems, however this flavor
is not very popular in the real world, because it requires that you have a
pvc from and to every point in the cloud. Let's just call this one "weird"
and only say that if the lab test tells you that you must make OSPF see the
frame cloud as "broadcast" then it would require that you say so on every
interface as it's not the OSPF default. This flavor does not scale very
well.
If you say..
interface Serial0
ip ospf network broadcast
You will NOT need to hardcode your neighbors under the OSPF process ID.
OSPF in this case sends to the data link layer a single packet going to
224.0.0.5 (just like an Ethernet). It's up to the Frame Relay data link
layer to duplicate it for each VC, and OSPF is not aware of this.
Flavor two... NON-BROADCAST (the default).
In my opinion, this flavor is the most complex (and not really that bad)
because you can either statically map or inverse-arp and it will work. I
agree with Caslow, you should statically map everywhere in the lab, because
they will be very precise, and if you use inverse-arp, it's possible (more
than likely) that a PVC will come up that you aren't using, and that can
cost you frame-relay points. If you statically map, you should also turn
off inverse arp "no frame-relay inverse-arp" and even after you do that, you
can still loose points because the inverse arp may have happened before you
turned it off, --so follow that with a "clear frame inarp."
Enough about the frame aspects, --what about OSPF?
If you say
interface Serial 0
ip ospf network non-broadcast
You then have to also tell OSPF to change the address from 224.0.0.5 to an
exact interface to deliver the routing update, --that would be by saying
router ospf X
neighbor w.w.w.w
And then you get a "show ip ospf neighbor" that looks like...
Router#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
180.234.234.2 255 FULL/DR 00:01:37 180.234.234.2 Serial0
And you get a "show ip ospf interface Serial0"
Router#sho ip ospf int
Serial0 is up, line protocol is up
Internet Address 180.234.234.4/24, Area 0
Process ID 180, Router ID 180.234.234.4, Network Type NON_BROADCAST, Cost:
64
Transmit Delay is 1 sec, State DROTHER, Priority 0
Designated Router (ID) 180.234.234.2, Interface address 180.234.234.2
No backup designated router on this network
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 00:00:26
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 180.234.234.2 (Designated Router)
Suppress hello for 0 neighbor(s)
Flavor Three... POINT-TO-MULTIPOINT (in my opinion the best).
This one is the easiest one, -the one that makes the most sense in the real
world, no neighbor statements required, however it may NOT be the one you
see on the lab: why would they give you the easiest one? Please, do NOT
confuse the frame aspect of multipoint on a subinterface with the OSPF
network type of multipoint. The two are not necessarily related and it's
easy to get them confused.
You probably already know the frame aspect of multipoint is on the
sub-interface, --and looks something like...
interface Serial0
encapsulation frame-relay
interface Serial0.1 multipoint <--(layer 2 multipoint)
ip address x.x.x.x 255.y.y.y
The OSPF aspect of multipoint has to do with how we are going to pass
routing updates, --and is configured as...
interface Serial0
ip ospf network point-to-multipoint. <--(layer 3 multipoint)
And when you use this flavor you get a "show ip ospf neighbor" that looks
like...
Router#sho ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
180.234.234.2 255 FULL/ - 00:01:59 180.234.234.2 Serial0
And you get a "show ip ospf interface Serial0" that looks like...
Router#sho ip ospf int s0
Serial0 is up, line protocol is up
Internet Address 180.234.234.3/24, Area 0
Process ID 180, Router ID 180.234.234.3, Network Type POINT_TO_MULTIPOINT,
Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 00:00:03
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 2, Adjacent neighbor count is 1
Adjacent with neighbor 180.234.234.2
Suppress hello for 0 neighbor(s)
Router#
Flavor Four .. POINT-TO-POINT. (both layer 2 frame and layer 3 OSPF)
I won't go into the details, --as this is the easiest one to
configure, --most common in the real world enterprise networks. In the
real world, it's easy to understand and only has one disadvantage, that is
it burns IP subnets fast. But if you live in an enterprise and you are
using the 10.0.0.0, --you have addresses to BURN! You might as well burn
them.
JONC
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Roger Sohn
Sent: Friday, September 07, 2001 9:50 AM
To: Ccielab (E-mail)
Subject: OSPF over Frame-Relay - Interface-DLCI vs. Map IP/Broadcas
I'm running OSPF over Frame-Relay in a hub and spoke
configuration.(CCbootcamp labs) I've set up Router1(hub) to have interface
S0.1 (p2p) and interface S0.2(multipoint). For multipoint connections, it's
pretty easy because I just input map ip statements.
But for my p2p connection, I'm having trouble understanding when I'm
supposed to use the "frame-relay interface-dlci" , "frame-relay map ip", or
frame-relay map ip broadcast" statements on the hub and spokes. Can anyone
help shed some light on this?
I've tried using a combination of all 3 types on both the hub and spoke, and
every time the hub and spoke are able to ping each other without any
problems.
-Roger
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:15 GMT-3