OSPF Troubleshooting 1 Lab

This lab was taken from gns3vault.com. Click here to go to the lab page.

Goal

All IP addresses have been preconfigured for you as following:
192.168.XY.X /24 where X = router1 and Y = router2.
for example: 192.168.58.5 between router5 and router8.

  • Every router has 1 or 2 loopback interfaces as following:
    • Loopback0: x.x.x.x /24 for example: 1.1.1.1 for router1.
    • Loopback1: xx.xx.xx.xx /24 for example: 11.11.11.11 for router1.

OSPF is preconfigured with the areas as specified in the topology picture.

Do not use show run! use the appropiate 'show' and 'debug' commands.

  1. The network engineer responsible for the backbone area has some problems. R1 was replaced and the most recent config was unavailable so he used an older config. The OSPF adjancency between R1, R2 and R3 is not working now. You don't have access to R2 and R3.
  2. After fixing the problem on R1 you notice traffic from R1 towards R2 uses the fastethernet link. All traffic should be sent through the serial interface, when the frame-relay link fails it should switch to the fastethernet.
  3. Area 51 seems to have problems, you can't get any of the OSPF adjancencies up…make sure Area 51 has adjancencies between R1, R4 and R5.
  4. R4 is the most powerful router in Area 51, make sure it will become the DR.
  5. There used to be a link between R1 and R4 which failed…replacing the cable is impossible so you need to find another solution to fix the separated backbone.
  6. With Area 0 and 51 up and running everything should be ok. however when you look in the routing table of R1 you still don't see all of the networks. For example the 4.4.4.0 network is not available.
  7. RIP networks are configured to be redistributed into OSPF, however you don't see any of the 172.16.X.X networks that are behind R7.
  8. The security officer made some changes in Area 56, the OSPF neighborship between R5 and R6 is not working anymore.
  9. For some reason R6 doesn't see any of the networks from the backbone area, see if you can find and solve the issue.
  10. R6 is configured to redistribute RIP into OSPF, however you don't see any of the networks coming from R7 in any of the OSPF routers.
  11. The network engineer of R6 has configured summarization of the RIP routes. however you still see 4 different 172.16.0.0 /24 networks.Configure the correct summary and make sure you don't advertise networks that you don't have.
  12. You notice that the 6.6.6.0 network is advertised in OSPF as a /24, make sure it's advertised as a /32 without changing the subnet mask.
  13. The Redistributed routes in OSPF have the same cost, no matter which router you look at. Change this on R6 so the cost increases throughout the network.

Topology

c5ospf1.png

Configuration

1

The first thing to check when OSPF neighborships are not working is whether the network statements are correct or present.

The 'show ip protocols' command reveals this information:

R1#show ip protocols
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is 13
  Router ID 4.4.4.4
  Number of areas in this router is 0. 0 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
 Reference bandwidth unit is 100 mbps
  Passive Interface(s):
    Serial0/0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 110)

Not only is OSPF disabled for the interface s0/0, but the interface is configured to passive. What this means is that OSPF will not send Hello messages down that interface, therefore will not form any adjacencies.

R1(config)#router ospf 1
R1(config-router)#net 192.168.123.1 0.0.0.0 area 0
R1(config-router)#no passive s0/0

Part of the problem is fixed, but the adjacencies do not happen. A ping reveals that there is no connectivity to the other routers:

R1#ping 192.168.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

It cannot be a routing problem because the network is directly connected. The other option is that layer 2 connectivity is not there.

R1#show frame map

R1#

Indeed, it appears that there are no frame-relay mappings on the interface.

The following command reveals that there are two DLCI's configured on the link. It makes sense that 102 would lead to R2 and 103 to R3.

R1#show frame pvc
[...]

DLCI = 102, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
[...]

DLCI = 103, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
[...]

To fix the Frame Relay problem, add the frame-relay mappings on the interface:

R1(config)#int s0/0
R1(config-if)#frame map ip 192.168.123.2 102 broadcast
R1(config-if)#frame map ip 192.168.123.3 103 broadcast
R1#ping 192.168.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/28 ms
R1#ping 192.168.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/21/28 ms

Pings are successful, but OSPF does not react.

If there is connectivity, one of the possible problems with OSPF adjacencies would be mismatching parameters. For this reason, I decided to use a debug command on R1. In a normal network, debug commands are off-limits because they will freeze your router.

