Pic. 1 - Topology Diagram.
Task 1
Reconfigure R3 and R4 Frame-Relay connection in such a way that there is NO spoke-to-spoke IP-to-DLCI mapping. On the spoke routers (R3, and R4) configure IP-to-DLCI mapping towards R1 (hub routers) and its own IP address.
Task 2
You need to reconfigure OSPF on Frame-Relay connection between R1, R3 and R4. Ensure that the OSPF routing table on R3 and R4 shows R1 (172.16.0.1) as the next hop to networks learned from the other spoke over Frame-Relay connection. Ensure that multicast (224.0.0.5) is supported and there is no DR/BDR election there.
Questions
Task 2
You need to reconfigure OSPF on Frame-Relay connection between R1, R3 and R4. Ensure that the OSPF routing table on R3 and R4 shows R1 (172.16.0.1) as the next hop to networks learned from the other spoke over Frame-Relay connection. Ensure that multicast (224.0.0.5) is supported and there is no DR/BDR election there.
Questions
- What is the mode of OSPF best to support the stipulations in Task 2?
- What needs to be done in terms of Frame-Relay configuration to support it?
- What are the principles of operation regarding the solution provided (DR/BDR election, timers, multicast support)?
Lab Solution
Solution configuration below:
https://docs.google.com/file/d/0BwE5C95tpjZOam11R2xrX1FLdkk/edit?usp=sharing
Task 1
Reconfigure R3 and R4 Frame-Relay connection in such a way that there is NO spoke-to-spoke IP-to-DLCI mapping. On the spoke routers (R3, and R4) configure IP-to-DLCI mapping towards R1 (hub routers) and its own IP address.R1 Config:
!
interface serial0/0
frame-relay map ip 172.16.0.4 104 broadcast
frame-relay map ip 172.16.0.3 103 broadcast
!
R3 Config:
!
interface Serial0/0
no ip ospf priority 0
no frame-relay map ip 172.16.0.4 301
frame-relay map ip 172.16.0.1 301 broadcast
!
R4 Config:
!
interface Serial0/0
no ip ospf priority 0
no frame-relay map ip 172.16.0.3 401
frame-relay map ip 172.16.0.1 401 broadcast
!
What You Should See
Pic. 2.
Pic. 3.
Pic.4.
Study Drill
Why did I use 'broadcast' keyword even though task 1 did not imply using it?
The reason is that task 2 will need the support of pseudo-broadcast/multicast (224.0.0.5 must be supported).
Why did I remove OSPF priority 0 from R3 and R4?
OSPF mode used in task 2 (Point-to-Multipoint) does NOT elect DR/BDR since it treats the connections like point-to-point. This configuration is not required anymore.
Task 2
You need to reconfigure OSPF on Frame-Relay connection between R1, R3 and R4. Ensure that the OSPF routing table on R3 and R4 shows R1 (172.16.0.1) as the next hop to networks learned from the other spoke over Frame-Relay connection. Ensure that multicast (224.0.0.5) is supported and there is no DR/BDR election there.
Since all serial0/0 interfaces in question have already been OSPF-enabled (ip ospf 1 area), all that is required is to remove 'neighbor' statement on R1 (unicast is no longer required in OSPF point-to-multipoint mode. Second thing to configure is to enable appropriate ospf mode.
R1 Config:
!
router ospf 1
no neighbor 172.16.0.3
no neighbor 172.16.0.4
!
interface serial0/0
ip ospf network point-to-multipoint
!
R3 Config:
!
interface serial0/0
ip ospf network point-to-multipoint
!
R4 Config:
!
interface serial0/0
ip ospf network point-to-multipoint
!
What You Should See
Neighbor relationship between R1 and its spokes (R3, R4) shows state: FULL. Notice, there is no DR/BDR information (-) since this mode does not elect DR/BDR. Similar relationship should be present on the spokes with R1.
R1, R2, and R3 should show State POINT_TO_MULTIPOINT on their serial0/0 interfaces. Pay attention to the Hello and Dead timers (30/120) respectively.
Study Drill
OSPF Point-to-Multipoint (RFC-based, not Cisco proprietary) treats the neighbors just like point-to-point connection (except for timers since p2p uses 10/40). Much like point-to-point, OSPF expects multicast support (Frame-Relay pseudo 'broadcast' while configuring IP-to-DLCI mapping). Also, consider that 224.0.0.5 (in fact the whole range 224.0.0.1-224.0.0.255) is link-local multicast. This means that spoke-to-spoke 'hello' would never get across R1 since the packet uses TTL=1. The communication between spokes will need to cross R1, which gives its own IP address (here: 172.16.0.1) as the next hop while advertising prefixes advertised from one spoke towards another spoke.
Take a look at the routing table on R4. Notice the next-hop-address towards 172.16.13.0/24 and 10.0.3.3):
The communication between R3 and R4 prefixes will work across R1 even though there is no IP-to-DLCI spoke-to-spoke mappings because the next hop is always hub router now.
!
interface serial0/0
ip ospf network point-to-multipoint
!
What You Should See
Pic. 5.
Pic. 6.
R1, R2, and R3 should show State POINT_TO_MULTIPOINT on their serial0/0 interfaces. Pay attention to the Hello and Dead timers (30/120) respectively.
Study Drill
OSPF Point-to-Multipoint (RFC-based, not Cisco proprietary) treats the neighbors just like point-to-point connection (except for timers since p2p uses 10/40). Much like point-to-point, OSPF expects multicast support (Frame-Relay pseudo 'broadcast' while configuring IP-to-DLCI mapping). Also, consider that 224.0.0.5 (in fact the whole range 224.0.0.1-224.0.0.255) is link-local multicast. This means that spoke-to-spoke 'hello' would never get across R1 since the packet uses TTL=1. The communication between spokes will need to cross R1, which gives its own IP address (here: 172.16.0.1) as the next hop while advertising prefixes advertised from one spoke towards another spoke.
Take a look at the routing table on R4. Notice the next-hop-address towards 172.16.13.0/24 and 10.0.3.3):
Pic. 7.
The communication between R3 and R4 prefixes will work across R1 even though there is no IP-to-DLCI spoke-to-spoke mappings because the next hop is always hub router now.