Just another Cisco blog
MPLS and BGP Lab Guide, Part 6
This is the sixth post in the series, the goal of the series is to provide a guide for the MPLS and BGP Lab I posted awhile back. The labs consists of MPLS VPNs and BGP along with some OSPF, NAT, IPSEC and GRE exposure. I will be posting the files needed for this lab at the bottom. Here’s the topology and the requirements:
(click image for fullsize)
Requirements:
Internet
* The two Internet routers should serve as transit ASes. No other routers should permit transit traffic.
* Internet sites (modeled by loopbacks) should be accessible by all lan IPs.
Clients
* London, Paris, and New York have Internet connections to their respective ISPs. New York is dual-homed.
* London, Paris, New York, and Chicago all have MPLS connections to the same provider. New York and Chicago constitute one company, while London and Paris constitute another. Their routes should not mix over MPLS.
* London, Paris, and New York each have data centers with a DMZ that should be publicly accessible.
* London, Paris, New York, and Chicago each have 2 LANs which should not be accessible from the Internet, though they should be able to access the Internet.
* London and Paris have a GRE over IPSEC connection between them that should take over routing between their LANs in case the MPLS connection fails. Additionally, the MPLS connection should take over for DMZ sites if the Internet connection should fail.
MPLS
* The MPLS-P router should be the only one in area 0. It should be an ABR connection MPLS-PE1 (a stub area 1) and MPLS-PE2 (a stub area 2).
* Area 1 and Area 2 should be summarized to /24′s before being injected into the OSPF backbone.
* The PE routers should communicate via BGP to the CE routers.
Today we will configure the M routers for London, NY, Paris and Chicago:
London-M
hostname London-M ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface FastEthernet0/0 description Connection to London-I ip address 192.168.0.254 255.255.255.0 ! interface Serial1/0 description Connection to MPLS-PE1 ip address 172.16.1.2 255.255.255.252 ! router bgp 65000 no synchronization bgp log-neighbor-changes network 192.168.1.0 neighbor 172.16.1.1 remote-as 65535 neighbor 192.168.0.1 remote-as 65000 neighbor 192.168.0.1 next-hop-self no auto-summary |
Relatively basic stufff here. We have the Loopback configured to simulate the LAN, then we have interfaces connecting to London-I and MPLS-PE1. Our BGP config is not complex, we have two neighbors, one internal and one external, and we’re advertising our LAN.
NewYork-M
hostname NewYork-M ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface FastEthernet0/0 description Conection to NewYork-I ip address 192.168.0.254 255.255.255.0 ! interface Serial1/0 description Connection to MPLS-PE1 ip address 172.16.1.6 255.255.255.252 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 192.168.1.0 neighbor 172.16.1.5 remote-as 65535 neighbor 192.168.0.1 remote-as 65001 neighbor 192.168.0.1 next-hop-self no auto-summary |
Paris-M
hostname Paris-M ! interface Loopback0 ip address 192.168.4.1 255.255.255.0 ! interface FastEthernet0/0 description Connection to Paris-I ip address 192.168.2.254 255.255.255.0 ! interface Serial1/0 description Connection to MPLS-PE2 ip address 172.16.2.2 255.255.255.252 ! router bgp 65002 no synchronization bgp log-neighbor-changes network 192.168.4.0 neighbor 172.16.2.1 remote-as 65535 neighbor 192.168.2.1 remote-as 65002 neighbor 192.168.2.1 next-hop-self no auto-summary |
Chicago-M
hostname Chicago-M ! interface Loopback0 ip address 192.168.5.1 255.255.255.0 ! interface Serial1/0 description Connection to MPLS-PE2 ip address 172.16.2.6 255.255.255.252 ! router bgp 65003 no synchronization bgp log-neighbor-changes network 192.168.5.0 neighbor 172.16.2.5 remote-as 65535 no auto-summary |
The rest of the M routers are configured similarly, so I won’t redundantly explain everything. Let’s test things:
Chicago-M#sh ip route
...
172.16.0.0/30 is subnetted, 2 subnets
B 172.16.1.4 [20/0] via 172.16.2.5, 00:55:17
C 172.16.2.4 is directly connected, Serial1/0
C 192.168.5.0/24 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks
B 10.2.1.0/30 [20/0] via 172.16.2.5, 00:53:45
B 10.1.1.0/30 [20/0] via 172.16.2.5, 00:54:46
B 10.1.0.0/30 [20/0] via 172.16.2.5, 00:53:14
B 10.128.0.0/16 [20/0] via 172.16.2.5, 00:54:46
B 10.129.0.0/16 [20/0] via 172.16.2.5, 00:54:46
B 10.192.2.0/24 [20/0] via 172.16.2.5, 00:53:45
B 10.192.0.0/24 [20/0] via 172.16.2.5, 00:53:14
B 10.192.1.0/24 [20/0] via 172.16.2.5, 00:54:46
B 192.168.1.0/24 [20/0] via 172.16.2.5, 00:55:18
Chicago-M#ping 10.128.0.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.128.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.5.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/28/48 ms
Chicago-M#ping 10.192.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.192.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/40/64 ms |
Here we see that Chicago-M can ping the internet from its LAN interface, and it can communicate with the DMZ on NewYork-I.
That’s it for the series, the lab is complete other than some simple things I was too lazy to configure. Check out the Dynamips/GNS3 page for links to every post in the series, as well as all the configs. Here are the files needed for the lab:
The Dynagen/GNS3 .net file
The IP Address Allocations
The Visio Diagram for the Lab
(You will need to modify the .net file to reflect your own IOS and path values)
Related Posts:
| Print article | This entry was posted by Colby on December 31, 2009 at 9:06 am, and is filed under Labs, Tutorials. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
No trackbacks yet.
Educational IOS Petition
about 3 weeks ago - 3 comments
Greg at Etherealmind has created a petition for an educational IOS version. Details:
We the undersigned ask you to sign our petition.
We are the people who are learning about Data networking and Cisco IOS software. As students and practitioners, we need to learn theory and knowledge and then to take that knowledge and practice on Cisco IOS software.
We want to be able to practice that knowledge, and demonstrate our competence. We know that you are considering the value. This petition is to show our need for this solution. Wendel Odom discusses the possibility Cisco Considers IOS for Certifcation Self Study and we are calling for Cisco to make an option available.
This experience and knowledge we gain gives us the capability to make the most of Cisco equipment for our employers, your customers. We help drive the best return on investment, and keep the network performing in the way that your customers expect.
We can test configurations prior to making and be better prepared. We can develop more complex configurations than would otherwise be possible, and not blame the equipment afterwards.
We resolve problems more quickly, we make better designs and we have greater confidence in our work. We raise less support cases (and reduce your costs) by being to perform our own testing and validation.
Whether we are resellers, consultants, students or just interested in learning, we all need an practical method to access IOS and practice.
Therefore, we are asking Cisco Systems to make a version of IOS available for educational and testing purposes.
Greg Ferro
I encourage everyone reading this to sign it!
Related Posts:
OSPF Summarization
about 1 month ago - 10 comments
This post is about OSPF Summarization. We’ll be using a familiar topology and going over two ways to summarize with OSPF.
There are two conventional ways to summarize networks in OSPF, we can use the “area range” command and the “summary-address” command. “Area range” is used on the ABR to summarize networks between areas. The “summary-address” command is used on the ASBR to summarize external networks.
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. On R1 I’ve added Lo11-14 and used “ospf 100 area 0″ under the respective interfaces. On R2 I’ve added Lo15-18 and used “redistribute connected subnets”. Let’s look at the RIBs on a couple routers:
First we’ll check out “sh ip route” on R1:
R1#sh ip route
...
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 01:13:32, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.123.3, 01:12:38, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.123.3, 01:03:47, FastEthernet0/0
172.30.0.0/24 is subnetted, 4 subnets
O E2 172.30.6.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
O E2 172.30.7.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
O E2 172.30.5.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
O E2 172.30.8.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
C 192.168.4.0/24 is directly connected, Loopback14
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.34.0 [110/74] via 10.1.123.3, 01:12:39, FastEthernet0/0
C 10.1.123.0 is directly connected, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Loopback11
C 192.168.2.0/24 is directly connected, Loopback12
C 192.168.3.0/24 is directly connected, Loopback13 |
Lots of routes here. The ones to note are the 172s showing as External Type 2, which are R2′s loopbacks. Also notice our connected loopbacks.
Now let’s check out the RIB on R4:
R4#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
172.30.0.0/24 is subnetted, 4 subnets
O E2 172.30.6.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O E2 172.30.7.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O E2 172.30.5.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O E2 172.30.8.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.4.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.1.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.2.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.3.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0 |
Here we see the loopbacks from R1 as Inter-Area, and the loopbacks from R2 as External Type 2.
Now we’ll configure the “area range” command to summarize R1′s loopbacks on R3 (ABR):
R3(config)#router ospf 100 R3(config-router)#area 0 range 192.168.0.0 255.255.248.0 |
Seems almost too easy. We use “area 0 range [IP] [Summary Mask]“.
Let’s verify on R4:
R4#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
172.30.0.0/24 is subnetted, 4 subnets
O E2 172.30.6.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
O E2 172.30.7.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
O E2 172.30.5.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
O E2 172.30.8.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:04:51, Serial0/0
O IA 192.168.0.0/21 [110/75] via 10.1.34.3, 00:00:13, Serial0/0 |
It worked! We shrunk all those loopbacks from R1 into a single summary route.
Now we’ll summarize on R2 (ASBR) using the “summary-address” command.
R2(config)#router ospf 100 R2(config-router)#summary-address 172.30.0.0 255.255.240.0 |
Again, pretty easy stuff, we used the “summary-address [IP] [Summary Mask]” command on R2 (ASBR) to summarize its loopbacks.
Let’s look at R4′s RIB now:
R4#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:37:55, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:02:15, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:04:01, Serial0/0
172.30.0.0/20 is subnetted, 1 subnets
O E2 172.30.0.0 [110/20] via 10.1.34.3, 00:02:15, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:37:55, Serial0/0
O IA 192.168.0.0/21 [110/75] via 10.1.34.3, 00:33:17, Serial0/0 |
It worked this time too. We see two summaries now, one Inter-Area summary for R1′s loopbacks, which we summarized on R3 (ABR) and also a External Type 2 summary for R2′s loopbacks which we configured on R2 (ASBR) itself.
Something to note before I end this one, when we create summary routes the router will install a “discard route” to null locally. This helps prevent routing loops. It will not interfere with the networks we summarize for as they are longer matches. Here are the two examples:
R2#sh ip route | i Null O 172.30.0.0/20 is a summary, 00:09:02, Null0 R3#sh ip route | i Null O 192.168.0.0/21 is a summary, 00:39:27, Null0 |
That’s OSPF Summarization in a nutshell. There are some other tricks you can use when summarizing, I may go into them in another post. Or you guys could talk about them in the comments. 
Related Posts:
OSPF Area Types: Not So Totally Stubby
about 1 month ago - No comments
This is the last post in a series about OSPF Area Types. Today we’ll go over Not So Totally Stubby Areas. We’ll be using the same topology as the NSSA post, but this time we will inject a specific route (40.40.40.0/24) from the ASBR (R4) instead of a default.
Quick refresher, OSPF Not So Totally Stubby Areas have intra-area routes (Type 2 LSAs) and also external routes in the form of Type 7 LSAs, which are converted to Type 5 LSAs by the ABR. No inter-area routes (Type 3 LSAs) are permitted in a Not So Totally Stubby Area and a default route will be injected by the ABR.
(For more detailed information on LSAs and Area Types, check out this post.)
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve redistributed loopbacks on each router (“redistribute connected subnets” under the OSPF process) to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. I’ve also added a static route on R4 (40.40.40.0/24) which I’m injecting into OSPF with the “redistribute static subnets” command. Let’s look at some show commands BEFORE we make area 34 a Not So Totally Stubby Area:
First we’ll check out “sh ip route ospf” on R3:
R3#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.123.1, 00:04:20, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:04:20, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.34.4, 00:03:33, Serial0/0
40.0.0.0/24 is subnetted, 1 subnets
O E2 40.40.40.0 [110/20] via 10.1.34.4, 00:02:57, Serial0/0 |
Here we see all the loopbacks and the static (40.40.40.0/24) come through as external type 2, which is the default.
Now let’s check out the RIB on R4:
R4#sh ip route
...
Gateway of last resort is not set
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:04:51, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
40.0.0.0/24 is subnetted, 1 subnets
S 40.40.40.0 is directly connected, Null0
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.34.0 is directly connected, Serial0/0
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:04:51, Serial0/0 |
We see one intra-area route (O – LSA 2) to 34.34.34.34/32, one inter-area route (O IA – LSA 3) to 10.1.123.0/23 and three external type 2 (O E2 – LSA 5) routes to the respective loopbacks. Also notice the static (40.40.40.0/24) to null0, which we’re injecting into the OSPF domain.
Now we’ll configure area 34 as not so totally stubby:
R3(config)#router ospf 100 R3(config-router)#area 34 nssa no-summary R4(config)#router ospf 100 R4(config-router)#area 34 nssa |
Easy stuff, we configure area 34 with “nssa no-summary” on R3 (ABR), then we configure R4 (ASBR) with “nssa” for area 34.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:50, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O N2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:50, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.34.3, 00:01:50, Serial0/0 |
We now have only three OSPF routes, our O (LSA 2) for the 34.34.34.34/32 network, our O*IA default route, which is injected from R3 (ABR) and the N2 (LSA 7) route for R3′s loopback, which is being redistributed with the “redistribute connected subnets” command on R3.
Here’s R4′s OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 255 0x80000006 0x00A1D5 3
4.4.4.4 4.4.4.4 252 0x80000009 0x0025E4 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 3.3.3.3 272 0x80000001 0x00DE4B
Type-7 AS External Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Tag
3.3.3.3 3.3.3.3 271 0x80000001 0x00E69F 0
4.4.4.4 4.4.4.4 256 0x80000001 0x0090B4 0
40.40.40.0 4.4.4.4 256 0x80000001 0x00A339 0 |
We see the router LSAs for R3 and R4, which are normal. Next we see the Type 3 LSA for the default route R3 is injecting and finally we see three Type 7 LSAs, one for each external network injected into area 34.
Last we’ll look at R1′s RIB so we can see how Not So Totally Stubby Areas affect the OSPF domain:
R1#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O IA 34.34.34.34 [110/11] via 10.1.123.3, 00:14:31, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:15:24, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.123.3, 00:14:31, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.123.3, 00:05:40, FastEthernet0/0
40.0.0.0/24 is subnetted, 1 subnets
O E2 40.40.40.0 [110/20] via 10.1.123.3, 00:05:40, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.34.0 [110/74] via 10.1.123.3, 00:14:31, FastEthernet0/0 |
The table looks normal. The important thing to note here is that the external routes from R4 are showing up as O E2 (LSA 5s), which we know is caused by R3 converting them from the Type 7s which only exist in NSSAs to Type 5s, which are allowed in normal areas.
Not So Totally Stubby Areas sound odd, and I’ve never seen them in the real world, but they are fair game on the CCIE lab, and you may come across them in a real network. The key concepts are simply that LSA Type 5s are not allowed in Not So Totally Stubby Areas, external routes will show as N (LSA 7s) in the RIB and are converted to Type 5s on the ABR before leaving the area. Also remember that the ABR injects a default route like a normal Totally Stubby Area.
Related Posts:
OSPF Area Types: NSSA
about 1 month ago - 3 comments
Today we’ll go over Not So Stubby Areas (NSSA). We will be using a slightly different topology here, we will make R4 an ASBR with a connection to the internet.
Quick refresher, OSPF NSSAs have inter and intra-area routes (Type 2 and Type 3 LSAs) and also external routes in the form of Type 7 LSAs, which are converted to Type 5 LSAs by the ABR.
(For more detailed information on LSAs and Area Types, check out this post.)
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve also redistributed loopbacks on each router (“redistribute connected subnets” under the OSPF process) to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. I’ve also added a static default route on R4 which I’m injecting into OSPF with the “default-information originate” command. Let’s look at some show commands BEFORE we make area 34 an NSSA:
First we’ll check out “sh ip route ospf” on R3:
R3#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.123.1, 00:03:42, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:03:42, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.34.4, 00:04:22, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 10.1.34.4, 00:03:59, Serial0/0 |
Here we see all the loopbacks and the default come through as external type 2, which is the default.
Now let’s check out the RIB on R4:
R4#sh ip route
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:06:39, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:06:02, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:06:02, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:06:39, Serial0/0
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.34.0 is directly connected, Serial0/0
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:06:39, Serial0/0
S* 0.0.0.0/0 is directly connected, Null0 |
We see one intra-area route (O – LSA 2) to 34.34.34.34/32, one inter-area route (O IA – LSA 3) to 10.1.123.0/23 and three external type 2 (O E2 – LSA 5) routes to the respective loopbacks. Also notice the static default to null0, which we’re injecting into the OSPF domain.
Now we’ll configure area 34 as an NSSA:
R3(config)#router ospf 100 R3(config-router)#area 34 nssa R4(config)#router ospf 100 R4(config-router)#no default-information originate R4(config-router)#area 34 nssa default-information-originate |
Pretty basic config, we configure area 34 as NSSA on R3 (ABR), then we remove the “default-information originate” command from R4 (ASBR) and use “area 34 nssa default-information-originate” to change the area to an NSSA and inject the default route.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:02:56, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O N2 3.3.3.3 [110/20] via 10.1.34.3, 00:02:56, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:02:56, Serial0/0 |
We see some cool stuff here, our O and IA routes are still present, but we also have an N2 (LSA 7) route now for R3′s loopback, which is being redistributed.
Here’s R4′s OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 300 0x80000005 0x00A3D4 3
4.4.4.4 4.4.4.4 299 0x80000004 0x002FDF 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
10.1.123.0 3.3.3.3 492 0x80000002 0x005A3F
Type-7 AS External Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 4.4.4.4 304 0x80000001 0x008ADD 0
3.3.3.3 3.3.3.3 491 0x80000001 0x00E69F 0
4.4.4.4 4.4.4.4 304 0x80000001 0x0090B4 0 |
First we see the router LSAs for R3 and R4, which are normal. Next we see the Type 3 LSA for 10.1.123.0 and finally we see three Type 7 LSAs, one for each external network injected into area 34.
Last we’ll look at R1′s RIB so we can get a full picture of how NSSAs affect OSPF domains:
R1#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O IA 34.34.34.34 [110/11] via 10.1.123.3, 00:20:46, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:22:14, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.123.3, 00:20:46, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.123.3, 00:08:16, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.34.0 [110/74] via 10.1.123.3, 00:20:46, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 10.1.123.3, 00:08:16, FastEthernet0/0 |
The table looks normal. The important thing to note here is that the external routes from R4 are showing up as O E2 (LSA 5s), which we know is caused by R3 converting them from the Type 7s which only exist in NSSAs to Type 5s, which are allowed in normal areas.
NSSAs are interesting, I’ve never seen one used in production, but I can see how they may be needed in some situations. The key concepts are simply that LSA Type 5s are not allowed in NSSA, external routes originated in the NSSA will show as N (LSA 7s) in the RIB and are converted to Type 5s on the ABR before leaving the area.
Related Posts:
OSPF Area Types: Totally Stubby
about 1 month ago - 4 comments
This is the first post in a series about OSPF Area Types. Today we’ll go over Totally Stubby areas. We’ll be using the same topology as the Stub post. I’m also reposting the first portion of that here since it will be the same.
Quick refresher, OSPF Totally Stubby Areas allow only intra-area routes and a default route generated by the ABR (Type 2 LSAs – the default route comes through as a Type 3 LSA, but no other Type 3s are allowed). Inter-area and External routes (Type 5 LSAs) are not allowed in totally stubby areas.
(For more detailed information on LSAs and Area Types, check out this post.)
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve also redistributed loopbacks on each router (“redistribute connected subnets” under the OSPF process) to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. Let’s look at some show commands BEFORE we make area 34 totally stubby:
First we’ll check out “sh ip route ospf” on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:17, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:17, Serial0/0 |
As expected, we see everything. 34.34.34.34/32 has come through as an intra-area route (O – LSA 2). We see our loopbacks from each router come through as external (O E2 – LSA 5, something to note is E2 routes do not increment cost as they traverse the network, so we see a cost of 20, which will be the same throughout the OSPF domain). Last we see 10.1.123.0/24 as an inter-area route (O IA – LSA 3).
Now let’s check out the OSPF Database on R4:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 3 0x8000000C 0x00EF87 3
4.4.4.4 4.4.4.4 2 0x8000000D 0x00ABEB 1
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
10.1.123.0 3.3.3.3 113 0x80000003 0x00B2EB
Summary ASB Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 119 0x80000001 0x0057CA
2.2.2.2 3.3.3.3 119 0x80000001 0x0029F4
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 1.1.1.1 1293 0x80000001 0x009BFC 0
2.2.2.2 2.2.2.2 1303 0x80000001 0x004F41 0
3.3.3.3 3.3.3.3 119 0x80000004 0x00FC88 0
4.4.4.4 4.4.4.4 3 0x80000004 0x00B0CC 0 |
Lots of output, but nothing crazy. We see our LSAs for area 34, and our redistributed loopbacks as external LSAs.
Now we’ll configure area 34 totally stubby:
R3(config)#router ospf 100 R3(config-router)#area 34 stub no-summary R4(config)#router ospf 100 R4(config-router)#area 34 stub |
There isn’t much to the config at all, as we can see. The command is “area n stub no-summary”, this tells the ABR not to send Type 3s into the area. On the non-ABR(s) we simply specify the area as a stub, the “no summary” keyword is only needed on the ABR.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:02:04, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.34.3, 00:02:04, Serial0/0 |
Very small table. Here we see that all the external routes are gone, but intra-area route to 34.34.34.34 is still in the table. Our only other OSPF route is the default generated by R3.
Finally we’ll look at the OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 665 0x8000000B 0x000A72 3
4.4.4.4 4.4.4.4 300 0x8000000A 0x00957D 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 3.3.3.3 1214 0x80000001 0x0057DA |
It is much smaller now. We see the router LSAs and a single inter-area LSA, the default route from R3.
Totally Stubby areas are pretty basic once you understand Stub areas and LSAs in general. The key concepts are simply that LSA Type 3s and Type 5s are not allowed in totally stubby areas, and also that a default route is generated by the ABR.
Related Posts:
OSPF Area Types: Stub
about 1 month ago - 5 comments
This is the first post in a series about OSPF Area Types. Today we’ll go over Stub areas. This one will be somewhat short on config, but should have a good amount of show commands.
Quick refresher, OSPF Stub Areas allow inter- and intra-area routes (Type 2 and Type 3 LSAs). External routes (Type 5 LSAs) are not allowed in stub areas.
(For more detailed information on LSAs and Area Types, check out this post.)
We’ll be using the same topology we used for OSPF Authentication:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve also redistributed loopbacks on each router to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. Let’s look at some show commands BEFORE we make area 34 a stub:
First we’ll check out “sh ip route ospf” on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:17, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:17, Serial0/0 |
As expected, we see everything. 34.34.34.34/32 has come through as an intra-area route (O – LSA 2). We see our loopbacks from each router come through as external (O E2 – LSA 5, something to note is E2 routes do not increment cost as they traverse the network, so we see a cost of 20, which will be the same throughout the OSPF domain). Last we see 10.1.123.0/24 as an inter-area route (O IA – LSA 3).
Now let’s check out the OSPF Database on R4:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 3 0x8000000C 0x00EF87 3
4.4.4.4 4.4.4.4 2 0x8000000D 0x00ABEB 1
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
10.1.123.0 3.3.3.3 113 0x80000003 0x00B2EB
Summary ASB Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 119 0x80000001 0x0057CA
2.2.2.2 3.3.3.3 119 0x80000001 0x0029F4
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 1.1.1.1 1293 0x80000001 0x009BFC 0
2.2.2.2 2.2.2.2 1303 0x80000001 0x004F41 0
3.3.3.3 3.3.3.3 119 0x80000004 0x00FC88 0
4.4.4.4 4.4.4.4 3 0x80000004 0x00B0CC 0 |
Lots of output, but nothing crazy. We see our LSAs for area 34, and our redistributed loopbacks as external LSAs.
Now we’ll configure area 34 as a stub:
R3(config)#router ospf 100 R3(config-router)#area 34 stub *Mar 1 00:13:39.675: %OSPF-5-ADJCHG: Process 100, Nbr 4.4.4.4 on Serial0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset R4(config)#router ospf 100 R4(config-router)#area 34 stub *Mar 1 00:03:25.923: %OSPF-5-ADJCHG: Process 100, Nbr 3.3.3.3 on Serial0/0 from LOADING to FULL, Loading Done |
Simple configuration, we configured area 34 as a stub under the OSPF process. Notice that the neighbors go down and reform once they match.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:33, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:33, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.34.3, 00:01:33, Serial0/0 |
Here we see that all the external routes are gone, but intra- and inter-area routes are still in the table. The inter-area route to 10.1.123.0/24 is still there, and we also have a default route, which is showing as an inter-area route as well.
Finally we’ll look at the OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 259 0x8000000E 0x000475 3
4.4.4.4 4.4.4.4 258 0x80000010 0x008983 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 3.3.3.3 308 0x80000001 0x0057DA
10.1.123.0 3.3.3.3 308 0x80000004 0x00CED0 |
It is much smaller now. We see the router LSAs and only two inter-area LSAs, the default route and the route to 10.1.123.0/24.
I was planning on putting a debug in here as well, but I didn’t really get anything interesting enough to add.
OSPF Stub Areas are relatively simple, but can be confusing when first digging into OSPF. The key concepts are simply that LSA Type 5s are not allowed in stub areas, and also that a default route is generated by the ABR. I very much expect to see stub areas of some sort on the CCIE lab.
Related Posts:
OSPF Authentication
about 1 month ago - 3 comments
This post is about the different OSPF authentication methods. It will be part of a series outlining OSPF commands/technologies.
We can configure OSPF to use authentication for an entire area, or just for a single interface. Today we’ll go over both. Here’s the topology:
First we’ll setup authentication for all of area 0:
R1(config)#interface FastEthernet0/0 R1(config-if)#ip ospf message-digest-key 1 md5 cisco R1(config-if)#ip ospf 100 area 0 R1(config-if)# R1(config-if)#router ospf 100 R1(config-router)#area 0 authentication message-digest R2(config)#interface FastEthernet0/0 R2(config-if)#ip ospf message-digest-key 1 md5 cisco R2(config-if)#ip ospf 100 area 0 R2(config-if)# R2(config-if)#router ospf 100 R2(config-router)#area 0 authentication message-digest R3(config)#interface FastEthernet0/0 R3(config-if)#ip ospf message-digest-key 1 md5 cisco R3(config-if)#ip ospf 100 area 0 R3(config-if)# R3(config-if)#router ospf 100 R3(config-router)#area 0 authentication message-digest |
Nothing crazy here, we configure OSPF and an MD5 key under our area 0 interfaces, then we specify that all of area 0 should use MD5 authentication. Note that the commands differ slightly if we want to use clear-text, it would be “ip ospf authentication-key [key]” and “area 0 authentication” under the OSPF 100 process.
Let’s verify:
R1#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:32 10.1.123.2 FastEthernet0/0
3.3.3.3 1 FULL/DROTHER 00:00:35 10.1.123.3 FastEthernet0/0
R1#sh ip ospf int fa0/0
...
Message digest authentication enabled
Youngest key id is 1 |
Everything is working, our neighbors are up and we see that authentication is enabled with the key we specifcied. Note, if we leave off a key, the neigbhors will still form and MD5 will still be enabled, but it will say key 0:
R1(config)#int fa0/0
R1(config-if)#no ip ospf message-digest-key 1 md5 cisco
R2(config)#int fa0/0
R2(config-if)#no ip ospf message-digest-key 1 md5 cisco
R2#sh ip ospf int fa0/0
...
Message digest authentication enabled
No key configured, using default key id 0 |
We see that no key is being used, but MD5 is still working. Not critical knowledge, but may be useful sometime.
Next we’ll configure MD5 between routers R3 and R4:
R3(config)#interface Serial0/0 R3(config-if)#ip ospf authentication message-digest R3(config-if)#ip ospf message-digest-key 2 md5 cisco R3(config-if)#ip ospf 100 area 34 R4(config)#interface Serial0/0 R4(config-if)#ip ospf authentication message-digest R4(config-if)#ip ospf message-digest-key 2 md5 cisco R4(config-if)#ip ospf 100 area 34 |
Notice that here we have not made any changes under the OSPF process, this is all at the interface level. We use the “ip ospf authentication message-digest” command to run MD5 on this interface, then we specify a key the same way as earlier.
We’ll verify this config:
R3#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
4.4.4.4 0 FULL/ - 00:00:36 10.1.34.4 Serial0/0
R3#sh ip ospf int s0/0
...
Message digest authentication enabled
Youngest key id is 2 |
As expected, everything is working.
That’s OSPF authentication. Both ways could be asked on the CCIE Lab, so this is good stuff to know.
Related Posts:
Cisco Port to ASIC Mapping
about 2 months ago - 1 comment
You know you’re a nerd or really bored when you get into conversations about the oversubscription of ports on each ASIC. 
So obviously I was having this conversation, lol. I’m pretty noobish when it comes to the mechanics of network gear. I know the configuration relatively well, but not enough about the internals. So I did some searching and came across this great page on James Ventre’s blog. Check it out if you’re curious about ASICs and how many ports each will support on various platforms. I found some other interesting reading on the site as well.
Here’s another helpful link describing the architecture of the 3750-Es. Page 53 goes into the ASICs specifically.
Related Posts:
BGP Multipath-Relax
about 2 months ago - 4 comments
So I learned a new command today. As usual I want to share with everyone. Today’s command is “bgp bestpath as-path multipath-relax”, which is actually hidden in IOS.
To give some background, BGP will not load balance across multiple paths by default. We can configure it to do so with the “maximum-paths n” command, which is pretty well known. The criteria of this command is that all attributes must match (Weight, LP, AS Path, etc). This is acceptable if we are multihomed to a single AS, but what if we are multihomed to different ASes? In that case we are not able to load balance across theoretically equal paths. Enter the “bgp bestpath as-path multipath-relax” command…
Here’s our first topology:
(click for fullsize)
Now the config:
R1(config)#router bgp 100 R1(config-router)#no synchronization R1(config-router)#neighbor 10.1.12.2 remote-as 200 R1(config-router)#neighbor 10.1.13.3 remote-as 200 R1(config-router)#no auto-summary |
Here we see the basic BGP config on R1. We will only be configuring R1 in this post.
Let’s look at the BGP table and RIB.
R1#sh ip bgp
...
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.1.12.2 0 200 400 i
*> 10.1.13.3 0 200 400 i
R1#sh ip route
...
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.13.0 is directly connected, Serial0/1
C 10.1.12.0 is directly connected, Serial0/0
B 192.168.1.0/24 [20/0] via 10.1.13.3, 00:01:16 |
We see that BGP has selected the path through R3 and put the router in its RIB.
Now we will configure BGP to use two paths, then we’ll verify:
R1(config)#router bgp 100
R1(config-router)#maximum-paths 2
R1#sh ip route
...
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.13.0 is directly connected, Serial0/1
C 10.1.12.0 is directly connected, Serial0/0
B 192.168.1.0/24 [20/0] via 10.1.13.3, 00:03:18
[20/0] via 10.1.12.2, 00:00:15 |
Simple command under the BGP process, we see that R1 is now equally load balancing across both paths.
Now we will change it up a bit.
Here’s our second topology:
(click for fullsize)
This time R2 and R3 are in separate ASes. Let’s try “maximum-paths” again and see what happens:
R1(config)#router bgp 100
R1(config-router)# maximum-paths 2
R1#sh ip bgp
...
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.1.13.3 0 300 400 i
*> 10.1.12.2 0 200 400 i
R1#sh ip route
...
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.13.0 is directly connected, Serial0/1
C 10.1.12.0 is directly connected, Serial0/0
B 192.168.1.0/24 [20/0] via 10.1.12.2, 00:00:04 |
As expected we see that R1 is not load balancing because it does no see the paths as “equal” (different AS Paths).
This is where “bgp bestpath as-path multipath-relax” comes in:
R1(config)#router bgp 100
R1(config-router)#bgp bestpath as-path ?
% Unrecognized command
R1(config-router)#bgp bestpath as-path multipath-relax
R1(config-router)#
R1#sh run | sec bgp
router bgp 100
bgp bestpath as-path multipath-relax
neighbor 10.1.12.2 remote-as 200
neighbor 10.1.13.3 remote-as 300
maximum-paths 2
R1#sh ip route
...
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.13.0 is directly connected, Serial0/1
C 10.1.12.0 is directly connected, Serial0/0
B 192.168.1.0/24 [20/0] via 10.1.13.3, 00:00:16
[20/0] via 10.1.12.2, 00:00:16 |
And it works! Notice that the command doesn’t show up when we use the “?”. It is a hidden command. I’m not sure why at this point, just that it is. We do see it when we look at R1′s BGP config though.
That’s it for this one, just a short post on something new I learned today.
Related Posts:
OSPF Lab #2 Tasks
about 2 months ago - 1 comment
This is the second OSPF post I’ll be doing for CCIE lab preparation. Today I’m posting the tasks, then tomorrow or the day after (or possibly after the weekend, depending how busy I am) I’ll post the walkthrough. If any of you work on this before the walkthrough, leave a comment.
Here’s the topology:
(Click image for fullsize)
Click here for the initial configs
Here are the tasks:
1. Configure R1, R2 and R3′s S0/0 interfaces in Area 0. Ensure that DR and BDR are elected. Advertise all loopback0s on all routers into OSPF.
2. Configure R1 as the default gateway for all OSPF routers. Do not use the “default-information” command.
3. Configure R6 to use the path through R4 to get to area 0 Do not use any interface level commands to accomplish this.
4. Configure R4 to filter any type 3, 4, 5 and 7 LSAs from entering area 45.
5. Resolve discontigous area issues.
6. R5 is using a low-speed, high cost serial link to connect to R4. Ensure that the link is only used when needed.
7. Filter all loopback0s from entering R2′s RIB. Use a distribute list.
8. Configure loopback IPs 192.168.1.1/24, 192.168.2.1/24, 192.168.3.1/24 and 192.168.4.1/24 on R1. Inject a summary for these networks into OSPF, ensure that R2 and R3 see this summary and no specific routes. Do not use any summarization commands under the OSPF process to accomplish this.
9. Configure area 67 to elect a DR and BDR.
(Some of this might change during the walkthrough)
Here’s the .net file:
The Dynagen/GNS3 .net file
(you will need to change the paths to make it work)
about 6 months ago
Interesting post
about 5 months ago
I am absolutely fascinated at how terrific the info is on this web page. I have saved this web site and I truly plan on visiting the site in the upcoming days. Keep up the fantastic work!
about 1 month ago
I came across your site, i think your blog is awsome, keep working !