R1#debug ip ospf hello
OSPF hello events debugging is on
R1#
*Mar  1 00:05:36.443: OSPF: Rcv hello from 2.2.2.2 area 0 from Serial0/0 192.168.123.2
*Mar  1 00:05:36.447: OSPF: Mismatched hello parameters from 192.168.123.2
*Mar  1 00:05:36.447: OSPF: Dead R 40 C 36, Hello R 10 C 9
*Mar  1 00:05:36.607: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 192.168.123.1
*Mar  1 00:05:36.819: OSPF: Rcv hello from 3.3.3.3 area 0 from Serial0/0 192.168.123.3
*Mar  1 00:05:36.823: OSPF: Mismatched hello parameters from 192.168.123.3
*Mar  1 00:05:36.823: OSPF: Dead R 40 C 36, Hello R 10 C 9

R1#show ip ospf int s0/0
Serial0/0 is up, line protocol is up
  Internet Address 192.168.123.1/24, Area 0
  Process ID 1, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 9, Dead 36, Wait 36, Retransmit 5
[...]

And indeed, it appears that the Hello interval is incorrect.

R1(config)#int s0/0
R1(config-if)#ip ospf hello-interval 10
*Mar  1 00:08:36.467: %OSPF-4-NONEIGHBOR: Received database description from unknown neighbor 3.3.3.3

Setting the correct Hello interval does seem to fix the problem, but create another. The console is flooded with flapping OSPF adjacency messages.

The reason for this is that, as you can see in the 'show ip ospf int s0/0' output above, the interface is configured as a POINT_TO_POINT interface. In this case, OSPF assumes that there can only be one neighbor on that link, thus replacing the adjacency with a new one every time it receives a Hello message.

To fix this, the interface must be set to the correct type. For a Frame-Relay network, the type is NON_BROADCAST.

R1(config)#int s0/0
R1(config-if)#ip ospf network non-broadcast
R1(config-if)#ip ospf hello-interval 10

The Hello interval must be reconfigured, otherwise it would stay at 30 seconds which is the default for NBMA type networks.

This fixes the problem and the adjacencies form correctly.
Now, to add the non-problematic link as well:

R1(config)#router ospf 1
R1(config-router)#net 192.168.12.1 0.0.0.0 area 0

Finally, everything appears to be in order:

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:31    192.168.12.2    FastEthernet1/0
2.2.2.2           1   2WAY/DROTHER    00:00:35    192.168.123.2   Serial0/0
3.3.3.3           1   FULL/DR         00:00:30    192.168.123.3   Serial0/0

2

I encountered a problem with this. Router R1 seems to have learned of no routes from R2 and R3. The lab requires sending traffic to R2 which is not possible unless there are some networks there.

Either the routers are not sending the updates or R1 is not receiving them for some reason.

There is an access-list on router R1 which permits only network matched by the prefix/wildcard mask 5.5.5.0 0.0.0.255. This is configured as a distribute-list in ospf 1 which makes ospf deny any route besides 5.5.5.0/24

R1(config)#router ospf 1
R1(config-router)#no distribute-list 13 in

There is another problem, however. I shutdown the f1/0 interface on R1 so that it does not add any confusion.

R1#show ip route
[...]
C    192.168.123.0/24 is directly connected, Serial0/0
C    192.168.12.0/24 is directly connected, FastEthernet1/0
     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 192.168.123.3, 00:02:41, Serial0/0
C    192.168.145.0/24 is directly connected, FastEthernet2/0

R1 only receives routes from R3. As we can see from the 'show ip ospf neighbor' output right before the beginning of problem #2, R3 is a DR on the Frame Relay segment and R2 is a DROTHER. This means that the R1-R2 adjacency will stop at 2-Way and they will not exchange routes.

R3 does not have anything to say about R2, which leads me to believe that this is a Hub and Spoke topology with R1 as the hub. In such a topology, the DR must be the hub router.

R1#show ip ospf int s0/0
Serial0/0 is up, line protocol is up
  Internet Address 192.168.123.1/24, Area 0
  Process ID 1, Router ID 4.4.4.4, Network Type BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DROTHER, Priority 0
[...]

Because of priority 0, R1 will not even participate in the DR/BDR election.

