Pic. 1 - Topology Diagram.
Task 1
Remove current Frame-Relay configuration on R1, R3, and R4.
Task 2
Enable basic Frame-Relay configuration using R1 as the hub and R3, R4 as the spokes. Use only DLCI presented in the topology diagram (pic. 1). Ensure that there are no additional mappings of IP-to-DLCI.
Task 3
Enable OSPF area 0 on serial interfaces of R1, R3, and R4. Use network statement with the wildcard mask matching the network mask configured on the interfaces. Ensure full connectivity between all OSPF enabled networks.
Questions
Task 2
Enable basic Frame-Relay configuration using R1 as the hub and R3, R4 as the spokes. Use only DLCI presented in the topology diagram (pic. 1). Ensure that there are no additional mappings of IP-to-DLCI.
Task 3
Enable OSPF area 0 on serial interfaces of R1, R3, and R4. Use network statement with the wildcard mask matching the network mask configured on the interfaces. Ensure full connectivity between all OSPF enabled networks.
Questions
- What is the default OSPF mode when enabled on NBMA (Frame-Relay, ATM, X.25) links?
- What are the 'hello' and 'dead' intervals used by default?
- Can Frame-Relay forward broadcast/multicast packets by default?
- Does NBMA network elect DR/BDR? If so, which device should be DR in hub-and-spoke topology?
- If DR is elected, which devices should be selected as BDR?
- How spoke-to-spoke connectivity is realized in NBMA networks?
Lab Solution
Solution configuration below:
https://docs.google.com/file/d/0BwE5C95tpjZOUXhHMC1xV0t4QTA/edit?usp=sharing
Task 1
Remove current Frame-Relay configuration on R1, R3, and R4.
R1 Config:
!
interface serial0/0
no encapsulation frame-relay
!
R1 Config:
!
interface serial0/0
no encapsulation frame-relay
!
R3 Config:
!
interface serial0/0
no encapsulation frame-relay
!
R4 Config:
!
interface serial0/0
no encapsulation frame-relay
!
What You Should See
Pic. 3.
Pic. 4.
Task 2
Enable basic Frame-Relay configuration using R1 as the hub and R3, and R4 as the spokes. Use only DLCI presented in the topology diagram (pic. 1). Ensure that there are no additional mappings of IP-to-DLCI.
R1 Config:
!
interface serial0/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay map ip 172.16.0.3 103
frame-relay map ip 172.16.0.4 104
!
R3 Config:
!
interface serial0/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay map ip 172.16.0.1 301
!
R4 Config:
What You Should See
Study Drill
Try R1, R3 or R4 try to ping the address of the local interface. Do you think it is going to succeed?
It fails. Why?
Try to 'debug frame-relay packet' while pinging the local IP address.
!
interface serial0/0
frame-relay map ip 172.16.0.3 301
!
and R4:
!
interface serial0/0
frame-relay map ip 172.16.0.4 401
!
From the on, the routers can resolve their own IP address (serial0/0) to the active DLCI and pinging the local address will succeed. Carry on with the task 3.
Task 3
Enable OSPF area 0 on serial interfaces of R1, R3, and R4. Use network statement with the wildcard mask matching the network mask configured on the interfaces. Ensure full connectivity between all OSPF enabled networks.
R1 Config:
!
router ospf 1
network 172.16.0.0 0.0.0.255 area 0
neighbor 172.16.0.3
neighbor 172.16.0.4
!
Study Drill
Pay attention to the following facts in Pic.9:
Notice!
There is one problem we need to fix before we consider our configuration correct!
Check the following:
R4 has two paths towards 172.16.13.0. However, ping does not seem to work correctly.
I hope you have noticed that R4 has connectivity to the next-hop-address 172.16.0.1, but currently, it does not have connectivity to 172.16.0.3 (no IP-to-DLCI mapping). Similarly, R3 does not know how to send the packets back towards 172.16.0.4 (no IP-to-DLCI mapping). In the above output, 172.16.0.3 also becomes the next hop address towards 172.16.13.0/24. This, and the fact that our source IP address while pinging is the 172.16.0.4 (inaccessible at the layer 2 on R3) cause presented connectivity issues.
In order to fix it, let's create spoke-to-spoke Frame-Relay mappings:
R3 Config:
!
interface serial0/0
frame-relay map ip 172.16.0.4 301
!
R4 Config:
!
interface serial0/0
frame-relay map ip 172.16.0.3 401
!
This time, we have ensured full connectivity as per Task 3 requirement.
One last thought. Why did I use the 'neighbor' statements on R1. And why did I not use them on R3 and R4?
NBMA networks do not support broadcast/multicast transmissions (there are no DLCIs for 224.0.0.5/224.0.0.6). The neighbor statement on R1 allows it to send 'hello' packet using unicast. The reason R3 and R4 do not need it, is because they always respond to the hello using the same transmission type (multicast or unicast). DR, using the 'neighbor' statement sent hello packet using unicast, R3 and R4 also respond using unicast. This way, DR is the only device that requires the 'neighbor' statement.
Enable basic Frame-Relay configuration using R1 as the hub and R3, and R4 as the spokes. Use only DLCI presented in the topology diagram (pic. 1). Ensure that there are no additional mappings of IP-to-DLCI.
R1 Config:
!
interface serial0/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay map ip 172.16.0.3 103
frame-relay map ip 172.16.0.4 104
!
R3 Config:
!
interface serial0/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay map ip 172.16.0.1 301
!
R4 Config:
!
interface serial0/0
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay map ip 172.16.0.1 401
!
Notice!
There is something missing the the configuration of R3 and R4 as far as the Frame-Relay is concerned. I did it on purpose here, just to show you certain behavior later (look at Lab Solution->Task 3->Study Drill for more information).
Pic. 5.
Study Drill
Try R1, R3 or R4 try to ping the address of the local interface. Do you think it is going to succeed?
Pic. 6.
Try to 'debug frame-relay packet' while pinging the local IP address.
Pic. 7.
The debug shows that layer 3 IP address (172.16.0.1) can't be encapsulated int the layer 2 Frame-Relay frame due to the lack of DLCI for this address. Check the IP-to-DLCI mapping:
NOTICE!
If your mapping shows other IP-to-DLCI output, you must shut down the interface to get rid of old mappings (in case of using a real router, sometimes the reload is necessary).
NOTICE!
If your mapping shows other IP-to-DLCI output, you must shut down the interface to get rid of old mappings (in case of using a real router, sometimes the reload is necessary).
Pic. 8.
On R1 there are two, static layer 3 to layer 2 mappings according to our manual configuration:
172.16.0.3 is mapped to DLCI=103,
172.16.0.4 is mapped to DLCI=104.
There is no mapping for 172.16.0.1. If you want to practice this, you can add the following line on R1:
!
interface serial0/0
frame-relay map ip 172.16.0.1 103
!
This will create layer 3 to layer 2 mapping (DLCI could also be 104) and the ping will succeed. Similar configuration could be added to R3:
interface serial0/0
frame-relay map ip 172.16.0.3 301
!
!
interface serial0/0
frame-relay map ip 172.16.0.4 401
!
From the on, the routers can resolve their own IP address (serial0/0) to the active DLCI and pinging the local address will succeed. Carry on with the task 3.
Task 3
Enable OSPF area 0 on serial interfaces of R1, R3, and R4. Use network statement with the wildcard mask matching the network mask configured on the interfaces. Ensure full connectivity between all OSPF enabled networks.
R1 Config:
!
router ospf 1
network 172.16.0.0 0.0.0.255 area 0
neighbor 172.16.0.3
neighbor 172.16.0.4
!
R3 Config:
!
interface serial0/0
ip ospf priority 0
interface serial0/0
ip ospf priority 0
!
router ospf 1
network 172.16.0.0 0.0.0.255 area 0
!
R4 Config:
!
interface serial0/0
ip ospf priority 0
!
router ospf 1
network 172.16.0.0 0.0.0.255 area 0
network 172.16.0.0 0.0.0.255 area 0
!
R4 Config:
!
interface serial0/0
ip ospf priority 0
!
router ospf 1
network 172.16.0.0 0.0.0.255 area 0
!
What You Should See
Wait a few minutes (hello are sent every 30 seconds on these interfaces) and check if your output matches the ones below:
Pic. 9.
Pic. 10.
Study Drill
Pay attention to the following facts in Pic.9:
- Network Type: NON_BROADCAST (default, RFC standard).
- R3 state: DROTHER (result of 'ip ospf priority 0' command).
- Timer intervals configured: Hello 30, Dead 120.
Also, look at the state of R1's OSPF neighbors (pic. 10) on Serial0/0 link (both R3 and R4 are DROTHERS).
On NBMA networks DR/BDR are elected. However, in hub-and-spoke topology, the only authorized source of updates (DR) should be the router with full connectivity to all spokes (in our design that would be R1). The reason we configured R3 and R4 as DROTHERS ('ospf priority 0', on serial0/0 interfaces) is that in case of losing R1, re-election occurs in whereby BDR becomes the new DR. We can't allow it since the DR role is non-preemptive. which means that upon coming back on line R1 would not become DR again. Since neither R3 and R4 do NOT have layer 2 connectivity to all other routers, they must never become DR or BDR.
Also, from the troubleshooting perspective it is good to remember that the following must match between OSPF routers in order for them to form proper adjacency:
- Hello and Dead Intervals
- Area Type flags
- Area ID
- Authentication type and passwords
- MTU (in order to exchange LSAs)
There is one problem we need to fix before we consider our configuration correct!
Check the following:
Pic. 11.
I hope you have noticed that R4 has connectivity to the next-hop-address 172.16.0.1, but currently, it does not have connectivity to 172.16.0.3 (no IP-to-DLCI mapping). Similarly, R3 does not know how to send the packets back towards 172.16.0.4 (no IP-to-DLCI mapping). In the above output, 172.16.0.3 also becomes the next hop address towards 172.16.13.0/24. This, and the fact that our source IP address while pinging is the 172.16.0.4 (inaccessible at the layer 2 on R3) cause presented connectivity issues.
In order to fix it, let's create spoke-to-spoke Frame-Relay mappings:
R3 Config:
!
interface serial0/0
frame-relay map ip 172.16.0.4 301
!
R4 Config:
!
interface serial0/0
frame-relay map ip 172.16.0.3 401
!
Pic. 12.
One last thought. Why did I use the 'neighbor' statements on R1. And why did I not use them on R3 and R4?
NBMA networks do not support broadcast/multicast transmissions (there are no DLCIs for 224.0.0.5/224.0.0.6). The neighbor statement on R1 allows it to send 'hello' packet using unicast. The reason R3 and R4 do not need it, is because they always respond to the hello using the same transmission type (multicast or unicast). DR, using the 'neighbor' statement sent hello packet using unicast, R3 and R4 also respond using unicast. This way, DR is the only device that requires the 'neighbor' statement.
