notes: OSPF Area types

OSPF Area

- Areas are identified by a 32-bit Area ID. The Area ID may be expressed either as a decimal number or in dotted decimal, and the two formats may be used together on Cisco routers. The choice usually depends on which format is more convenient for identifying the particular Area ID.

 area 0 and area 0.0.0.0 are equivalent, as are area 16 and area 0.0.0.16, and area 271 and area 0.0.1.15.

router ospf 1

network 155.1.146.1 0.0.0.0 area 0.0.0.0

network 155.1.147.1 0.0.0.0 area 0.0.1.16

LSA filtering is done in two ways:
   - Area Types
   - LSA 3 filtering see filtering below

note:
- When only a single area network is used, it doen not have to be area 0.
- The rule is that all areas must connect to the backbone; therefore, a backbone area is needed only if there is more than one area.

1.  Backbone (transit) - carries all LSA types.

2.  Normal Area - carry all LSA types, type1, type2, type3, type4, type5

3.   Stub Areas - Type 4 ASBR summary LSAs and 5 AS External LSAs are not flooded into stub areas.                
    - Still receives inter-area type 3 LSA's.
    - ABRs at the edge of a stub area use network summary (type 3) LSAs to advertise a single default route (0/0) into the area, for destination external to the AS.
    - The ABR will advertise this default route with a cost of 1.
    - This default cost can be changed with the "area default-cost" command.
    - Configured on ALL routers in the stub area with "area stub" command.
    - will not accept external routes, accept anything internal and default route.
    - LSA view:  type1, type2, type3 and 0/0 route

Stub area restrictions:-
    - All routers in a stub area must have identical link-state databases, and agree to be stub.
    - To ensure this condition, all stub routers will set a flag (the E-bit) in their hello packets to zero.
    - They will not accept hellos with E=1. (If the E-bit = Evil-bit, then Stub-Area = Holy-Area)
    - Virtual links cannot be configured within, nor transit, a stub area.
    - No router within a stub area can be an ASBR or perform any type of redistribution, including static and connect.

command:

- Configures attached area 1 as a stub area, required on all area routers
- Shows the default route in the routing table as 'O*IA 0.0.0.0/0'

router ospf 99

area 1 stub

4.  Totally Stubby Areas (cisco specific)

      - Uses a default route to reach not only destinations external to the autonomous system but also
all destinations outside the area.
     - The ABR of Totally Stubby Area will block all summary LSAs with the exception of a single type3 LSA to advertise a default route (0/0).
    - Configured with "area stub no-summary", which is necessary only at the ABR/s; the internal routers use the standard stub area configuration.
    - LSA VIEW: type 1 and type 2 + 0/0 default route.
    - does not allow any type 3 to come in. ( all other internal area routes are blocked)
    - one single type 3 LSA default route from ABR.
    - it can reach other areas but dont have the detail of the network because it only allows default route.
 
command:

 - Configures attached area 2 as a totally stubby area, only needed on ABR's
  - Shows the default route in the routing table as 'O*IA 0.0.0.0/0'

router ospf 99

area 1 stub no-summary

5.  NSSA (Not-So-Stubby Areas)

     - An area that allows redistributed while retaining the characteristics of a stub area to the rest of the AS.
     - No type 4 and 5 LSA's, but redistribution is allowed, ie AS-external routes.
     - The ASBR in an NSSA will originate type 7 LSAs to advertise the external destinations.
     - These NSSA external LSAs are flooded throughout the NSSA but are blocked at the ABR.
     - The NSSA ASBR has the option of setting or clearing the P-bit.
     - If the NSSA's ABR receives a type 7 LSA with the P-bit set to one, the type 7 LSA translates into a type 5 LSA before being flooded to other areas.
     - If the P-bit is set to zero, no translation will take place and the destination in the type 7 LSA will