R1(config)#int s0/0
R1(config-if)#ip ospf priority 10

The DR will not change because this command is not preemptive.

Restarting routers R2 and R3 will result in R1 being elected as DR. However, for this to work properly, R2 and R3 must be configured with priority 0.

Now the IP routing table is correct on R1.

The reason that traffic from R1 to R2 goes through the FastEthernet interface is because it is the better route. FastEthernet interfaces have a cost of 1, while Serial interfaces have a cost of 65.

To make R1 prefer the route through Frame Relay, I just have to make the route appear to be better by changing either the bandwidth or the cost on the FastEthernet interface.

R1(config)#int f1/0
R1(config-if)#ip ospf cost 100
R1#traceroute 2.2.2.2

Type escape sequence to abort.
Tracing the route to 2.2.2.2

  1 192.168.123.2 16 msec *  44 msec

The traffic now goes through 192.168.123.2.

3

First thing to do is check whether ospf is running and configured correctly on all the routers.

R1#show ip proto
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 4.4.4.4
[...]

R4#show ip proto
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 4.4.4.4
  It is an area border router
  Number of areas in this router is 2. 2 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    4.4.4.0 0.0.0.255 area 0
    192.168.145.0 0.0.0.255 area 51
 Reference bandwidth unit is 100 mbps
  Passive Interface(s):
    FastEthernet0/0
    Loopback0
    VoIP-Null0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 110)

R5#show ip proto

R5#

I already know that router R1 does not have the network statement configured because of previous output. However, there is another problem on R1. The router ID of R1 is 4.4.4.4, same as R4. That will not work, because the routers need to have unique IDs.

