multipoint/p2p on a serial link

exkor5000

hello

in the following FR ocnfiguration:

R1(config)#interface ser 1 multipoint
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#encap frame-relay 
R1(config-if)#frame-relay interface-dlci 105
R1(config-if)#frame-relay map ip 192.168.1.5 105 broadcast
%LINK-3-UPDOWN: Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
21:49:39: %FR-5-DLCICHANGE: Interface Serial1 - DLCI 105 state changed to ACTIVE

what would be the difference of replacing multipoint with point-to-point in the first line?

Thanks

exkor5000

I guess I missphrased the question

I meant to ask, if it would actually matter if I used multipoint for only one DLCI? would this cause any problems?

The configurations I've posted work fine, and the ping goes through, however if using multipoint and point-to-point would not matter for a single DLCI then why Cisco bothers keeping 2 terms?

BubbaJ

exkor5000 wrote:

I meant to ask, if it would actually matter if I used multipoint for only one DLCI? would this cause any problems?

The configurations I've posted work fine, and the ping goes through, however if using multipoint and point-to-point would not matter for a single DLCI then why Cisco bothers keeping 2 terms?

Check out how OSPF treats multipoint vs. point-to-point connections. There are a lot of things that must match on both sides for an adjacency to form. Multipoint should be used on the hub in a partial-mesh or hub-and-spoke topology. Point-to-point should be used as it is named, but there are many different combinations. Either way, those are only used on sub-interfaces. Physical interfaces are treated as NBMA unless you use the ip ospf network command.

EdTheLad

exkor5000 wrote:

I guess I missphrased the question

I meant to ask, if it would actually matter if I used multipoint for only one DLCI? would this cause any problems?

Split-horizon is disabled by default on a multipoint interface, so if your using a distance vector routing protocol you could have possible loop problems.
A ptp FR interface has split-horizon enabled by default, one reason split-horizon is disabled on the multipoint interface is due to ospf.If you have
a partial mesh, in order for updates from the DR to be propagates to all DRothers they will need to be forwarded between subinterfaces on the same
physical port, this is because with the partial mesh setup the DR doesnt have a direct connection to all routers.

BubbaJ

ed_the_lad wrote:

Split-horizon is disabled by default on a multipoint interface, so if your using a distance vector routing protocol you could have possible loop problems.
A ptp FR interface has split-horizon enabled by default, one reason split-horizon is disabled on the multipoint interface is due to ospf.If you have
a partial mesh, in order for updates from the DR to be propagates to all DRothers they will need to be forwarded between subinterfaces on the same
physical port, this is because with the partial mesh setup the DR doesnt have a direct connection to all routers.

OSPF doesn't use split horizon. RIP and EIGRP do, but EIGRP doesn't necessarily follow the rules RIP does. Other protocols such as Multicast also have a split horizon rule. Do some research on cisco.com.

EdTheLad

BubbaJ wrote:

ed_the_lad wrote:

Split-horizon is disabled by default on a multipoint interface, so if your using a distance vector routing protocol you could have possible loop problems.
A ptp FR interface has split-horizon enabled by default, one reason split-horizon is disabled on the multipoint interface is due to ospf.If you have
a partial mesh, in order for updates from the DR to be propagates to all DRothers they will need to be forwarded between subinterfaces on the same
physical port, this is because with the partial mesh setup the DR doesnt have a direct connection to all routers.

OSPF doesn't use split horizon. RIP and EIGRP do, but EIGRP doesn't necessarily follow the rules RIP does. Other protocols such as Multicast also have a split horizon rule. Do some research on cisco.com.

OSPF doesnt use split horizon correct, but my example was discussing OSPF
on top of FR.If you have a partial mesh and are using OSPF how do you think the DR will communicate with the DRothers if it is not directly connected.The hello packets need to be sent to the DRothers, if split horizon is enabled on the FR multipoint interface these hellos cannot be forwarded out the the other subinterface dlci's.So with split horizon enabled on the multipoint interface ospf adjacencies cannot be formed with routers that are not directly connected.When you disable split horizon on the multipoint interface the hellos can then be forwarded and the adjaceny to the DR can be formed.Try it out in your lab and do some reading on www.cisco.com

BubbaJ

ed_the_lad wrote:

if split horizon is enabled on the FR multipoint interface these hellos cannot be forwarded out the the other subinterface dlci's.So with split horizon enabled on the multipoint interface ospf adjacencies cannot be formed with routers that are not directly connected.When you disable split horizon on the multipoint interface the hellos can then be forwarded and the adjaceny to the DR can be formed.

That is completely incorrect. OSPF does not know about split horizon. The scenario you described really has to do with making (under the proper circumstances) the hub router the DR by using ip ospf priority.

In fact, by using multipoint interfaces on all the connected FR interfaces, OSPF will not elect a DR. Since the hellos are multicast on multipoint interfaces, it is very important to use the broadcast keyword on any frame-relay map statements. A multipoint interface will do a pseudo-broadcast by replicating it to all the DLCIs defined on the multipoint interface.

You need to do a little more research before you attempt your Lab Exam.