Sunday, July 28, 2013

OSPF Null Authentication


Pic. 1 - Topology Diagram.


Task 1
Remove OSPF MD5 authentication between R1 and R2 (look at configuration in previous lab). Do not change anything else on R1. Ensure R1 and R2 stay OSPF neighbors.


Questions
Try to answer the following questions:
  1. What is OSPF Null authentication?
Study Drill

Consider the configuration on R1:

Pic. 2.

The task stipulates that we can remove OSPF configuration from R1's FastEthernet, but we CAN'T change anything in OSPF routing context (we can't remove 'area 0 authentication).

Since FastEtherent0/0 on R1 is enabled in OSPF area 0, the only option we have is to apply OSPF null authentication.

Lab Solution
Task 1
Remove OSPF MD5 authentication between R1 and R2 (look at configuration in previous lab). Do not change anything else on R1. Ensure R1 and R2 stay OSPF neighbors.


R1 Config:
!
interface FastEthernet0/0
 no ip ospf message-digest-key 1 md5 G33K
 no ip ospf message-digest-key 2 md5 CISCO123
 ip ospf authentication null

!

R2 Config:
!
interface FastEthernet0/0
 no  ip ospf authentication message-digest
 no  ip ospf message-digest-key 1 md5 G33K

!

Pic. 3.



Study Drill

Recall the order of operations in terms of OSPF: interface-based authentication overrides the routing context one. Also, if authentication is enabled in the OSPF routing context for a specific area, ALL interfaces in this authenticated area will send their 'hello' packets with the authentication method/data by default. 

In the later labs we will use OSPF Virtual Link configuration. Which area will a VL belong to? How area authentication will affect VL?

OSPF Password Rollover


Pic. 1 - Topology Diagram.


Task 1
R1 is configured to run Simple Password Authentication with R3 and R4 in the routing context like presented in pic. 2:

Pic. 2.

Configure new password between R1 and R2 on their Fa0/0 link. Use the 'CISCO123' as the password and ensure that R1 and R2 do not lose FULL state.

Questions
Try to answer the following questions:
  1. What is OSPF password rollover?

Task1
R1 is configured to run Simple Password Authentication with R3 and R4 in the routing context like presented in pic. 2. Configure new password between R1 and R2 on their Fa0/0 link. Use the 'CISCO123' as the password and ensure that R1 and R2 do not lose FULL state.

R1 Config:
!
interface FastEthernet0/0
 ip ospf message-digest-key 2 md5 CISCO123
!


Notice!
Once you add another password (key_id 2, here), R1 still uses the first key, since R2 uses the first one too (G33K). During that process here's the output of R1's OSPF enabled interface (check out the last four lines):


Pic. 3.


R2 Config:
!
interface FastEthernet0/0
ip ospf message-digest-key 2 md5 CISCO123
!


After adding the new key/password pair on both routers, here's the OSPF interface output:


Pic. 4.

Study Drill

If you add an extra key+password pair, while leaving the old one still configured, OSPF neighbor relationship stays intact. Try to remove the key and then add the new key on both R1 and R2. Make sure you do not do this too fast (you should give it at least 40 seconds - dead time to see what happens).

Friday, July 26, 2013

OSPF MD5 Authentication


Pic. 1 - Topology Diagram.


Task 1
Reconfigure OSPF authentication between R1 and R2. Use the password 'G33K' and the most secure option to accomplish this. Do not change Simple Password authentication configured on the remaining routers (configured in the previous lab).

Questions
Try to answer the following questions:
  1. When MD5 authentication is enabled, what should match between routers in order to establish FULL adjacency?
  2. What is the order of operations if OSPF authentication method is configured in the routing context and on an interface?
Lab Solution

Solution configuration below:

Task 1
Reconfigure OSPF authentication between R1 and R2. Use the password 'G33K' and the most secure option to accomplish this. Do not change Simple Password authentication configured on the remaining routers (configured in the previous lab).
R1 Config:
!
interface FastEthernet0/0
 no ip ospf authentication-key 
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 G33K
!
R2 Config:
!
interface FastEthernet0/0
 no ip ospf authentication
 no ip ospf authentication-key
 ip ospf message-digest-key 1 md
 ip ospf message-digest-key 1 md5 G33K
!

