Task 3.1 Wan technologies

TASK 3. WAN Technologies  (30 Minutes)
3.1. Partial Mesh
 Configure a Frame Relay connection between R1, R2, R4, and R5 using
the DLCIs provided in the diagram.
 Use only the physical interfaces on R1 and R5.
 Use multipoint subinterfaces on R2 and R4.
 Use only one Frame Relay map statement on R2 and R4.

Is it right to use Inverse arp on R1 and R5 ?? or is mandatory to use frame-relay maps  as in the solution document?

Rack1R1#show frame-relay map
Serial0/0/0 (up): ip 156.1.0.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0/0/0 (up): ip 156.1.0.5 dlci 105(0x69,0x1890), dynamic,
              broadcast,, status defined, active
Rack1R1#sh run int ser 0/0/0
Building configuration...

Current configuration : 163 bytes
!
interface Serial0/0/0
 ip address 156.1.0.1 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 no fair-queue
 clock rate 128000
end

Rack1R1#

Rack1R5#sh run int ser 0/2/0:1
Building configuration...

Current configuration : 131 bytes
!
interface Serial0/2/0:1
 ip address 156.1.0.5 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
end

Rack1R5#
Rack1R5#
Rack1R5#show fram
Rack1R5#show frame-relay map
Serial0/2/0:1 (up): ip 156.1.0.1 dlci 501(0x1F5,0x7C50), dynamic,
              broadcast,, status defined, active
Serial0/2/0:1 (up): ip 156.1.0.4 dlci 504(0x1F8,0x7C80), dynamic,
              broadcast,, status defined, active
Rack1R5#

SOLUTION GUIDE BY IE:

R5:
interface Serial0/0
ip address 156.1.0.5 255.255.255.0
encapsulation frame-relay
frame-relay map ip 156.1.0.1 501 broadcast
frame-relay map ip 156.1.0.4 504 broadcast
no frame-relay inverse-arp

Comments

  • I think using the dynamic mapping would be ok since there's no such thing mentioned in the Question. but i prefer to use frame-relay map statement disabling inverse-arp so I have the full control over the layer 3 to layer 2 mappings.

    HTH

  • In this task we are free use either dynamic or static mapping as long as it is meeting the task requirement. However static mapping is more appropriate solution.

  • Can't see any specific requirement but I would recommend to use specific map statement.

  • Another point to note is that if you use the frame-relay maps statements as detailed in the SG you will not have reachability within the frame relay cloud until task 4.5

  • Another point to note is that if you use the frame-relay maps statements as detailed in the SG you will not have reachability within the frame relay cloud until task 4.5

    Why are you saying so? if i remember this task correctly, after completing this task i had connectivity within the frame-relay cloud.

  • Why are you saying so? if i remember this task correctly, after completing this task i had connectivity within the frame-relay cloud.

    R2 and R4 are only allowed one frame-relay map statement and must be multipoint subinterfaces.  Assuming you didn't use frame-relay interface-dlci xxx (breaking the task requirement), R4 can only reach R5.  Traffic to R1 and R2 will result in an encapsulation failure!

    R5 could be configured with three frame-relay map statements, but only two are needed to make OPSF work in the later task i.e. to R4 and R1.  So R5 can't reach R2 - encapsulation failure.

    As above R1 with two frame-relay map statements can reach R5 and R1 but not R4!

    And finally R2 can reach R1 but not R4 or R5.

    These connectivity issues are kindly solved by OSPF coming to rescue with the "point-to-multipoint" network type as the next hop is changed and is advertised as a /32!

     

     

     

     

     

     

  • R5 could be configured with three frame-relay map statements, but only two are needed to make OPSF work in the later task i.e. to R4 and R1.  So R5 can't reach R2 - encapsulation failure.

    As above R1 with two frame-relay map statements can reach R5 and R1 but not R4!

    And finally R2 can reach R1 but not R4 or R5.

    Agree with you however I doubt we need to have spoke to spoke connectivity in a hub and spoke frame-relay environment unless explicitly specified or required such as for some ospf network types. 

  • Agree with you however I doubt we need to have spoke to spoke connectivity in a hub and spoke frame-relay environment unless explicitly specified or required such as for some ospf network types. 

    I agree with dcancerian, the best thing to do here is to follow the instructions, if the task does not ask for spoke-to-spoke connectivity, you don't need to worry about it.

  • Agree with you however I doubt we need to have spoke to spoke connectivity in a hub and spoke frame-relay environment unless explicitly specified or required such as for some ospf network types. 

    I agree with dcancerian, the best thing to do here is to follow the instructions, if the task does not ask for spoke-to-spoke connectivity, you don't need to worry about it.

  • Agree with you however I doubt we need to have spoke to spoke connectivity in a hub and spoke frame-relay environment unless explicitly specified or required such as for some ospf network types. 

    I agree with dcancerian, the best thing to do here is to follow the instructions, if the task does not ask for spoke-to-spoke connectivity, you don't need to worry about it.

    I was merely making an observation in my original post.  In most of the frame relay designs in this workbook - endpoint reachability is established once the relevant section 3 task has been completed.  This is not true in this particular case.

     

Sign In or Register to comment.