not be advertised outside of the NSSA.
     - Configured on ALL routers in the NSSA area with "area nssa".
     - Biggest difference to a stub area, redistribution is allowed, and no default route by default is sent into the area.
     - With NSSA, the ABR does not originate a default route.
     - To originate a default into a NSSA area, use the command "area nssa default-originate".
    - LSA view: type1, type2, type3, type7

command:
- Configures attached area 3 to be nssa, required on all area routers
- NO default route is automatically generated.

router ospf 99

area 3 nssa

- Configures attached area 4 to nssa, only needed on ABR's to generate the default
- Shows the default route in the routing table as 'O*N2 0.0.0.0/0'

router ospf 99
area 4 nssa default-information-originate

6.   Totally NSSA
       - ABR makes an NSSA totally stubby, with 'area nssa no-summary'.
       - Removes inter-area (type 3) LSA’s.
       - Removes external (type 4 and type 5) LSA’s.
       - The ABR originates a default as 'O*IA'.
       - Configured with 'area nssa no-summary', which is necessary only at the ABR; the internal routers use the standard NSSA area configuration.
       - Allows redistribution into NSSA (LSA 7).
      LSA view:  type1, type2, type7 and 0/0 route

commands:

- Configures attached area 5 to totally-nssa, only needed on ABR's
- Shows the default route in the routing table as 'O*IA 0.0.0.0/0'

router ospf 99

area 5 nssa no-summary 

- Configures attached area 6 to totally-nssa with default redistribution disabled
- Will show the type 3 default route in the routing table as 'O*IA 0.0.0.0/0'

router ospf 99

area 6 nssa no-redistribution no-summary 

additional notes:

- All routers in a STUB or NSSA must agree on the STUB or NSSA flag. It is the ABR(s) of the stub or NSSA area that determines if it is totally-stubby or totally-NSSA by adding the keyword "no-summary" onto the stub/nssa command.

- The ABR generates the type 4 LSA. If the area is configured as a stub area, the ABR filters the type 5 LSAs(generated by the ASBR) and does not generate a type 4 LSA. So, technically, an OSPF stub configuration only explicitly filters type 5 LSAs, but it implicitly filters type 4 LSAs as well as there is no need for the ABR to generate a type 4 LSA.

- When an ABR is also an ASBR and is connected to a NSSA, the default behaviour is to advertise the
redistributed routes into the NSSA.
- This redistribution can be turned off by adding the 'no-redistribution' keyword to the "area nssa" command.

- Suppress OSPF forwarding address in translated type-5 LSAs
- This is used when an NSSA ABR translates type 7 LSAs to type 5 LSAs, but use the 0.0.0.0 as the forwarding address instead of the address specified in the type 7 LSA.

- Routers which are configured not to advertise forwarding addresses into the backbone, will directly forwarded traffic to the translating NSSA ASBRs.


======================================================
AREA TYPE     STOPS TYPE5     STOPS TYPE3     ALLOW TYPE7

stub                          yes                          no                        no
totally stubby           yes                          yes                      no
NSSA                       yes                          no                        yes
totally NSSA            yes                          yes                      yes
 ======================================================

area type options:


[stub] blocks type 4 and type 5 LSA's
[no-summary] blocks type 3 LSA's except the default route type 3 LSA
[nssa] blocks type 4 and type 5 LSA's, but allows type 7 redistribution
[no-redistribution] blocks type 7 LSA's

command:

- Changes the cost of the default route advertised by the ABR. (default = 1)

router ospf 99

area 1 default-cost {cost}

- Configures a nssa, allowing type 3, blocking type 4, 5 and 7
- Will show the type 7 default route in the routing table as 'O*N2 0.0.0.0/0'

router ospf 99 
area 7 nssa no-redistribution default-information-originate


- Suppresses the inclusion of a forwarding address when translated into type 5 LSAs

 router ospf 99
area 8 nssa translate type7 suppress-fa

notes: OSPF Router types and LSA (link state advertisement)