What You Should See


Pic. 2.


Notice, that R1 shows as FULL state OSPF neighbor and R2's routing table has been populated again. Also, take a look at pic. 3. The last two line show that key 1 and MD5 method has been used.


Pic. 3.

Study Drill

In OSPF MD5 authentication method, you can change passwords by adding an extra key with the new password. If you do so, there is no interruption in the service (you will see it in the next lab). 

While using OSPF MD5 authentication, both 'key number' and the 'password' between routers must be identical in order to establish FULL state between neighbors.

Experiment by changing the 'key number' on R2 (and leaving key=1 on R1). Use 'debug ip ospf adj' to see the result of that change. Then, configure the key=1 on R2 back again, but change the password instead. Observe the output of the debug. Find the differences between the two dubug output.

Thursday, July 25, 2013

OSPF Simple Password Authentication


Pic. 1 - Topology Diagram.


Task 1
Enable OSPF area 0 between R1 and R2 on their FastEthernet interfaces (refer to pic.1).

Task 2
Enable OSPF Simple Password authentication in area 0. Configure R1 to use this authentication methods in the 'router ospf' context. R2, R3, and R4 should have their authentication enabled on their respective interfaces. Use the password 'G33K' on all routers.


Questions
Try to answer the following questions:
  1. What is the purpose of authenticating routing packets?
  2. What are the OSPF authentication methods?
  3. What are the differences between them?
  4. What are the methods of implementing OSPF authentication?
Lab Solution

Solution configuration below:
https://docs.google.com/file/d/0BwE5C95tpjZOZWZIX1NjLXlRcDQ/edit?usp=sharing


Task 1
Enable OSPF area 0 between R1 and R2 on their FastEthernet interfaces (refer to pic.1).

R1 Config:
!
interface FastEthernet0/0
 ip ospf 1 area 0
!

R2 Config:
!
interface FastEthernet0/0
 ip ospf 1 area 0
!

What You Should See


Pic. 2.

Pic. 3.

Task 2
Enable OSPF Simple Password authentication in area 0. Configure R1 to use this authentication methods in the 'router ospf' context. R2, R3, and R4 should have their authentication enabled on their respective interfaces. Use the password 'G33K' on all routers.


R1 Config:
!
router ospf 1
 area 0 authentication
!
interface FastEthernet0/0
 ip ospf authentication-key G33K
!
interface Serial0/0
 ip ospf authentication-key G33K
!

R2 Config:
!
interface FastEthernet0/0
 ip ospf authentication
 ip ospf authentication-key G33K
!

R3 Config:
!
interface Serial0/0
 ip ospf authentication
 ip ospf authentication-key G33K
!

R4 Config:
interface Serial0/0
 ip ospf authentication
 ip ospf authentication-key G33K
!

What You Should See


Pic. 4.
Notice!
All R1's neighbors are back.


Pic. 5.


Notice!
The last line of Se0/0 says: Simple password authentication enabled.
All other routers show the same on their respective interfaces.

Study Drill

OSPF (like any other routing protocol) uses authentication to prevent rogue routers from joining the routing domain. OSPF has two major methods of authenticating its packets:
  1. Simple Password (clear text).
  2. MD5
Simple password method is very insecure since the password is sent in a clear text format. MD5 uses hashing algorithm and allows easy password changes without any interruption (presented in later lab).
Both authentication methods can be enabled in router context or on an interface.

Tuesday, July 23, 2013

OSPF Point-to-Multipoint Non-Broadcast


Pic. 1 - Topology Diagram.

Task 1
On R1, R3, and R4 disable pseudo-broadcast on Frame-Relay interfaces.

Task 2
Reconfigure OSPF on R1, R3, and R4 to use OSPF point-to-multipoint non-broadcast mode. Ensure OSPF domain has full connectivity.

Questions
Try to answer the following questions:
  1. What happened when you have removed 'broadcast' keyword in Task 1 as far as OSPF communication?
  2. What is/are the difference(s) between OSPF point-to-multipoint and point-to-multipoint non-broadcast?
  3. Is the mode used in this lab Cisco proprietary or RFC standard?

Lab Solution

Solution configuration below:
https://docs.google.com/file/d/0BwE5C95tpjZOMnhPdmFuMUJ2b3c/edit?usp=sharing


