LAB – Rootguard
You have been working a lot on STP lately and you are coming to appreciate the niceties of a stable L2 topology. To ensure than older devices that still exist in the network you are to protect the core switches from a STP root bridge hijack.
STP Stability
- Enable STP enhancements that will allow SW1 to block downstream switches from becoming a rootbridge
- Enable STP enhancements that will allow SW1 to block downstream switches from becoming a rootbridge
- Ensure this across multiple VLANs.
Bonus: Why is it important to establish a stable topology?
Answer Key Below
LAB – Port Aggregation
You are an employee of Microsoft's Tailspin Toys division. The test lab requires you to increase the throughput of inter-switch connections to allow for new technology to be tested. You are required to increase throughput.
Etherchannel
- Bundle SW1 - SW3 connection with a proprietary protocol with SW1 initiating.
- Bundle SW2 - SW3 connection with a non-proprietary protocol with SW 2 initiating.
- Enable a L3 bundle between SW1 - SW2. Choose any IP range with a /30 mask.
- Enable load balancing based upon dst-ip on SW1 and SW2.
Bonus: Which etherchannel protocol will allow up to 16 ports in an etherchannel (8 active, 8 redundant)?
LAB-Spanning-Tree
You work at a small not-for profit charity. With a small budget that is stretched thin they have invested in better network infrastructure. They don't know anything about networking. You are given this diagram.
Spanning-Tree configuration
- Provision four VLANs across the switches - Voice, Data, Management, vMotion
- Ensure STP 802.1w is used
- Ensure that SW1 is root for Voice and Data, Secondary for Management and Vmotion
- Ensure that SW2 is root for Management and vMotion and secondary for Voice and Data
- Client Devices in the Data VLAN on SW3 need to transition to a forwarding state instantaneously (Any ports)
- Ensure a stable and predictable topology with 802.1w root safeguards.
Bonus: What needs to be considered when procuring hardware and calculating port costs?
LAB- Multiple Spanning-Tree
You work for an online gaming company. It has been decided that the STP topology must scale with support of thousands of VLANs. The solution is to use MST to help reduce load, CPU cycles, and management traffic.
The pilot pod above is what you will use to enable the proof of concept to work.
MST Configuration
- Set the STP mode to MST
- Define VLANs 2,4,6,8,10,12,14,16 across all devices
- map VLAN 2,4,10,12 to Instance 1
- map VLAN 6,8,14,16 to Instance 2
- set SW2 to be the root for Instance 1
- set SW1 to be the root for Instance 2
- set SW3 to be root for CIST
Bonus: If high availability was configured on this network at a later date, what design considerations should you take on board in regards to MST root placements?
I will upload the results in the fullness of time.
Getting probed. The ACE Cisco way!
Now with a title such as this you'd almost think I was going to start talking about Cisco's awesome prices and comparative rates but alas, It is part three of my dive into load balancers.
Previously we have discussed what a load balancer can offer and a simple one-arm configuration. That's great! Now lets look at how to keep your servers up and not up and down like a merry-go-round.
Health Probes are one way to ensure a server is still servicing correctly. It can let a load balancer know that requests to that server will still be there or conversely let it know that the party's over and it's out of action. There are some important things to understand when talking about health probes. Timers. How often, how long and what is being checked. Sounds like a horrible day at t
he doctor's office. Or for some - the daily grind!
Now - back on topic Anthony! Health probes are easily set up but can be a headache. I mentioned that timers are important and I will discuss why. Health checks will place a server in or out of service and it allows the ACE to make informed load balancing decisions. The two categories are Passed - denoting a valid response, and Failed - indicating a server which has failed to provide a response after a specified number of retires.
There are over 1000 unique configurations for probes. Ping, HTTP, ICMP and more! Oh the possibilities. This allows compatibility with a raft of services and software.
Lets get probin'
First we configure the health probe with its name, type of probe, and the attributes associated to it.
probe http ACE-PROBE-HTTP-GET interval 10 faildetect 2 passdetect interval 30 passdetect count 2 request method get url /index.html expect status 200 200
Note above the following settings. First we have defined the probe type including a name for it. Next the interval command specifies how frequently the ACE sends probes to the server marked as passed. This is important. The Goldilocks rule applies here. Timers that are too aggressive can load the server and cause a failure. Timers that are too slow will not be efficient in detecting a failure. Measured in seconds the interval default is 15. Here we have set it to 10 seconds.
Faildetect works by setting a counter and allows you to choose how many probes can fail before a server is marked as failed and placed out of service. Default is 3 and here we have manually defined 2.
Passdetect interval is the next interesting feature and it needs to be set correctly. When a server has failed to respond to probes the passdetect interval must pass before a new probe is sent. That is by default 60 seconds. Too long for me. 30 seconds will suit. To put the server back inservice it must pass 2 health checks defined with passdetect count at the interval value of 10 seconds.
The way I am checking this probe is through a HTTP get request. This allows me to confirm that IIS/Apache is working. If I was just to ping the real server IP, IIS/Apache could fall over and the server would still receive HTTP request and yield unsatisfactory results.
The next important field is expect status 200 200. By default the device will not have an expected statuses set. This means that it will never expect anything and the probe will fail. By defining what to expect this will allow the probe to mark a successful pass! You can define a high and low range with this setting and that will allow you to expect a all sorts of http response codes.
My take
The importance of health probes is paramount to achieving HA. Ineffective timers can cause headaches. What I have shown here is but a fraction with many 00's of the possibilities that are out there. Just remember if you are being aggressive that the probe you are placing on a server farm, that there could be hundreds or thousands of simultaneous probes occurring. This will place more load onto the ACE's finite resources.
More resources
Interval, time, and count are very important to settings to tweak to get the health check "just right". A particular post from Tony Bourke sums up the importance of timings and intervals.
Health Checking On Load Balancers: More Art Than Science
For more information on health checks and load balancing tips and tricks - Please go check out one of the best CCIE DC candidates blog! Lot's of ACE goodies aswell as Nexus and FC resources. Oh and it's full of meme's!
http://datacenteroverlords.com
Previous ACE Articles by @pandom_
Cisco ACE : I’ve not gone green and flipped a table yet.
Cisco Application Control Engine 4710
Cisco ACE : I’ve not gone green and flipped a table yet.
I swear people have had bad luck or I am just lucky. Maybe I am not testing my ACE or using them to their full capacity. So far! Phwoar. What a device. I've not hulked, raged or got angry at it. I've seen people cuss and curse and even grow grey hairs before my eyes. I myself have not done any of it! Medal? Maybe. Serious load? Maybe not 
On the heels of my previous article regarding Cisco ACE load balancers I am following up now with a basic configuration and getting your ACE servicing. Now that we have established the concept of the load balancers role in the network and how it works to deliver increased uptime and performance.
** Disclaimer - I have worked on these in a lab environment and dealt with a handful in a production space. I do not profess to be a rock star and below explanations have been made with my best efforts and understandings. Feel free to point out any major no no's or inconsistencies. **
Remember to allow connectivity first.
In the admin context - change this after if you want to disable http/https or other access methods.
access-list ALL line 8 extended permit ip any any access-list RMT-MGMT-ACL line 8 extended permit ip any any access-list RMT-MGMT-ACL line 16 extended permit icmp any any
Virtual Contexts
The virtualized environment is divided into objects called contexts. Each context behaves like an independent ACE appliance with its own policies, interfaces, domains, server farms, real servers, and administrators. While the server load balancing design doesn’t require multiple contexts for successful implementation, the ACE 4710 appliance is provisioned with one user context on top of the default Admin context. This approach provides better implementation flexibility in the future. One of the possible features that such setup makes available is active/active implementation with load sharing between redundant appliances. Active/active mode of operation requires multiple user contexts to be provisioned and started, therefore this option is left for potential expansion in the future. Each user context is initially defined in the Admin context, which contains the basic settings for each virtual device or context. Each context has a number of SVIs associated with it for communication.
ACE4710-01/Admin# sh contextNumber of Contexts = 3Name: Admin , Id: 0 Config count: 137 Description: Resource-class: default FT Auto-sync running-cfg configured state: enabled FT Auto-sync running-cfg actual state: enabled FT Auto-sync startup-cfg configured state: enabled FT Auto-sync startup-cfg actual state: enabledName: WWW-CXT , Id: 1 Config count: 113 Description: WWW Frontend Context Resource-class: WWW-RC Vlans: Vlan100-101 FT Auto-sync running-cfg configured state: enabled FT Auto-sync running-cfg actual state: enabled FT Auto-sync startup-cfg configured state: enabled FT Auto-sync startup-cfg actual state: enabledName: DNS-CXT , Id: 2 Config count: 167 Description: DNS Lookup Context Resource-class: DNS-RC Vlans: Vlan110-111 FT Auto-sync running-cfg configured state: enabled FT Auto-sync running-cfg actual state: enabled FT Auto-sync startup-cfg configured state: enabled FT Auto-sync startup-cfg actual state: enabled
** Note here that FT auto-sync shows that the running config and startup config are being shared between the Fault Tolerant group.
Resource-Classing - Class those resources boy - maximise your balanced load.
One part of having contexts is the fact you have the ability to allocate an amount of the physical devices resources to a virtual context. In our example below we could split 50 percent of total chassis resources to WWW context and 30 percent to the DNS context. This allows us to reserve 20 percent for Admin base context so the device does not become overloaded.
resource-class DNS-RC limit-resource all minimum 20.00 maximum unlimited limit-resource mgmt-connections minimum 20.00 maximum unlimited limit-resource sticky minimum 20.00 maximum unlimited limit-resource rate mgmt-traffic minimum 20.00 maximum unlimited limit-resource throughput minimum 30.00 maximum equal-to-min resource-class WWW-RC limit-resource all minimum 20.00 maximum unlimited limit-resource mgmt-connections minimum 20.00 maximum equal-to-min limit-resource sticky minimum 20.00 maximum equal-to-min limit-resource rate mgmt-traffic minimum 20.00 maximum equal-to-min limit-resource throughput minimum 50.00 maximum equal-to-minTHO-EST-SLB-01/Admin# sh resource allocation | begin throughput --------------------------------------------------------------------------- Parameter Min Max Class --------------------------------------------------------------------------- throughput 0.00% 80.00% default 50.00% 50.00% WWW-RC 30.00% 30.00% DNS-RC
Although these devices are in a test lab and I am generating my own traffic - these values here should not be taken as gospel and those with far more knowledge of ACE and SLB principles should comment here if you read this. I'd love to know what DC guru's would recommend.
Fault Tolerance and FT Groups
It is possible to share contexts between devices. This allows us to have fail over if a ACE drops. This means we have connection redundancy for traffic passing to the servers as well as device redundancy that will allow us to continue servicing requests if we need to update or lose an ACE peer.
FT Example
ft interface vlan 100 ip address 169.254.0.1 255.255.255.252 peer ip address 169.254.0.2 255.255.255.252 no shutdownhostname ACE4710-01 peer hostname ACE4710-02 ft peer 1 heartbeat interval 300 heartbeat count 10 ft-interface vlan 100 ft group 10 peer 1 peer priority 110 associate-context Admin inservice ft group 20 peer 1 associate-context WWW-CXT inservice ft group 30 peer 1 associate-context DNS-CXT inserviceshared-vlan-hostid 1 peer shared-vlan-hostid 2
Here my FT VLAN allows keep-alives to be passed through to each other. We define the device hostname and the peers hostname then we set up peer 1 and how regular FT heartbeats area and the number required to miss before failure. Then I assign groups to associate contexts to. This allows sharing of context configuration. Then I set the remote peer id and voila! Friendship and Rainbows!
Farmville!
Lets start by discussing server farms and defining real servers. Below we define the following real servers in the ACE.
rserver host WWW01 ip address 192.168.10.10 inservice rserver host WWW02 ip address 192.168.10.11 inservice rserver host WWW03 ip address 192.168.10.12 inservice rserver host WWW04 ip address 192.168.20.13 inservice rserver host DNS01 ip address 192.168.20.10 inservice rserver host DNS02 ip address 192.168.20.11 inservice rserver host DNS03 ip address 192.168.20.12 inservice rserver host DNS04 ip address 192.168.20.13 inservice
One Arm and Virtual Server Farms
Simple enough to define a real server. Important trick to remember is in service. Treat it like no shut! Now that we have define our real servers we need to nest them inside a Virtual Serverfarm.
This server farm will be the IP that is presented to the world. It will distribute requests based upon roundrobin load sharing and service accordingly.
serverfarm host WWW-FRONTEND-SFpredictor roundrobin rserver WWW01 inservice rserver WWW02 inservice rserver WWW03 inservice rserver WW04 inservice serverfarm host DNS-SF predictor roundrobin rserver DNS01 inservice rserver DNS02 inservice rserver DNS03 inservice rserver DNS04 inservice
Simple enough there. Now comes the head scratching pat!
Map inside my Map so we can discover while we discover.
Follow this key and decipher! It does make sense - trust me!
Define the class-map WWW-CMAP. This matches traffic from the listed IP. The Policy map multi-match MATCH-REQUEST-ACTION-PMAP matches our first WWW-CMAP then applies what is contained in the Policy map. The second policy-map then assigns it to a server farm.
** Disclaimer - As far as my little mind understand this is how it all works. Feel free to correct. I have been reading a lot and there isn't much info out there! **
class-map match-all WWW-CMAP 2 match virtual-address 192.168.10.1 tcp eq wwwpolicy-map multi-match MATCH-REQUEST-ACTION-PMAP class WWW-CMAP loadbalance vip inservice loadbalance policy LB-WWW-PMAP loadbalance vip icmp-replypolicy-map type loadbalance http first-match LB-WWW-PMAP class class-default serverfarm WWW-FRONTEND-SF class-map match-all DNS-CMAP 3 match virtual-address 192.168.20.1 tcp eq dns policy-map multi-match MATCH-REQUEST-ACTION-PMAP class DNS-CMAP loadbalance vip inservice loadbalance policy LB-DNS-PMAP loadbalance vip icmp-reply policy-map type loadbalance http first-match LB-DNS-PMAP class class-default serverfarm DNS-SF
Alright - now because this setup is a one-armed ACE install we need to point a static route back to the SVI. Now our traffic goes to a server of the ACE's choosing dealt out by a round-robin styled procedure.
Ant's thoughts
So far so good. The ACE for me has been reliable and customisable as I need. Next little post will cover the health checking probes which allow a Server farm to mark a real server offline. Great if you need to upgrade, install, change or fix. It's a lot to take in but I am enjoy what this product can do.
Oh and expect a rant towards programmers soon with how they put data onto the wire and think that they know best.
Cisco Application Control Engine 4710
Cisco ACE is ACE. I am finding that this statement is a semi-truth. Before inheriting this network with a few ACE clusters, I did some reading. A light google confirmed what I had read on the Twitters but I wanted to find out for myself. It was like Cisco with this device threw a 44 gallon drum of petrol into a bonfire. The catalyst to open revolt. My doppelgänger and Data Center hero Tony Bourke (@tbourke) summed it what he thought of the ACE - especially after teaching it for a long time and now it appearing like a wild Weedle on the CCIE DC exam blueprint.
"It’s kind of like a distant relative who won the lottery: I suddenly find it more interesting. -tbourke 2012 "
So what is this Cisco ACE?
Why the love/hate relationship with it? Or hate/hate? Let's first off start my delving into what the ACE actually is and how it can help you.
The Application Control Engine is Cisco's offering into the load-balancer market. This market has well known vendors such as F5 Networks, Barracuda, Riverbed and Foundry. Cisco's ACE 4710 from simple google searches is a hot topic with contrasting reviews. That doesn't bode well in a market that is dominated by F5 - at least, from all the data centers I walk into .
Load-balancing is the act of distributing traffic across a number of servers. The devices increase the amount of concurrent users and reliability of the application/device. improvement of performance comes from pooling resources and the maintaining of applications/network sessions.
There are two levels of load balancing. Layer 4 and Layer 7. Now, if we refer to the OSI model - Layer 4 includes juicy stuff such as IP, TCP, FTP, UDP. Layer 7 load balancing allows distribution of traffic based upon the application layer protocols - in this case and I am guessing the most used - HTTP.
The next part is the distribution of requests. Both levels of load balancers recieve requests and they are distributed to a particular server-based on algorithms. Crazy Black voodoo is used here. Also known as Maths. These names could ring a bell to some who use the QoS a lot.
- Least connections
- Least response time
- Round Robin
- Weighted Round Robin
I was also surprised when configuring the device to find you could further manipulate requests based on specific data such as Headers, Cookies, Type of Request, and more.
Why do I need one?
Let alone the nice features offered by a load balancer thus far the best part I believe is the ability for a server to go down (or be upgraded) and to not lose connectivity. How is this achieved? Through Virtual Server Farms.
Let's say I run an online store. I would have a cluster of 15 front end web servers set up. On the load balancer I define the real server IPs ( 10.1.1.1-15 ). By doing that I then can assign them to a server farm and assign that farm a virtual IP address (10.1.1.254) This virtual IP address becomes the IP address of the store.
With some CLI magic - I will delve into this further in upcoming posts - it is possible to have machines fail, drop, be pulled offline which is detected by a health check and session states move to a new real server maintaining connection information. Without this you'd just get a timeout.
Wow Ant, this is a lot to take in.
Well I have had a crash course in Load balancers and learnt a lot very quickly. I am currently attempting to copy run start what I have learnt. There is a lot more to discover and share and I will follow-up with a basic config including clustering the load balancers and make posts that include health probes, checks, failover and more.
Thoughts thus far?
I don't think I could have a web server now without one. The protection it can provide is a serious benefit to any 24/7 deployment. Although Cisco's ACE can be cost prohibitive for some - there are other cheaper alternatives.
All in the Detail
My new job sucked a little time away from me at the start and now I am getting back on board with some nice new blog posts.
(This hot little blog is featured on @packetpushers website right now http://packetpushers.net/slow-down-its-in-the-details-a-story-of-bgp-peering-trauma )
Much like any exam and from what I hear the CCIE it's all about what is in the details. After a few short discussions and quite a few more emails with our ISP and account managers we were wanting to establish a BGP peering amongst sites. This is a private intra-site BGP peering leveraging the ISP's internal network. Nothing overally complex. Just a simple BGP peering. Outlined in the long email chain which all parties had was the ISP assigned ASNs and our assigned ASNs.
In the outage window we attempted to peer and saw the error below.
BGP: 192.168.10.54 open failed: Connection refused by remote host, open active delayed 14931ms (35000ms max, 60% jitter)
Initially thinking it was an ACL blocking port 179 or something along those lines we looked into it. After checking our end thoroughly and confirmed out configs were fine we then looked back to the ISP. ( I bet I am not the first to have to do this 
)
It ended up that the ISP configured our ASN on his router and didn't read their own supplied config diagram. The moment he changed his ASN, our peering came up and we had connectivity.
Other examples where this issue can appear are listed below
-
The neighbor statement is incorrect.
-
No routes to the neighbor address exist , or the default route (0.0.0.0/0) is being used to reach the peer.
-
The update-source command is missing under BGP.
-
A typing error resulted in the wrong IP address in the neighbor statement or the wrong autonomous system number. .
-
Unicast is broken due to one of the following reasons:
- Wrong virtual circuit (VC) mapping in an Asynchronous Transfer Mode (ATM)
or Frame Relay environment in a highly redundant network.
- Access list is blocking the unicast or TCP packet.
- Network Address Translation (NAT) is running on the router
and is translating the unicast packet.
- Layer 2 is down.
My learnings from this:
It goes to show the importance of reading all the information before running in with half a picture. I am of the strong believe that knowledge is power and allows you to make sound decisions. Slowing down and reading everyones input in this case would of meant a much smoother migration and things working the first time.
Multiple Tenant, Same Switch – Private VLANs
A private VLAN allows conservation of IP and VLANs via L2 separation within a VLAN. It allows web hosts and ISPs to segregate or group devices whilst conserving IP addressing. PVLANs restrict communication between ports and allow communication with promiscuous port. Think VLAN inside a VLAN!
Primary PVLAN
- Primary PVLAN can be composed of many secondary PVLANs. The secondary PVLANs belong to the same subnet as the Primary PVLAN. The primary VLAN has the task of also carrying data from the promiscuous port to the isolated, community, and other promiscuous ports in the same primary PVLAN.
Secondary PVLAN
- A child PVLAN to the primary PVLAN, a secondary PVLAN is mapped to a single primary PLVAN. Secondary PVLAN are what hosts attach to.
Types of Secondary PVLANs
- Community PVLANS
- Ports can communicate with other community members and the promiscuous port of the primary PVLAN
- Isolated Private VLAN
- Ports can only communicate with the promiscuous ports only.
NOTE: Promiscuous ports only service and work with one primary PVLAN. A promiscuous port can service one isolated PVLAN or many community PVLANs
PVLAN Port types
- Isolated
- Isolated ports are completely separated at L2 from any other ports except those listed as promiscuous. These ports block all traffic to other isolated ports. Traffic is forward to promiscuous ports only
- Servers, Hosts (Think web-hosting!)
- Promiscuous
- These ports communicated with all ports within a PVLAN including community and isolated ports. Promiscuous ports are apart of one primary PVLAN and each promiscuous port can map themselves to multiple secondary PVLANS.
- Routers, Shared Servers, SVIs, Routed Switch ports
- Community
- These ports communicate amongst themselves and their promiscuous ports. L2 communities are isolated from other communities and isolated ports within their PVLAN.
- Servers, Server Farms
Configuration of Private VLANs
The objective of this exercise is meet the requirements of a webhosting company. They have employed you to configure the following PVLAN setup for their tenants.
VLANs in your VLANs so you can isolate while you isolate
First of all we define the PVLAN Type. This allows us to assign which VLAN will be a primary, community or isolated PVLAN
vlan 50private-vlan primaryvlan 51private-vlan communityvlan 52private-vlan isolatedvlan 50private-vlan association 51,52
int gi0/10switchport mode private-vlan hostswitchport private-vlan host-association 50 51int gi0/11switchport mode private-vlan hostswitchport private-vlan host-association 50 51int gi0/12switchport mode private-vlan hostswitchport private-vlan host-association 50 52int gi0/13switchport mode private-vlan hostswitchport private-vlan host-association 50 52int gi0/15switchport mode private-vlan promiscuousswitchport private-vlan mapping 50 add 51,52
show vlan private-vlan typeVlan Type---- -----------------50 primary51 community52 isolatedshow vlan private-vlanPrimary Secondary Type Ports------- --------- ----------------- ------------------------------------------50 51 community Gi0/10, Gi0/11, Gi0/1550 52 isolated Gi0/12, Gi0/13, Gi0/15
Easy enough. I was always daunted by this topic but now after labbing it I have found it to be quite nice and easy. Also remember that this is a 3560 series and higher technology. Sorry 3550!
OSPF Part IV – Sticking it together
Today I will continue with my OSPF series and dive into some command line. I will hopefully gel together what we have touched on thus far and show off the OSPF database. Before we start I wanted to share some good news. I resigned from my currently employee about a week ago. I will be moving into a much faster pace, mission critical environment where redundancy is paramount in every single aspect. More will come as I get started (skill level is going to a sharp vertical climb) but for now lets continue with today's blog post.
I have slowly been introducing you to OSPF at this stage from a theory side and explained some of the basic concepts. Shortest Path First, OSPF Database and LSA's, and how neighbor adjacency forms. Today I will go through on the CLI and explain this further. Let's hope today we can put our theory into practice.
Understanding LSA's at the CLI will make you happy
So today we will start with a simple topology of two routers directly connected via a switch. Each device will have a loop back adapter with an IP address. Simple multi-area OSPF coupled with some honest to goodness OSPF routing. Below is the topology we are going to use.
Area 51....err. yeah..
Alright. Today we are going to achieve the following tasks. I will outline them first and then we shall progress through them.
- Assign IP addresses to interfaces and devices.
- Configure and Verify basic connectivity
- Configure and Verify Area 0 OSPF. Set the OSPF ID to 1.1.1.1 for R1 and 2.2.2.2 for R2.
- Configure and Verify multi-area OSPF.
Easy enough. Let's get started.
Task 1
Configure and Verify IP addressing
R1 interface Loopback0 description Lo0_A1 ip address 10.10.10.10 255.255.255.0 ! interface FastEthernet0/0 description LINK_TO_R2 ip address 192.168.1.1 255.255.255.0 R2 interface Loopback0 description Lo0_A0 ip address 20.20.20.20 255.255.255.0 ! interface FastEthernet0/0 description LINK_TO_R1 ip address 192.168.1.2 255.255.255.0
Task Two
Verify connectivity.
R1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 20/23/28 ms R1#sh ip arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.1.1 - c000.0dff.0000 ARPA FastEthernet0/0 Internet 192.168.1.2 0 c001.0dff.0000 ARPA FastEthernet0/0
The Initial lost ping is ARP doing it's thing.
Task Three
OSPF time. We are going to initially set router id's on each of the switches and enable OSPF on the 192.168.1.0/24 network for Area 0.
R1 router ospf 1 router-id 1.1.1.1 network 192.168.1.0 0.0.0.255 area 0 R2 router ospf 1 router-id 2.2.2.2 network 192.168.1.0 0.0.0.255 area 0
This simple configuration will broadly enable OSPF on each router. First thing to notice is that OSPF uses the wildcard mask. It is the inverse of the subnet mask. I do believe that this is a great concept and quite easily remember. How I remember the wildcard mask is in my head have 255.255.255.255 and subtract the subnet mask of the network.
Example
255.255.255.255 -255.255.255.0 ------------------- 0 . 0 . 0 . 255
Notice the neighbor relationship's now have come up. This is confirmed by what is printed by the logging,
R2 *Mar 1 01:31:07.599: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done R1 *Mar 1 01:31:07.907: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
Remember back to the previous piece that LSA's are generated and there were Router, Network and Summary. At this stage we should see Type 1 and 2 LSAs. Let's confirm this.
R2#sh ip ospf database OSPF Router with ID (2.2.2.2) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 100 0x80000001 0x003515 1 2.2.2.2 2.2.2.2 99 0x80000002 0x00F44B 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.1.2 2.2.2.2 99 0x80000001 0x0009B0 R1#sh ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 112 0x80000001 0x003515 1 2.2.2.2 2.2.2.2 113 0x80000002 0x00F44B 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.1.2 2.2.2.2 113 0x80000001 0x0009B0
Easy done! OSPF is running and sharing advertisements. You can see the Link ID which is the IP of the interface that is advertising the OSPF and the router-id being used for 2.2.2.2/1.1.1.1 respectively.
Task Three verified and complete
Task Four
Multi-Area OSPF
Now we come to the fun of OSPF. As mentioned prior, Area's can define branches, routing groups or physical portions of the network. The loopback we are adding to this network (simulating the 10.10.10.10.0 network in our case) will be assigned to Area 1.
router ospf 1 network 10.10.10.0 0.0.0.255 area 1
Simple yet subtle change can make all the difference. First of all let's check R2's routing table.
R2#sh ip route ospf 10.0.0.0/32 is subnetted, 1 subnets O IA 10.10.10.10 [110/11] via 192.168.1.1, 00:07:43, FastEthernet0/0
Look at that. O IA - OSPF inter area route. Just what we wanted. Now let's check out the LSA database of R2.
R2#sh ip ospf data summ
OSPF Router with ID (2.2.2.2) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 519
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.10.10.10 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xA768
Length: 28
Network Mask: /32
TOS: 0 Metric: 1
Notice the advertising router. Coming from R1. This is great. Now let's compare and confirm with the OSPF database on R1
OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 601 0x80000002 0x003612 1 2.2.2.2 2.2.2.2 623 0x80000003 0x00B528 2 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.1.2 2.2.2.2 1172 0x80000001 0x0009B0 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.10.10.10 1.1.1.1 597 0x80000001 0x00A768 Router Link States (Area 1) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 601 0x80000001 0x0007F9 1 Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 20.20.20.20 1.1.1.1 602 0x80000001 0x003E9F 192.168.1.0 1.1.1.1 604 0x80000001 0x0013B1
Here you can see that there is both areas. This router is an Area Border Router (ABR) and has an interface in each area. Notice there is database entries for each area. Take your time and get used to this.
This is a brief entry into OSPF but we will dig deeper as we get through this series.
I think I've opened a can of worms.
Who is this guy?
About Me- Network Engineer, blogger and CCIE wannabe. I am a guest blogger on PacketPushers, my own content here at blog.ciscoinferno.net and on Twitter @pandom_
Twitterfeed
- Labbed - Rootguard (with answer key) blog.ciscoinferno.net/lab-rootguard Try your hand at stabilizing your L2 topology today. 1 day ago
- RT @fetep: Four 9s is 4.32 minutes of downtime per (30 day) month. You will not reach four 9s if it takes 10 minutes to escalate an outage. 2 days ago
- Looking at Mi-Token 2FA and now looking at you @networkjanitor , @cooperlees 2 days ago