Router Types

- All OSPF routers will be one of four router types:

1.  Internal - Are routers whose interfaces all belong to the same area. These routers have a single link-state database.  exchange LSAs  only with routers in the same area.

2.  Backbone - Are routers with all interfaces attached to the backbone.

3.  ABR - Connect one or more areas to the backbone and act as a gateway for inter-area traffic.  Has at least one interface, which belongs to the backbone, and must maintain a separate link-state database for each of its connected areas.

4.  ASBR - Is a gateway to external traffic. It injects routes into the OSPF domain that was learned (redistributed) from another external protocol.


LSA (Link State Advertisements)

- LSA is the OSPF data structure used to describe topology information.
- LSAs are aged as they reside in the link-state database.
- MaxAge (1 hour) is the time if reached when LSAs are flushed from the OSPF domain.
- LSRefreshTime (every 30 min): The router that originated the LSA floods a new copy of the LSA with an incremented
sequence number and an age of zero.


LSA types:

1. Router LSAs (intra Area)
   - Are produced by every router for all its own connected interfaces.
   - Lists all of a router's links, or interfaces, the state and outgoing cost of each link, and any known OSPF   neighbors on the link.
  - Local area flooding scope.
  - Describes the intra-area routes (Displayed as 'O' routes in the RIB)
  - Can be seen with "show ip ospf database router".

2. Network LSAs (intra area)
    - Are produced by the DR on every multi-access network.
    - Lists all attached routers, including the DR itself.
    - Local area flooding scope.
    - Describes who is the designated routers on a segment.
    - Can be seen with "show ip ospf database network".

3. Network Summary LSAs (inter area)
    - Are originated by ABRs.
    - Are sent into a single area to advertise destinations outside that area, but still internal to the OSPF
      autonomous system.
    - Default routes external to the area, but internal to the OSPF autonomous system, are also advertised
       by LSA type 3.

    -  Inter-Area flooding scope.
    - Describes the inter-area routes (Displayed as 'O*IA' routes in the RIB)
    - Can be seen with "show ip ospf database summary".
    - on different area, next-hop to reach the other network is via ABR

4.  ASBR Summary LSAs
     - Are originated by ABRs.
     - Are identical to network summary LSAs, except that the destination they advertise is an ASBR, not a
       network.
     - Inter-Area flooding scope.
     - Describes who is doing the redistribution.
     - Can be seen with "show ip ospf database asbr-summary".
              area0
         -------------ABR-------------------ASBR
           type4<------|                type1<-------|
 
     Note:  ABR will take type 1 from ASBR & convert it to type 4 (domain wide) for next-hop reachability to ASBR.
          
5.  AS External LSAs (domain wide)
     - Are originated by ASBRs.
     - They advertise either a destination external to the OSPF autonomous system, or a default route external to the OSPF autonomous system.
    - AS External LSAs are the only LSA type that are not associated with a particular area.
    - Autonomous system wide flooding scope.
    - Describes what routes were redistributed (Displayed as 'O*E1' or 'O*E2' routes in the RIB)
    - Can be seen with "show ip ospf database external".


6.  MOSPF
    - Cisco routers do not support LSA Type 6 (MOSPF), and generates syslog messages if such packets are
      received.
   - It might be necessary to configure a router to ignore these packets and to prevent a large number of syslog messages
  - Configured with "ospf ignore lsa mospf"

7.  NSSA External LSAs
    - Are originated by ASBRs within not-so-stubby areas (NSSAs).
    - Similar to an AS External LSA, except NSSA External LSAs are flooded only within the not-so-stubby
 areas in which it was originated.
   - Describe redistributed routes within a NSSA area (Displayed as 'O*N1' or 'O*N2' routes in the RIB).
   - Can be seen with "show ip ospf database nssa-external".

              area0                   nssa

         -------------ABR-------------------
           type5<------|                type7<----
 note: type 7 only exists in nssa