R4 seems to be configured correctly (except the passive interface statement which shouldn't be there), but R5 does not have any configuration.

R1(config)#router ospf 1
R1(config-router)#router-id 1.1.1.1
Reload or use "clear ip ospf process" command, for this to take effect
R1(config-router)#net 192.168.145.1 0.0.0.0 area 51
R1#clear ip ospf process
Reset ALL OSPF processes? [no]: yes

The adjacency with R4 should form as soon as the OSPF process is restarted.

R4(config)#router ospf 1
R4(config-router)#no passive-interface f0/0

R5(config)#router ospf 1
R5(config-router)#net 5.5.5.5 0.0.0.0 area 51
R5(config-router)#net 192.168.145.5 0.0.0.0 area 51

Everything is now up and running and the adjacencies are formed.

4

R4(config)#int f0/0
R4(config-if)#ip ospf priority 10

This is not preemptive, so the current DR/BDR will not change. But this is all there is to setting R4 as the preferred DR in the ethernet segment. R1 and R5 need to have their ospf processes restarted to have R4 as the DR.

5

The solution to this is a Virtual Link.

R1(config)#router ospf 1
R1(config-router)# area 51 virtual-link 4.4.4.4

R4(config)#router ospf 1
*Mar  1 01:12:02.115: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 192.168.145.1, FastEthernet0/0
R4(config-router)#area 51 virtual-link 1.1.1.1

This creates a tunnel from R1 to R4 which connects the two Area 0 islands so that they can communicate using OSPF.

Virtual-Link identifies the peer by the OSPF router ID, not the interface in the ethernet segment.

6

I fixed this already when I removed the distribute-list configured in router R1's OSPF 1 process.

All routes are present.

7

The first thing to verify is that router R6 is actually redistributing the RIP routes.

R6#sh ip proto
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 6.6.6.6
  It is an autonomous system boundary router
  Redistributing External Routes from,
    rip
  Number of areas in this router is 1. 0 normal 1 stub 0 nssa
[...]

And indeed it is. One thing that catches the eye is the last line. R6 says it has 0 normal, 1 stub and 0 nssa areas. However, area 56 is supposed to be a nssa.

R5#show ip proto
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 5.5.5.5
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    5.5.5.5 0.0.0.0 area 51
    192.168.145.5 0.0.0.0 area 51
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    4.4.4.4              110      00:06:34
    1.1.1.1              110      00:06:29
  Distance: (default is 110)

The probem on R5 is that it does not have the network statement for the R5-R6 link.

R5(config)#router ospf 1
R5(config-router)#network 192.168.56.5 0.0.0.0 area 56
R5(config-router)#area 56 nssa

This adjacency will not form because one of the criteria for OSPF routers to form an adjacency is identical area ID.

R5#debug ip ospf hello
OSPF hello events debugging is on
*Mar  1 01:25:01.127: OSPF: Rcv hello from 6.6.6.6 area 56 from FastEthernet1/0 192.168.56.6
*Mar  1 01:25:01.131: OSPF: Hello from 192.168.56.6 with mismatched NSSA option bit

The debug output confirms this. Area 56 on R6 needs to be configured as a NSSA.

R6(config)#router ospf 1
R6(config-router)#area 56 nssa
OSPF: Area is configured as stub area already
R6(config-router)#no area 56 stub
R6(config-router)#area 56 nssa

The neighbor relationships do not form, even though everything should be correctly configured.

It would be a good idea to check for connectivity before trying to troubleshoot OSPF any further.

R5#ping 192.168.56.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.56.6, timeout is 2 seconds:
U.U.
Success rate is 0 percent (0/4)

This should not happen because the network is directly connected. The problem is most likely on R6.

R6#ping 192.168.56.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.56.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R6#ping 192.168.56.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.56.6, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Not only can R6 not ping R5, but it cannot ping its own interface. The interface status is up.

R6#ping 192.168.56.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.56.6, timeout is 2 seconds:

*Mar  1 01:35:03.087: IP: tableid=0, s=192.168.56.6 (local), d=192.168.56.6 (FastEthernet0/0), routed via RIB
*Mar  1 01:35:03.091: IP: s=192.168.56.6 (local), d=192.168.56.6 (FastEthernet0/0), len 100, sending
*Mar  1 01:35:03.099: IP: s=192.168.56.6 (FastEthernet0/0), d=192.168.56.6, len 100, access denied

Access denied.

R6#show ip access-list
Standard IP access list 20
    10 permit 1.1.1.0, wildcard bits 0.0.0.255

There is an access-list that blocks everything apart from packets with source in the network 1.1.1.0/24. This access-list is most likely applied to the interface.

R6(config)# int f1/0
R6(config-if)#no ip access-group 20 in

The neighbor relationship does not yet form, but there are some good news:

R6#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
5.5.5.5           0   2WAY/DROTHER    00:00:30    192.168.56.5    FastEthernet0/0

Connectivity is restored between R5 and R6, but they seem to be stuck in 2-Way. In this state the routers have exchanged Hello packets and have listed each other as neighbors. In this state the DR/BDR are elected as well, because this is a FastEthernet link, therefore a BROADCAST network type.

R5#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DROTHER    00:00:39    192.168.145.1   FastEthernet0/0
4.4.4.4          10   FULL/DR         00:00:33    192.168.145.4   FastEthernet0/0
6.6.6.6           0   2WAY/DROTHER    00:00:33    192.168.56.6    FastEthernet1/0

The 'show ip ospf neighbor' reveals that both routers have a priority of 0. This priority means that neither of the routers will participate in the election, so neither of them will become a DR. In a BROADCAST type network, full relationships are established only to the DR and BDR, which is why R5 and R6 are stuck in 2-Way.

R5(config)#int f1/0
R5(config-if)#ip ospf prio 1

Setting a priority on R5 and clearing its OSPF process will result in R5 being a DR.

R6#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
5.5.5.5           1   EXSTART/DR      00:00:36    192.168.56.5    FastEthernet0/0

Still does not work. R5 seems to be stuck in EXSTART now. The routers do not agree on some of the parameters.

R5#sh ip int f1/0
FastEthernet1/0 is up, line protocol is up
  Internet address is 192.168.56.5/24
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1100 bytes

R6#sh ip int f0/0
FastEthernet0/0 is up, line protocol is up
  Internet address is 192.168.56.6/24
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1500 bytes

I looked around to check that the router ID's are unique, the area ID is correct, the timers are identical. There is no authentication.

When I checked whether the network masks are the same, I noticed that the MTU value is different. The default is 1500 on all routers, but R5 has it set to 1100

R5(config)#int f1/0
R5(config-if)#no ip mtu

The adjacency goes to full immediately.

8

Fixed at problem #7. There were several problems: the access-list permitting the 1.1.1.0/24 network, thus denying everything else because of the implicit deny at the end of the list, DR/BDR election was failing because both routers had priority 0 and the routers did not agree on the MTU parameters.

9

Area 56 is connected to Area 51, which is not normal in a properly designed OSPF network, because Area 56 is not connected to the backbone.
A Virtual Link between R1 and R5 needs to be established to connect Area 56 to Area 0.

R5(config)#router ospf 1
R5(config-router)#area 51 virtual-link 1.1.1.1

R1(config)#router ospf 1
*Mar  1 00:13:34.215: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 192.168.145.5, FastEthernet2/0
R1(config-router)#area 51 virtual-link 5.5.5.5

10

Checking the Link-State database of OSPF on R6 reveals some information:

[...]
                Type-7 AS External Link States (Area 56)

Link ID         ADV Router      Age         Seq#       Checksum Tag
192.168.67.0    6.6.6.6         18          0x80000001 0x003683 0

There is a Type-7 LSA on R6, but only the R6-R7 link is present. Type-7 LSA stands for external routes injected into a NSSA area.
The problem seems to be a redistribution issue on R7, so the next step would be to check OSPF on R7.

R7>show ip proto
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 26 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
[...]

"Redistributing: rip" is not okay. Configured like this, R7 is redistributing only classful networks, which is not the case for the 172.16 loopbacks.

R6(config)#router ospf 1
R6(config-router)#redistribute rip subnets

The routes are now present on R1, R4 and R5.

11

The problem is on R6, it is not summarizing the networks correctly.

There are two ways to summarize routes on an OSPF router:

R6#show ip ospf 1 | begin Area 56
    Area 56
        Number of interfaces in this area is 2
        It is a NSSA area
        Area has no authentication
        SPF algorithm last executed 00:32:46.376 ago
        SPF algorithm executed 13 times
        Area ranges are
           172.16.0.0/16 Passive Advertise
[...]

R6#show ip ospf summary

OSPF Process 1, Summary-address

    Not configured

The first one is using the 'area # range <address> <mask>' command. What it does is summarize routes on Area Border Routers. For example, R5 can summarize routes learned from area 56 to area 51.

The second way is using the 'summary-address <address> <mask>' command. This does nothing to inter-area routes, but it is used to summarize external routes.

The problem on R6 is that 'area # range' command was used instead of the 'summary-address' command.

R6(config)#router ospf 1
R6(config-router)#no area 
R6(config-router)#summary-address 172.16.0.0 255.255.252.0

The subnet mask was also used incorrectly, because R6 does not have all of the 172.16 networks included in a class B network. Mask /22 should be used, which includes only the four routes that R6 knows about.
The change is reflected on R5:

R5#show ip route | i 172
     172.16.0.0/22 is subnetted, 1 subnets
O N2    172.16.0.0 [110/20] via 192.168.56.6, 00:00:52, FastEthernet1/0

12

By default, an OSPF router treats a loopback network as a stub host, which results in a /32 mask when it is advertised in OSPF.
The default behavior was modified by the administrator.

R6#show ip ospf int l0
Loopback0 is up, line protocol is up
  Internet Address 6.6.6.6/24, Area 56
  Process ID 1, Router ID 6.6.6.6, Network Type POINT_TO_POINT, Cost: 1

To revert back to default behavior, just negate the 'ip ospf network' command on the respective interface.

R6(config)#int l0
R6(config-if)#no ip ospf network

R5 now receives the route as a /32.

R5#show ip route
[...]
     6.0.0.0/32 is subnetted, 1 subnets
O       6.6.6.6 [110/2] via 192.168.56.6, 00:01:30, FastEthernet1/0
[...]

13

External routes have one of two types of metric when they are injected into OSPF:

E1 - cost is modifed throughout the OSPF domain
E2 - cost is not modified

The default is type E2.

R6(config)#router ospf 1
R6(config-router)#redistribute rip subnets metric-type 1

The changes are now visible on R5 and R1:

R5#show ip route | i 7.7.7.0
O N1    7.7.7.0 [110/22] via 192.168.56.6, 00:03:02, FastEthernet1/0

R1#show ip route | i 7.7.7.0
O E1    7.7.7.0 [110/23] via 192.168.145.5, 00:03:08, FastEthernet2/0

N1 and N2 are the equivalent of E1 and E2, but they are used to distinguish the routes coming from NSSA areas.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License