Task 1
On R1, R3, and R4 disable pseudo-broadcast on Frame-Relay interfaces.

R1 Config:
!
interface Serial0/0
 frame-relay map ip 172.16.0.3 103
 frame-relay map ip 172.16.0.4 104

!

R3 Config:
!
interface Serial0/0
  frame-relay map ip 172.16.0.1 301
!

R4 Config:
!
interface Serial0/0
 frame-relay map ip 172.16.0.1 401
!

What You Should See


Pic. 2.

R1 has lots R3 and R4 as its OSPF neighbors. The reason is that multicast 224.0.0.5 (hello) is no longer supported (no DLCI for multicast/broadcast). The 'debug ip packet detail' should reveal the cause of the problem:


Pic. 3.

Task 2
Reconfigure OSPF on R1, R3, and R4 to use OSPF point-to-multipoint non-broadcast mode. Ensure OSPF domain has full connectivity.

R1 Config:
!
interface Serial0/0
 ip ospf network point-to-multipoint non-broadcast
!
router ospf 1
 neighbor 172.16.0.4
 neighbor 172.16.0.3

!

R3 Config:
!
interface Serial0/0
ip ospf network point-to-multipoint non-broadcast
!

R4 Config:
!
interface Serial0/0
 ip ospf network point-to-multipoint non-broadcast
!


What You Should See


Pic. 4.


Study Drill

If you cannot use pseudo-broadcast (for instance, this is an exam stipulation)on NBMA links (or there is no support for), you can use OSPF point-to-multipoint non-broadcast mode. This will behave just like OSPF point-to-multipoint (treats connections as point-to point, no DR/BDR election).

This mode of OSPF is Cisco proprietary. The timers are 30/120 seconds (hello, dead). Since this mode does not assume pseudo broadcast/multicast support, it requires the 'neighbor' statement in the configuration on R1 (the hub router). The spoke routers will respond using unicast upon receiving unicast hello. As for the next-hop address, this option also behaves like OSPF point-to-multipoint mode.


Friday, July 19, 2013

OSPF Point-to-Multipoint Mode


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
Try to answer the following questions:
  1. What is the mode of OSPF best to support the stipulations in Task 2?
  2. What needs to be done in terms of Frame-Relay configuration to support it?
  3. What are the principles of operation regarding the solution provided (DR/BDR election, timers, multicast support)?

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


Pic. 5.

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.


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.

Wednesday, July 17, 2013

OSPF DR Configuration


Pic. 1 - Topology Diagram.

Task 1
Configure R3 to be the DR and R4 to be BDR in Vlan 100. Do not shut down any interface, reload any of the devices or clear OSPF process on any device to accomplish this.

Questions
Try to answer the following questions:
  1. What is the role of DR/BDR in the broadcast and NBMA networks?
  2. What are the pre-requisites to make a router eligible to become DR/BDR?
  3. What is the order of operations when it comes to DR/BDR election?
  4. In the previous lab we have configured R1 to be elected the DR in the Frame-Relay hub-ans-spoke network. We made sure that neither of the spokes became the BDR. Can you explain why?
Study Drill

Before we start the configuration, let's see what the current state of things regarding DR/BDR in Vlan 100 is. Do not worry if your output is different. Take a look at pic. 2.


Pic. 2.


Here's an interesting question for you: based on what Pic.2 represents, would you be able to tell which device is the DR and which is the BDR in Vlan 100 (FastEthernet0/0 interface)?

Stop reading now, and give it a shot! If you can't answer the questions, read on!

OSPF neighbor output on R6 (id=10.0.6.6) has three neighbors in Vlan 100:

  1. 10.0.3.3 (R3) is DROTHER.
  2. 10.0.4.4 (R4) is DROTHER.
  3. 10.0.7.7 (SW1) is BDR.
Most likely, R6 who's the neighbor of all of them is the DR in Vlan 100. In order to support this hypothesis, let's prove it it in two different ways:

Pic. 3.

Clearly, OSPF neighbor output on R3 confirms that R6 (10.0.6.6) is the DR. You can also check the status of OSFP interface on R6, like shown below:


Pic. 4.

The 5th line of the output says: State DR.