10.  Opaque LSAs
       - Have been used to add various extensions to OSPF, such as traffic engineering parameters for MPLS networks.
 
OSPF Link-State Database Overload Protection with MAX-LSA
 - Allows you to limit the number of nonself-generated LSAs for a given OSPF process.
 - Used to prevent excessive LSA's generated by other routers in the OSPF domain from substantially draining the CPU and memory resources of the router.
- Configured with "max-lsa"

OSPF LSA Throttling
 - Provides a dynamic mechanism to slow down link-state advertisement (LSA) updates in OSPF during times of network instability.
 - Also allows faster OSPF convergence by providing LSA rate limiting in milliseconds.
 - Configured with "timers throttle lsa all"

commands:

show commands:

- Displays the number of LSAs in a link-state database by area and by LSA type

show ip ospf database database-summary 

- Shows a list of the different LSAs in a link-state database 

show ip ospf database [router|netw|sum|asbr-sum|ext|nssa-ext]


ospf process commands:

router ospf {pid}

- Allows more LSA's to be grouped together before being flooded (default=4min)

timers pacing lsa-group 

- Changes the group pacing interval of LSA's

timers lsa-group-pacing {seconds} 

- Changes the delay time between receiving a topology change and SPF calculation

timers spf {spf-delay} {spf-holdtime} 

- Ignore MOSPF LSA packets, stops generating syslog messages.

ospf ignore lsa mospf

- Block the flooding of OSPF LSA packets only to a specific neighor

neighbor {ip} database-filter all out 

- limit LSAs  recieved from neighbor

max-lsa {max-no} [threshold-%] [warning-only] [ignore-time] [ignore-count] [reset-time]

- {max number}: of non-self-generated LSA’s that can be kept in the OSPF LSDB
- [threshold]: Percentage at which a warning message is logged. The default is 75%
- [warning-only]: OSPF process never enters ignore state. (Def = Disabled)
- [ignore-time]: time to ignore neighbors after the limit's exceeded. (Def = 5 min)
- [ignore-count]: number of times consecutively to enter ignore state. (Def = 5)
- [reset-time]: time before ignore count gets reset (Def = 10 min)

- limit LSAs from redistribution

  redistribute maximum-prefix (#prefix) [opt]

    - withdraw - stops redistribution if max reached.

OSPF throttling

timers throttle lsa all {start-interval} {hold-interval} {max-interval}

- Sets the rate-limiting values (in milliseconds) for LSA generation
- {start-interval}: (Def = 0 ms)
- {hold-interval}: (Def = 5000 ms)
- {max-interval}: (Def = 5000 ms)

interface command:

interface s0/0

ip ospf database-filter all out

- Block the flooding of OSPF LSA packets out the interface


Flood reduction
we have LSA updates,  every 30 minutes it will refresh entire database to ensure stability, in a large network it will cause a blip in the network.
note:  will affect voice traffic which is critical in the network.

command:

int e0/0

ip ospf flood-reduction

notes; OSPF Finite State Machine

- An OSPF router transitions a neighbor through several states before the neighbor is considered fully adjacent:

1.  Down - The initial state of a neighbor conversation indicates that no hellos have been heard from
the neighbor in the last router dead-interval.  If a neighbor transitions to the down state, the link state retransmission, database summary, and link state request lists are cleared.

2.  Attempt - This state applies only to neighbors on NBMA networks, where neighbors are manually configured.  A router sends packets to a neighbor in attempt state at the hello-interval instead of the poll-interval.

3.  Init - This state indicates that a hello packet has been seen from the neighbor in the last router dead-interval, but two-way communication has not yet been established.

4.  2Way - Indicates that the router has seen its own router ID in the neighbor field of the neighbor's hello packets, meaning bidirectional conversation has been established.  On multi-access networks, neighbors must be in this state or higher to be eligible to be elected as the DR or BDR.

5.  ExStart - The router and its neighbor will establish a master/slave relationship and determine the initial DD sequence number to exchange of Data Descriptor Packet's (DDP’s).  The neighbor with the highest router ID becomes the master.

6.  Exchange - The router sends DDP's describing in summary its entire link-state database to neighbors that are in the Exchange state.  The router may also send Link State Request packets, requesting more recent LSAs, to neighbors in this state.

7.  Loading - The router sends Link State Request packets to neighbors, requesting more recent LSAs that have been discovered in the exchange state but have not yet been received.

8.  Full - Neighbors in this state are fully adjacent, and the adjacencies appear in router LSAs and network LSAs.


- The adjacency building process uses four OSPF packet types

1.  DDP: Database Description packets (type 2) - Carry a summary description of each LSA in the originating router's link-state database.
       These descriptions are not the complete LSAs.   
         Three flags in the DD packet are used to manage the adjacency building   

         process:                                
        - I-bit, or Initial bit, when set indicates the first DD packetsent.                                                      
        - M-bit, or More bit, when set indicates that this is not the last DD packet to be sent.
        - MS-bit, or Master/Slave bit, is set in the DD packets originated by the master.


2.  LSR: Link State Request packets (type 3)
3.  LSU: Link State Update packets (type 4)
4.  LSAck: Link state Acknowledgement packets (type 5)

- All LSAs sent in update packets must be individually acknowledged, by one of two means:

1.  Explicit Acknowledgment - A Link State Acknowledgment packet containing the LSA header is received.

2.  Implicit Acknowledgment - A update packet that contains the same instance of the LSA is received.  Do not confuse LSA (Link State Advertisement) with LSAck (Link state Acknowledgement).

notes: OSPF and Frame Relay

Keypoints:

1.  matches network types or interface types
      i.e. physical interface (multipoint) while IP OSPF type is point-to-point
      - timers wont match if the interface types are different.

2.  Remember that Broadcast & Non-Broadcast try to elect DR/BDR (hub must be the DR)

3.  "Broadcast" keyword statement if using frame maps
      - not running non-broadcast unicast fashion need a broadcast parameter.

4. Router ID
    - read first the LAB if there is requirement for RID same as BGP

      router ospf 1

      router-id 1.1.1.1 

5.  DR /BDR
     - the higher # the better
        first - highest priority
        2nd - highest RID

6.  DR @ Multipoint FR
     - multiple spokes connected to the hub router.
     - ensure all host has a direct connectivity to the hub.
note: OSPF packets have TTL of 1, so if you have a "frame-map" statement going from spoke to spoke still will not be able not talk to each other.

CCIE LAB:  Frame relay network by default will show up believing that other routers are DR.
          a.  you can use priority command on the interface  @ spoke set priority to 0.

7. Some network interface types requires neighbor command like non-broadcast and point-to-multipoint nonbroadcast. so it is important to look at network type using " show ip ospf interface"

       router ospf pid

       neighbor {ip} [priority {pri}] [cost {cost}]

              note: the cost  here are associated to the cost of the link.


Problem Areas in Frame Relay

Network Type:
connecting point-to-point/point-to-multipoint to physical interface:

to verify the network type:  show ip ospf interface

by default
physical interface network type is non-broadcast  with hello/dead  30/120 then must have DR.
on another side of the link (can be the hub) subinterface running in point-to-multipoint will have hello/dead of 30/120 and dont elect DR.

hub (point-to-multipoint)-----------------------(physical)spoke
bye default it will never peer-up

so carefully watch in the ccie lab if you are not allowed to hange the network type of a router.

LAB: PPP over Frame Relay

Requirements:  no router may use subinterface

==============================================
100.100.100.0/24

R2

int virtual-template 1

ip address 100.100.100.2 255.255.255.0 

bandwidth  64

int s0/1/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 204 ppp virtual-template 1

frame-relay interface-dlci 205 ppp virtual-template 1

frame-relay interface-dlci 206 ppp virtual-template 1

R4

int virtual-template 1

ip address 100.100.100.4 255.255.255.0 

bandwidth  64

int s0/0/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 402 ppp virtual-template 1

R5

int virtual-template 1

ip address 100.100.100.5 255.255.255.0

bandwidth  64

int s0/1/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 502 ppp virtual-template 1

R6

int virtual-template 1

ip address 100.100.100.6 255.255.255.0

bandwidth  64

int s0/1/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 602 ppp virtual-template 1

note:
- virtual access interface nos. issuing shut/no shut it will not assume always the same nos of virtual access interface.
- show ip route - will show /32 for virtual access. so might create problem on some dynamic routing.


==============================================
100.100.110.0/24


R2

int virtual-template2

ip address 100.100.110.2 255.255.255.0 

bandwidth  64

int s0/1/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 215 ppp virtual-template 2

frame-relay interface-dlci 216 ppp virtual-template 2

R5

int virtual-template 2

ip address 100.100.110.5 255.255.255.0

bandwidth  64

int s0/1/0

ip address 100.100.100.5 255.255.255.0

frame-relay interface-dlci 512 ppp virtual-template 2

R6

int virtual-template2

ip address 100.100.110.6 255.255.255.0

int s0/1/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 612 ppp virtual-template 2

verification
show int virtual access 2 - information inherited shows 100M link from virtual template
need to update the BW at virtual template

==============================================
100.100.120.0/24 128K 2 pvcs are active using 64k
note: there will be no load sharing / you can use multilink.

R2

int virtual-template 3

ip address 100.100.120.2 255.255.255.0 

bandwidth  64  

ppp multilink

int s0/1/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 224 ppp virtual-template 3

frame-relay interface-dlci 214 ppp virtual-template 3

R4

int virtual-template 3

ip address 100.100.120.4 255.255.255.0 

bandwidth  64  

ppp multilink

int s0/0/0

encapsulation frame-relay

no frame-relay inverse-arp

frame-relay interface-dlci 412 ppp virtual-template 3

frame-relay interface-dlci 422 ppp virtual-template 3

verification:

show ip route - there will one single set of /32 virutal access #
show int virtual-access # - will show only inherited 64k from virtual-template
show ppp multilink  - will show 2 member w total of 128K (definitive answer)

LAB: Frame Relay Back to Back with multilink

no rules on the to use frame-relay interface type.

R6 - providing the clockrate

int s0/2/0

encap frame mfr1

clockrate 128000

no shut
bandwidth 128

!

int s0/2/1

encap frame mfr1

clockrate 128000

no shut
bandwidth 128

!

int mfr 1

no keepalive

!

int mfr1.1 point-to-point

ip address 200.200.200.6 255.255.255.0

frame-relay interface-dlci 691

!

int mfr1.2 point-to-point

ip address 200.200.210.6 255.255.255.0

frame-relay interface-dlci 691

!

int mfr1.3 point-to-point

ip address 200.200.220.6 255.255.255.0

frame-relay interface-dlci 691

R9

int s0/2/0

encap frame mfr1

no shut
bandwidth 128

!

int s0/2/1

encap frame mfr1

no shut
bandwidth 128

!

int mfr 1

no keepalive

!

int mfr1.1 point-to-point

ip address 200.200.200.9 255.255.255.0

frame-relay interface-dlci 691

!

int mfr1.2 point-to-point

ip address 200.200.210.9 255.255.255.0

frame-relay interface-dlci 691

!

int mfr1.3 point-to-point

ip address 200.200.220.9 255.255.255.0

frame-relay interface-dlci 691

LAB: Frame Relay Multilink FRF.16

Requirements:  use multilink at R2
ISP FR - links at R2 can serve via s0/1/0 and s0/0/0 at spokes it is transparent.

from the previos labs the interface configs here are moved to MFR logical interfaces.
R2:

int s0/0/0

encapsulation frame mfr 1

no shut

int s0/1/0

encapsulation frame mfr 1

no shut

int mfr1

encapsulation frame-relay

no frame-relay inverse-arp

ip address 100.100.100.2 255.255.255.0

frame-relay map ip 100.100.100.4 204 broadcast

frame-relay map ip 100.100.100.5 205 broadcast

frame-relay map ip 100.100.100.6 206 broadcast

frame-relay map ip 100.100.100.2 204 broadcast -ping to its own int

!

int mfr1.110 multipoint

ip address 100.100.110.2 255.255.255.0

frame-relay map ip 100.100.110.5 215 broadcast

frame-relay map ip 100.100.110.6 216 broadcast

frame-relay map ip 100.100.110.2 215 broadcast -ping to its own int

!

int mfr2.120 point-to-point

ip address 100.100.120.2 255.255.255.0

frame-relay interface-dlci 214

verification

show frame multilink

show int mfr 1 - BW are automatically computed.

show frame map

debug ip packet

LAB: Frame Relay Back to Back

Requirements: 1 multipoint & total of 2 subinterfaces

R7

int s0/0/0

encapsulation frame

ip address 200.200.200.7 255.255.255.0

clockrate 128000

no shut

R8

int s0/0/0

encapsulation frame

ip address 200.200.200.8 255.255.255.0

no shut

note: on older version of software the interface is up/down, new version is up/up its already configured clockrate. i.e. not using the default clockratre 2000000

sho int s0/0/0

both sides up/down
looped at R7

show frame lmi

 important points: frame relay DTE on R7 eventhough we have a clockrate but DTE layer2 FR.
frame-relay DTE means it expects a frame relay DCE that provides clock but in this setup we are using FR back to back. 

1.  We need to turn off LMI by turning keep alives.
2.  After this still encapsulation failed. because there is no L2 to L3 resolution. frame map is needed.
3.  DLCI are locally significant, since R7 and R8 are directly connected, same DLCI must be used on both sides.


R7

int s0/0/0

encapsulation frame

ip address 200.200.200.7 255.255.255.0

clockrate 128000

no shut

no keepalive

frame-relay map ip 200.200.200.8 101 broadcast

frame-relay map ip 200.200.200.7 101

R8

int s0/0/0

encapsulation frame

ip address 200.200.200.8 255.255.255.0

no shut 

no keepalive

frame-relay map ip 200.200.200.7 101 broadcast

frame-relay map ip 200.200.200.8 101

================================================
200.200.210.0/24  multipoint



R7

int s0/0/0.210 multipoint

ip address 200.200.210.7 255.255.255.0

frame-relay map ip 200.200.210.8 111 broadcast

frame-relay map ip 200.200.210.7 111

R8

int s0/0/0 multipoint

ip address 200.200.210.8 255.255.255.0

frame-relay map ip 200.200.210.7 111 broadcast

frame-relay map ip 200.200.210.8 111

================================================
200.200.220.0/24 one point to point


R7

int s0/0/0.220 point-to-point

ip address 200.200.220.7 255.255.255.0

frame-relay interface-dlci 121

R8

int s0/0/0.220 point-to-point

ip address 200.200.220.8 255.255.255.0  

frame-relay interface-dlci 121

LAB: Frame Relay Interface type

Requirements:  Any router is only allowed to have 1 multipoint sub-interface

100.100.100.0/24 segment

R2:

int s0/1/0

ip address 100.100.100.2 255.255.255.0

frame-relay map ip 100.100.100.4 204 broadcast

frame-relay map ip 100.100.100.5 205 broadcast

frame-relay map ip 100.100.100.6 206 broadcast

frame-relay map ip 100.100.100.2 204 broadcast -ping to its own int

R4:

int s0/0/0

ip address 100.100.100.4 255.255.255.0

frame-relay map ip 100.100.100.2 402 broadcast

frame-relay map ip 100.100.100.5 402

frame-relay map ip 100.100.100.6 402

frame-relay map ip 100.100.100.4 402

R5:

int s0/1/0

ip address 100.100.100.5 255.255.255.0

frame-relay map ip 100.100.100.2 502 broadcast

frame-relay map ip 100.100.100.4 502

frame-relay map ip 100.100.100.6 502

frame-relay map ip 100.100.100.5 502

R6:

int s0/1/0

ip address 100.100.100.6 255.255.255.0

frame-relay map ip 100.100.100.2 602 broadcast

frame-relay map ip 100.100.100.4 602

frame-relay map ip 100.100.100.5 602

frame-relay map ip 100.100.100.6 602

================================================

100.100.110.0/24 segment  r2, r5 and r6 using subinterface everything should be map.

R2:

int s0/1/0.110 multipoint

ip address 100.100.110.2 255.255.255.0

frame-relay map ip 100.100.110.5 215 broadcast

frame-relay map ip 100.100.110.6 216 broadcast

frame-relay map ip 100.100.110.2 215 broadcast -ping to its own int

R5:

int s0/1/0.110 multipoint

ip address 100.100.110.5 255.255.255.0

frame-relay map ip 100.100.110.4 512 broadcast

frame-relay map ip 100.100.110.6 512

frame-relay map ip 100.100.110.5 512

R6:

int s0/1/0.110 multipoint

ip address 100.100.110.6 255.255.255.0

frame-relay map ip 100.100.110.2 612 broadcast

frame-relay map ip 100.100.110.5 612

frame-relay map ip 100.100.110.6 612

================================================

100.100.120.0/24 segment  r2, r4 ( each router nly have one multipoint)

R2:

int s0/1/0.120 point-to-point

ip address 100.100.120.2 255.255.255.0

frame-relay interface-dlci 214

R4:

int s0/0/0.120 multipoint

ip address 100.100.120.4 255.255.255.0

frame-relay map ip 100.100.120.2 412 broadcast

frame-relay map ip 100.100.120.4 412

note:  Not really a problem of using both physical interface and sub interface.

LAB: Frame Relay Address Resolution using inverse-arp

DLCIs

R2=205,206,215,216,225,226

R5=502,506,512,516,522,526

R6=602,605,612,615,622,625

LAB Requirements:  no DLCI indicated in the diagram: donot use PVC with 0 & 1 in the middle

R2,R5,R6

int s0/1/0

encapsulation frame-relay

 no shut

 ip address a.b.c.d

verify the DLCI

show frame-relay pvc | in ACT

show frame-relay pvc | in \ ACT
show frame-relay map

R2
no frame-relay inverse-arp ip 205

no frame-relay inverse-arp ip 206

no frame-relay inverse-arp ip 215

no frame-relay inverse-arp ip 216

R5

no frame-relay inverse-arp ip 502

no frame-relay inverse-arp ip 506

no frame-relay inverse-arp ip 512

no frame-relay inverse-arp ip 516


R6
no frame-relay inverse-arp ip 602

no frame-relay inverse-arp ip 605

no frame-relay inverse-arp ip 612

no frame-relay inverse-arp ip 615




note: you can issue the command below to clear some dynamic arps
clear frame-relay inarp

from R5 to reach R6 must add static mapping

frame-relay map ip 100.100.100.6 522

from R6 to reach R5

frame-relay map ip 100.100.100.5 622

frame-relay map ip 100.100.100.6 622  ===if u wan to ping urself

useful tool: to ensure that l2 to l3 mapping is ok, or if there is encapsulation failed
debug ip packet

extra: adding dynamic routing

R2, R5, R6

router ospf 1

passive interface default

network 0.0.0.0 0.0.0.0 area 0

no passive s0/1/0

!

int s0/1/0

ip ospf network broadcast