Now, recall that the purpose of DR/BDR roles in broadcast and NBMA network is to reduce the number of LSA exchanges. The exchanges must happen between all neighbors in FULL state. In the aforementioned networks, FULL adjacency is built only with DR/BDR, so DR becomes the only representative to send update on behalf of other routers. Both DR, and its sidekick, BDR must have layer 2 connectivity to all OSPF enabled routers in the same broadcast/NBMA network. If the routers are in the same Vlan this is not a problem. But consider Frame-Relay hub-and-spoke topology in which there is not layer 2 PVC provisioned between spokes. In such situation only the hub router can become DR (has layer 2 connectivity with all other routers) and spokes should never become BDR. We will take a closer look at this after we have solved the problem presented in the task 1.

As for the order of DR/BDR election, the routers follow the order of:

  1. Prefer the highest OSPF priority on the interfce (exchanged in 'hello' packets)
  2. In case of a tie (the same priority), prefer the highest OSPF router ID.

However, the thing to realize is that the DR role does not allow preemption. Once the router is elected DR it will stay as such even if we introduce a router with higher priority later (after the election has been completed). Only its failure or bringing its interface down will result in re-election. This means that election of DR/BDR may be unpredictible at times

Now, let's configure the solution.

Lab Solution

Solution configuration below:
https://docs.google.com/file/d/0BwE5C95tpjZOMVRXRUlXVG9IYVU/edit?usp=sharing

Task 1
Configure R3 to be the DR and R4 to be BDR in Vlan 100.  Do not shut down any interface, reload any of the devices or clear OSPF process on any device to accomplish this.

R3 Config:
!
interface fa0/0
 ip ospf priority 255
!

In my case, R6 is still DR (non preemptive role)


Pic. 5.

Now, in order to create re-election, as per the stipulation, I will make R6, R4 and SW1 temporarily ineligible of becoming DR/BDR by introducing OSPF priority 0 on their respective interfaces, and then after few seconds bringing the default priority of 1 on them.

R4 Config:
!
interface f0/1.100
 ip ospf priority 0
!

R6
!
interface f0/0
 ip ospf priority 0
!

SW1 Config:
!
interface vlan 100
 ip ospf priority 0
!

Now, let's put thing back to where they should be.

R4 Config:

interface fa0/1.100
 ip ospf priority 254
!

R6 Config:
!
interface f0/0
 ip ospf priority 1
!

SW1 Config:
!
interface vlan 100
 ip ospf priority 0
!

What You Should See
With this little acrobatics we should complete the task properly. Here's the result:


Pic. 6.


Study Drill
Let's tinker with Frame-Relay network and the problem of just having DR (R1) with no BDR. Let's leave the election of DR/BDR without interfering (all routers have default OSPF priority 1). Shut the interfaces down and bring them back up.

R1, R3, and R4 Config:
!
interface serial0/0
 ip ospf priority 1
!

After the interfaces have been brought up the DR is R4 (10.0.4.4) and BDR is R1 (10.0.1.1). In order to see this just give it a moment. 


Pic. 7.

Let's see how R3 learns 10.0.1.1/32. I have issued: show ip ospf database router 10.0.1.1 (which displays LSA type-1):

Pic. 8.

It is apparent that Stub Network 10.0.1.1/32 has been learned from R1 (Advertising Router: 10.0.1.1). It is easy to predict what is going to happen if I shut the interface serial0/1 on R3. It is going to remove 10.0.1.1/32 from its routing table since the next hop 172.16.13.1 (advertising router 10.0.1.1) is no longer available. 

Pic. 9.


It will still be available on R4 though.

Pic. 10.

Even though R3 could have reached 10.0.1.1 through R1, it does NOT know the second path exists. The reason is, that current DR on Frame-Relay link is R4. This one cannot send LSA about 10.0.1.1/32 towards R3 since it has no layer 2 connectivity withR3!

If you make R1 DR on the Frame-Relay link, R3 can reach 10.0.1.1 through its serial0/0 link). In the picture below, R1 is DR again, the R3's serial0/1 interface is still down (no OSPF neighbor there), but the connectivity to 10.0.1.1 is restored.

Pic. 11.

This little study drill clear proves that in a hub-and-spoke topology, the DR should be the hub router. In order to avoid the situation that the spoke becomes the BDR, they should always be DROTHERs.