I figure it's easiest to show this as classless, as the same method works for classful.
Analyzing Existing Subnets:
How to determine subnet number?
The easiest way to find the subnet number, is to first convert the IP and subnet mask, and then AND the two together.
Example:
IP: 199.1.1.100
Subnet Mask: 255.255.255.224
If we were to convert the IP to binary, we would mostly be worried about the last octet, as this is where the "magic" happens.
01100100
11100000
The result of ANDing the two numbers is: 01100000, or 96.
Finding the broadcast IP?
Once you have your binary subnet number, change all of the host bit values in the subnet number to binary 1s. Using the above example, that would give us 01111111 or 127.
Thus, using the above example, we would have a range of 97-126 usable addresses in this particular subnet.
Another example:
Address: 130.4.102.1
Subnet mask: 255.255.252.0
Based on the following example, we are examining the 3rd octet.
102 in binary is...01100110 and 252 in binary is...11111100
ANDing the two numbers..
0 1 1 0 0 1 1 0
1 1 1 1 1 1 0 0
You have: 01100100 or a subnet number of 130.4.100.1 and a broadcast number of 130.4.103.255.
Using the same example, how can we have determined the number of subnets? To determine the number of subnets, use the formula:
Because we had as subnet mask of 255.255.252.0 or 6 subnet bits, we have potentially 64 subnets. The cool thing with this formula, is that we can also determine how many bits one must back to get a desired number of subnets.
Because we know that the subnet number is 130.4.100.1 and the subnetted portion is in the 3rd octet, we can also determine which subnet this subnet number is a part of! With the "strange" subnet mask portion being a value of 252, we can subtract it from our "magic" number 256. Subtracting the two numbers gives a result of 4. With the given subnet mask and IP address, the first non zero subnet would be 130.4.4.0. The above example, of 130.4.100.0 would then be 25th subnet in a series of 64 subnets!
Imagine your boss were to tell you: "We need a subnet for each printer VLAN." If you were to know that there were 20 printer VLANs, you would use the 20=2^s. Because it cannot exactly equal 20, we would need to mask 5 bits.
How can you then determine the number of hosts per subnet? Use the formula: number of hosts per subnet=2^h-2 with h being the number of host bits.
Example:
Given the IP address 192.168.10.0/26, provide all useful information (network ID, Subnet numbers, broadcast IPs, etc):
Take your address, and break it down into binary, with a focus on the "interesting part" of the subnet mask. A class C IP has a default subnet mask of 255.255.255.0. Because our provided subnet mask is 255.255.255.192, this is our "interesting octet", or part that isn't 255 or 0. To find your current subnet ID, simply write out the subnet mask & IP interesting octet in binary. In this case we have..
Subnet Mask: 1100000
IP: 0000000
This one is easy because the last octet is 0 (which you will learn to be the network ID). If it wasn't 0, you perform an AND, not add, but AND. Anyways, for this subnet, the subnet ID is the IP you listed. To find the number of subnets, the easiest way is to take the number 256-the number in the "interesting octet" of the subnet mask. 256-192=64.
Because we have two masked bits, we can determine that there are actually 4 subnets. The formula for this is 2^s, with s being the number of masked bits. 2^2=4
192.168.10.0 - Subnet ID
192.168.10.1 through 192.168.10.62 - Possible host addresses
192.168.10.1.63 - Broadcast IP (LAST possible IP before the next subnet ID)
192.168.10.64 - Subnet ID
192.168.10.65 through 192.168.10.126 - Possible host addresses
192.168.10.127 - Broadcast IP (LAST possible IP before the next subnet ID)
192.168.10.128 - Subnet ID
192.168.10.129 through 192.168.10.190 - Possible host addresses
192.168.10.191 - Broadcast IP (LAST possible IP before the next subnet ID)
192.168.10.192 - Subnet ID
192.168.10.193 through 192.168.10.254 - Possible host addresses
192.168.10.255 - Broadcast IP (LAST possible IP before the next subnet ID)
Sunday, November 13, 2011
Tuesday, November 8, 2011
Border Gateway Protocol (BGP)
Border Gateway Protocol (BGP) advertises, learns, and chooses the best paths inside the global Internet.
Some key points:
Because AS_Path can be used to choose the best route, over who has the shortest AS_PATH (Fewest number of ASNs listed), as each ASN advertises the routes they know about the AS_Path PA is manipulated. For example: As ASN1 tells ASN2 about prefix 192.X.X.X, the AS_Path is simply 1. When ASN2 tells ASN5 about the same prefix, the AS_Path is now 1,5. One thing worth noting, is that when routers share information within an AS (iBGP), the AS_Path PA does not change--only when passing between different ASNs (eBGP). Again, assuming no other PAs have been manipulated, BGP path selection uses the shortest AS_Path.
Routing loop prevention: Because each ASN includes its ASN when advertising a known prefix, it can prevent routing loops. If an ASN receives an update, and a route advertisement lists an AS_Path with its own ASN, the router ignores the route.
Because ASN numbers need to be unique, IANA administers the assignments of ASNs much like it does with IP address prefixes. If they were to assign two organizations the same ASN, and one were to advertise its prefix, the BGP update would be ignored as part of the BGP loop prevention process.
When to use BGP over static routes? Because having a default route is most beneficial when you have a single internet connection, once you have two, BGP allows you to choose one outbound path over another for particular destinations. The alternative? The ISP could configure static routes for the Enterprise's public IP addres prefix and then use BGP in the Internet to advertise those routes. Also, you could simply use a default static route pointing towards the core of the network. The WAN edge routers then need static routes for the subnets at each branch, with the WAN edge routers advertising these brange subnets into the core using an IGP.
Different cases of internet connectivity:
Requirements to form eBGP neighborships:
Step 2. E1 looks in the IP routing table for the route that matches destination 10.1.1.2
Step 3. Route matched in Step 2 lists S0/0/0 as outgoing interface
Step 4: Router A's interface IP address for S0/0/0 is 10.1.1.1, so Router A uses 10.1.1.1 as its source IP address for this BGP peer.
Step 5: The neighbor command on the other router, must refer to Router A's source IP address (10.1.1.1 in this case).
Because TCP uses a concept called a socket, which consists of a local TCP port number and an IP address, if the interface whose IP addres ised used by IP were to fail, then the TCP socket would fail, closing the TCP connection. Using the example above, if S0/0/0 were to fail, the devices would loose connectivity.
How to avoid this?! Configure a loopback interface as the source of their single BGP TCP connection. In the event that there are multiple links between the routers, and one interface were to fail, the loopback interface would remain up. To accomplish this, setup a loopback interface, then initiate the command neighbor... update-source <interface-id> command.
If you utilize the loopback interface as the source of the BGP TCP connection, you must also enable eBGP Multihop. The purpose for this is that when building packets to send to an eBGP peer, IOS defaults to a TTL value of 1. With a TTL value of 1, the packets will never arrive! While it seems as if a router 1 hop away should work fine with a TTL of 1, the internal IOS packet forwarding logic decrements the TTL before giving the packet to the loopback interface! For two devices directly connected, configuring the command neighbor ebgp-multihop 2 would solve this issue.
Keep in mind, because you are now using a loopback interface for BGP TCP connectivity, the two devices will no longer be "connected" and cannot realy on connected routes for forwarding packets. You would need to either configure an IGP or static routes for this to work.
How does the ISP learn routes for the Enterprise's public IP address space?
Some key points:
- Establishes a neighbor relationship before exchanging topology information with a neighbor router, like EIGRP and OSPF.
- Does not require neighbors to be attached to the same subnet (Uses TCP port 179), unlike EIGRP or OSPF.
- Uses path attributes, which will be described shortly, to determine the best route.
- Emphasis is on scalability, not fast convergence as EIGRP and OSPF are.
- Similar to distance vector
Because AS_Path can be used to choose the best route, over who has the shortest AS_PATH (Fewest number of ASNs listed), as each ASN advertises the routes they know about the AS_Path PA is manipulated. For example: As ASN1 tells ASN2 about prefix 192.X.X.X, the AS_Path is simply 1. When ASN2 tells ASN5 about the same prefix, the AS_Path is now 1,5. One thing worth noting, is that when routers share information within an AS (iBGP), the AS_Path PA does not change--only when passing between different ASNs (eBGP). Again, assuming no other PAs have been manipulated, BGP path selection uses the shortest AS_Path.
Routing loop prevention: Because each ASN includes its ASN when advertising a known prefix, it can prevent routing loops. If an ASN receives an update, and a route advertisement lists an AS_Path with its own ASN, the router ignores the route.
Because ASN numbers need to be unique, IANA administers the assignments of ASNs much like it does with IP address prefixes. If they were to assign two organizations the same ASN, and one were to advertise its prefix, the BGP update would be ignored as part of the BGP loop prevention process.
When to use BGP over static routes? Because having a default route is most beneficial when you have a single internet connection, once you have two, BGP allows you to choose one outbound path over another for particular destinations. The alternative? The ISP could configure static routes for the Enterprise's public IP addres prefix and then use BGP in the Internet to advertise those routes. Also, you could simply use a default static route pointing towards the core of the network. The WAN edge routers then need static routes for the subnets at each branch, with the WAN edge routers advertising these brange subnets into the core using an IGP.
Different cases of internet connectivity:
- Single Homed (1 link per ISP, 1 ISP)
- Single link between the enterprise and the ISP (only one possible next-hop router for any and all routes destined for the internet).
- Two options of implementing:
- Default routes on the inside, and static for the Enterprise's public address range at the ISP).
- Use BGP, but only to exchange a default and a route for the Enterprise's public prefix.
- ISP router uses BGP to advertise a default route to the enterprise..IGP configured on Enterprise internet-facing router to flood a default route..BGP configured on the Enterprise router and advertise the Enterprise's public prefix towards the ISP.
- Dual Homed (2+ links per ISP, 1 ISP)
- This option gives the enterprise a choice!
- Can manipulate EIGRP metrics or AD to create a preferred route.
- Manipulate BGP PAs to create a preferred route (soon to follow..)
- Single multihomed (1 link per ISP, 2+ ISP)
- Dual multihomed (2+ links per ISP, 2+ ISP)
Requirements to form eBGP neighborships:
- A local router's ASN must match the neighboring router's reference to that ASN with its neighbor remote-as <asn> command.
- The BGP router IDs of the two routers must NOT be the same
- How is the router ID chosen?
Like EIGRP and OSPF, BGP follows these steps to choose the router ID: Configured, highest loopback, highest other interface. The syntax to hardcode the router ID is bgp router-id <rid> - If configured, MD5 authentication must pass.
- Will fail if keys are incorrect, or if only one router configures authentication. Syntax to configure authentication is neighbor <neighbor IP> password <key>.
- An active TCP connection with the other router (read below for how this works..)
Step 2. E1 looks in the IP routing table for the route that matches destination 10.1.1.2
Step 3. Route matched in Step 2 lists S0/0/0 as outgoing interface
Step 4: Router A's interface IP address for S0/0/0 is 10.1.1.1, so Router A uses 10.1.1.1 as its source IP address for this BGP peer.
Step 5: The neighbor command on the other router, must refer to Router A's source IP address (10.1.1.1 in this case).
Because TCP uses a concept called a socket, which consists of a local TCP port number and an IP address, if the interface whose IP addres ised used by IP were to fail, then the TCP socket would fail, closing the TCP connection. Using the example above, if S0/0/0 were to fail, the devices would loose connectivity.
How to avoid this?! Configure a loopback interface as the source of their single BGP TCP connection. In the event that there are multiple links between the routers, and one interface were to fail, the loopback interface would remain up. To accomplish this, setup a loopback interface, then initiate the command neighbor... update-source <interface-id> command.
If you utilize the loopback interface as the source of the BGP TCP connection, you must also enable eBGP Multihop. The purpose for this is that when building packets to send to an eBGP peer, IOS defaults to a TTL value of 1. With a TTL value of 1, the packets will never arrive! While it seems as if a router 1 hop away should work fine with a TTL of 1, the internal IOS packet forwarding logic decrements the TTL before giving the packet to the loopback interface! For two devices directly connected, configuring the command neighbor ebgp-multihop 2 would solve this issue.
Keep in mind, because you are now using a loopback interface for BGP TCP connectivity, the two devices will no longer be "connected" and cannot realy on connected routes for forwarding packets. You would need to either configure an IGP or static routes for this to work.
How does the ISP learn routes for the Enterprise's public IP address space?
- Utilize the BGP network command
- The IGP network command, which lists paramaters that the router comapres to all its interface IP address, and if it finds a match the router enables the IGRP routing protocol on that particular interface. Unlike the IGP network command, BGP does not use the network command to enable BGP on interfaces. It adds a prefix to the BGP table only if the exact prefix with that same mask exists in a router's routing table. If a router does not have a route for an entire range (which is possible if that range has been subnetted), you can use a static route pointing towards null0. When implementing the network <IP> mask <subnet mask>, if you omit the subnet mask, IOS will assume a classful network mask.
- WTF is BGP auto-summary? Unlike EIGRP, BGP defaults to no auto-summary. If auto-summary is enabled, it will change how we interpret the network command listed above. With auto-summary enabled, the router will add a route to the BGP table if the exact classful route is in the IP routing table, or if any subset routes of that classful network are int he routing table. For instance, if you used the network 9.0.0.0 command and auto-summary were enabled, and if only a subset route exists (like 9.1.1.0/24) , but no route for exactly 9.0.0.0/8 were present, then the router still adds a route for the classful network to the BGP table.
- Redistribute from an IGP
Monday, November 7, 2011
Policy-Based Routing
Policy-Based Routing (PBR) intercepts a packet after de-encapsulation (data link header and trailer discarded) on the incoming interface, before the router performs the CEF table look up.
PBR chooses how to forward the packet by using matching logic defined through a route map, which in turns typically refers to an IP ACL. When matched, the route map also defines the forwarding instructions, which may include the next-hop IP address or outgoing interface.
To match packets, you have two options:
Well, this parameter tells IOS whether to apply PBR logic BEFORE trying to use normal destination-based routing, or whether to first try to use the normal destination-based routing, relying on PBR's logic only if the destination-based routing logic fails to match a nondefault route.
For example, without the default parameter if client X is told to use router X as the next-hop, and router X is down, to try and use the normal destination-based IP routing process. But if the default parameter is enabled, the router will try to route the packet as normal, but if no nondefault route matches the destination, the the router forwards the packet as directed in the set command.
Finally, once a route-map has been configured with all the clauses to match packets, the only remaining step requires the ip policy route-map <route-map name> command to enable PBR for packets entering an interface.
So far, it seems as the easiest way to make this make sense is to work Left->Right. Imagine the packet entering the interface on which the policy based routing will be configured. While PBR primarily routes packets recieved on an interface, there are additional PBR functions.
This feature measures the ongoing behavior of the network. IP SLA tools, such as Cisco Works Internetwork Performance Monitor (IPM), can be used to monitor data to determine whether the business SLAs were met based on gathered statistics. All othe SLA opertions rely on the router sending packets and some device sending packets back. By configuring a pre-exhisting device as an IP SLA responder, it gives the network engineer a way to monitor network behavior without having to place devices around the network just to test the network.
PBR chooses how to forward the packet by using matching logic defined through a route map, which in turns typically refers to an IP ACL. When matched, the route map also defines the forwarding instructions, which may include the next-hop IP address or outgoing interface.
To match packets, you have two options:
- Use your stand match statement, match ip address. This command can reference standard and extended ACLs.
- Specify a range of lengths, in bytes, via the match length command.
- Forward to the first address in the list for which the associated interface is up, via the set ip next hop <ip address>
- Forward to the first address in the list for which the associated interface is up, except policy routing first attempts to route based on the routing table, via the set ip default next-hop <ip address>
- Forward packets using the first interface in the list that is up, via the set interface <interface-type interface-number>
- Forward packets using the first interface in the list that is up, except policy routing first attempts to route based on the routing table, via the set default interface <interface-type interface-number>
Well, this parameter tells IOS whether to apply PBR logic BEFORE trying to use normal destination-based routing, or whether to first try to use the normal destination-based routing, relying on PBR's logic only if the destination-based routing logic fails to match a nondefault route.
For example, without the default parameter if client X is told to use router X as the next-hop, and router X is down, to try and use the normal destination-based IP routing process. But if the default parameter is enabled, the router will try to route the packet as normal, but if no nondefault route matches the destination, the the router forwards the packet as directed in the set command.
Finally, once a route-map has been configured with all the clauses to match packets, the only remaining step requires the ip policy route-map <route-map name> command to enable PBR for packets entering an interface.
So far, it seems as the easiest way to make this make sense is to work Left->Right. Imagine the packet entering the interface on which the policy based routing will be configured. While PBR primarily routes packets recieved on an interface, there are additional PBR functions.
- Applying PBR to locally created packets: Because you cannot implement the normal configuration, because the packet is not entering the device, you would use the ip local policy route-map <name> global command.
- Setting IP Precedence: While this particular method of implementing QoS is outdated, you can use PBR to set older QoS marking field -- the IP Precedence (IPP) and the entire ToS byte.
- PBR with IP SLA: If the IP SLA tool measures the network's current performance, and the performance does not meet the defined threshold, PBR chooses to not use a particular route.
This feature measures the ongoing behavior of the network. IP SLA tools, such as Cisco Works Internetwork Performance Monitor (IPM), can be used to monitor data to determine whether the business SLAs were met based on gathered statistics. All othe SLA opertions rely on the router sending packets and some device sending packets back. By configuring a pre-exhisting device as an IP SLA responder, it gives the network engineer a way to monitor network behavior without having to place devices around the network just to test the network.
Redistribution / Using multiple Routing protocols
Reason for redistribution?
Because the topology tables (map of the network) may vary between different routing protocols, the redistribution process uses the one table that both routing protocols understand: the IP routing table. By performing the redistribution commands, you are essentially pulling routes from one routing protocol, and putting them into another. Like EIGRP, OSPF treats the redistributed routes as external routes. OSPF creates an LSA to represent each redistributed subnet - normally a Type 5 LSA (See my OSPF section for information of LSA types). Also, aside from passing routes learned via the routing protocol, the redistribution command also passes information on connected routes on interfaces enabled with that routing protocol.
Redistribution into EIGRP:
Syntax: redistribute <protocol> <process id / as-number> <metric> <match> <tag> <route-map (value)>
How do you put routing protocol X into EIGRP? You would first go under the EIGRP routing protocol, via the router eigrp <process id> and then perform the above command. A better command name might have been "take-routes-from," because the first parameter after the command tells IOS from where to get the routes.
Things to remember:
EIGRP does not have a default setting for the metric components to use when redistributing into EIGRP from OSPF. To successfully redistribute OSPF routes into EIGRP, you need to use the metric <bw delay reliability load mtu> in conjunction with the redistribute command to redistribute all routes by a single redistribute command. You can use the same synax, but use default-metric <bw delay reliability load mtu> to set the default for all redistribute commands.
Redistribution into OSPF:
Like redistributing into EIGRP, OSPF flags redistributed routes as external. Unlike EIGRP, OSPF creates LSAs to represent each external route. By default, the OSPF redistribute command creates Type 2 routes.
Syntax: redistribute <protocol> <process id / as-number> <metric> <match> <tag> <route-map (value) <subnets>
The main difference one might notice about the syntax, is with regards to the <subnets> portion. By default, when redistributing into OSPF, it only redistributes classful (class A, B, and C) networks, and not routes for subnets. By omitting the subnets parameter, OSPF will only redistribute routes for entire classful subnets, and only if such a route is listed in the IP routing table. For example, if no route exists for the EXACT class B network prefix of 172.30.0.0/16, OSPF will not redistribute any subnets inside that range. By including the subnets prefix, it would redistribute the subnets.
Dealing with the external routes...
When the external route is created, the ASBR floods the Type 5 LSA throughout the area. Then, if any ABRs exist, the ABRs flood the Type 5 LSA into any normal (nonstubby) areas. Because the Type 5 LSA is defaulted to a Type 2 route (E2), the route's metric is simply the metric listed in the Type 5 LSA. While this makes cost calculations easy, it makes it difficult to calculate the best path. For example, if you have 2 possible routes, with one being the obvious winner and one requiring multiple hops, the cost for both routes would be the same, as they are both external. When a router finds multiple routes for the same E2 destination subnet, it chooses the best route based on the lowest cost to reach any ASBR(s) that advertised the lowest E2 metric. The method for choosing the best route is as follows:
1. Find the advertising ASBR(s) as listed in the type 5 LSA(s) for Type 5 LSA(s).
2. Calculate the lowest cost route to reach any of the ASBR(s) based on the intra-area LSDB topology.
3 Use the outgoing interface and net hop based on the best route to reach the ASBR.
4. The route's metric is unchanged--it is still simply the value listed in the Type 5 LSA.
Now what if the router exists in a different area than the ASBR? If a router finds multiple routes to reach a single E2 subnet, some or all may tie based on metric, because the metric is based solely on the external cost as defined by the ASBR. A router then chooses the best route based on the least-cost route to reach an ASBR that has advertised the lowest E2 cost for the subnet.
The steps are as follows:
1. Calculate the cost to reach the ABR, based on the local area's topology database.
2. Add the cost from the ABR to the ASBR, as listed in a Type 4 LSA.
ABRs create this new type of LSA -- The Type 4 LSA -- to support the logic mentioned in step 2. The Type 4 LSA lists the RID of the ASBR, and the RID of the ABR that created and flooded the Type 4 LSA. Most importantly, the Type 4 LSA lists that ABR's cost to reach the ASBR.
E2 routes work well when the design needs to choose the best route based on the external metric. OSPF routers calculate the metric of E1 routes by adding the internal cost to reach the ASBR to the external cost defined on the redistributing ASBR. One can influence the route-type by using the metric-type 1 value in the redistribution command. For routers in a different area than the ASBR, the calculation of metric follows the same general logic used when breaking E2 routes. Generally, the computation adds three items:
How does redistribution work if using NSSA areas?!
Being that you cannot redistribute routes into stubby or totally stubby areas (don't allow type 5 LSAs), you can redistribute into Not-so-stubby-areas (NSSAs).
Using the above example, the ASBR attached to the NSSA area 1 redistributes a route for subnet 1, creating a Type 7 LSA. The ASBR then proceeds to flood the Type 7 LSA throughout NSSA area 1. When ABR1 receives the Type 7 LSA, it converts it to a Type 5 LSA when forwarding into other areas!
And then things get real...
First off, lets take a look at the administrative distance table:
Administrative Distance (AD) is the measure used by Cisco routers to select the best path to a destination when there are more than one route to the same destination from two different routing protocols. By default, you would prefer the path that has the lowest administrative distance. For example: If you know a route to subnet 10.16.1.0 through both (internal) EIGRP and OSPF, you would prefer the EIGRP route (assuming default AD settings). These administrative distance costs can be changed / adjusted so to make one path preferred over another.
Issue that can happen with redistribution:
Given the following example, you have two routers performing redistribution, which is considered to be the minimum in regards to redistribution design. Because we have two distribution routers, routing loops can occur. As seen in the image, Subnet X is advertised to RD2 as both an internal EIGRP as well as an external OSPF route. With regards to redistributing between EIGRP and OSPF, the default AD settings as mentioned above prevent said loops. When RD2 considers the internal EIGRP route as the best route, because of the lower AD, and places that route in its own IP routing table. RD2 does not further mess it up by redistributing subnet x BACK into EIGRP because RD2 does not have an OSPF route for subnet X..wew!
What about when its reversed? Given the same example, but with a subnet Y being advertised from within the OSPF domain? EIGRPs default AD saves us again! Subnet X would work the same was as the example above, and when subnet Y works its way around...RD1 would prefer the route from OSPF over the external EIGRP route! The default AD for an external EIGRP route is 170, which is obviously higher than the internal OSPF AD of 110..wew!
Time for things to get messed up...RIP!
Because RIP does not have a concept of internal and external routes; the proceding references refer to internal routes as routes that exisite inside the RIP domain, and external as routes that exist outside the RIP domain. Because RIP does not have a default AD setting to defeat the domain loop problem, the different routing protocols have the ability to override the default AD.
To change the default AD values..
RIP: distance <ad-value>
EIGRP: distance eigrp <internal-ad external-ad>
OSPF: distance eigrp (external) <ad-value> (intra-area) <value> (inter-area) <value>
To defeat the OSPF-RIP domain loop problem by setting AD, just configure the AD for OSPF external routes. The AD value doesn't matter much, but it should be higher than RIP's AD on that same router.
Yay, we solved domain loops!!...wait a second..
Check this out..
With the given example, R9 advertises a route for 172.20.0.0/16 into the EIGRP domain with an AD of 170 as an external route. RD1 redistributes this EIGRP external route into the OSPF domain as a E2 external route, with an AD of 110, by default. RD2 uses the AD 110 E2 route, rather than the EIGRP external route, as its best route for 172.20.0.0/16. As a result, RD2 can then redistribute that OSPF route back into EIGRP as an external route. R4 learns of two external routes for 172.20.0.0/16, and the routes tie based on RD (170). R4 may have a better EIGRP metric through RD2, depending ont he metrics used in redistribution, preferring this long route through the OSPF domain as shown.
How could we solve an issue like this? One solution would be to cause RD2 to use a higher AD--specifically higher than the 170 AD used for EIGRP external routes--for prefix 172.20.0.0/16 as learned with OSPF. To do this, we can use an access list to match the 172.20.0.0/16 prefix!
RD2(config)# router ospf 2
RD2(config-router)# distance 171 1.1.1.1 0.0.0.0 match-172-20
RD2(config-router)# ip access-list standard match-172-20
RD2(config-std-nacl)# permit host 172.20.0.0
What we essentially did, was tell OSPF to look for LSAs owned by RID 1.1.1.1 (RD1's RID), and if the prefix is permited by the match-172-20 ACL, apply AD 171 to this route. So instead of preferring the external OSPF value of 110, it is made to believe that R1 is advertising a cost of 171 to reach 172.20.0.0/16. Because the AD is increased, RD1 now prefers its AD 170 EIGRP route for 172.20.0.0/16.
Worth noting..when using the distance command with RIP or EIGRP, the distance matches the interface IP address of the neighboring router that advertises the route.
Preventing Domain Loops by Filtering on route-tag Using Distribution Lists
A route tags is a unitless 32-bit integer that most routing protocols can assign to any given route. Route tags can be assigned by a route-map referenced by a routing protocol distribution list or redistribute command. The route tag allows other IOS tools to match routes to make a decision. It is essentially the equivalent of a post it note on a route. Using the figure above as an example, we could tag traffic coming into RD1, while denying the tagged traffic incoming into RD2 through the use of route-maps, while permitting everything else. The configuration to accomplish something like that...
R1:
router ospf 2
router-id 3.3.3.3
log-adjacency-changes
redistribute eigrp 1 subnets route-map set-tag-11
network 172.30.0.0 0.0.255.255 area 0
roure-map set-tag-11 permit 10
set tag 11
R2:
Router eigrp 1
redistribute ospf 2 metric 1000 200 255 1 1500 route-map stop-tag-11
network 172.16.0.0
no auto summary
route-map stop-tag-11 deny 10
match tag 11
route-map stop-tag-11 permit 20
- Mergers when different internal gateway protocols (IGPs) are used.
- Mergers when the same IGP is used. (Example: Two companies both use EIGRP, but different AS numbers. Redistribution is a useful immediate fix, until all former company's routers are migrated to use the same ASN as the first company.)
- Momentum (Enterprise has been using multiple routing protocols a long time.)
- Connections between partners
Because the topology tables (map of the network) may vary between different routing protocols, the redistribution process uses the one table that both routing protocols understand: the IP routing table. By performing the redistribution commands, you are essentially pulling routes from one routing protocol, and putting them into another. Like EIGRP, OSPF treats the redistributed routes as external routes. OSPF creates an LSA to represent each redistributed subnet - normally a Type 5 LSA (See my OSPF section for information of LSA types). Also, aside from passing routes learned via the routing protocol, the redistribution command also passes information on connected routes on interfaces enabled with that routing protocol.
Redistribution into EIGRP:
Syntax: redistribute <protocol> <process id / as-number> <metric> <match> <tag> <route-map (value)>
How do you put routing protocol X into EIGRP? You would first go under the EIGRP routing protocol, via the router eigrp <process id> and then perform the above command. A better command name might have been "take-routes-from," because the first parameter after the command tells IOS from where to get the routes.
Things to remember:
EIGRP does not have a default setting for the metric components to use when redistributing into EIGRP from OSPF. To successfully redistribute OSPF routes into EIGRP, you need to use the metric <bw delay reliability load mtu> in conjunction with the redistribute command to redistribute all routes by a single redistribute command. You can use the same synax, but use default-metric <bw delay reliability load mtu> to set the default for all redistribute commands.
Redistribution into OSPF:
Like redistributing into EIGRP, OSPF flags redistributed routes as external. Unlike EIGRP, OSPF creates LSAs to represent each external route. By default, the OSPF redistribute command creates Type 2 routes.
Syntax: redistribute <protocol> <process id / as-number> <metric> <match> <tag> <route-map (value) <subnets>
The main difference one might notice about the syntax, is with regards to the <subnets> portion. By default, when redistributing into OSPF, it only redistributes classful (class A, B, and C) networks, and not routes for subnets. By omitting the subnets parameter, OSPF will only redistribute routes for entire classful subnets, and only if such a route is listed in the IP routing table. For example, if no route exists for the EXACT class B network prefix of 172.30.0.0/16, OSPF will not redistribute any subnets inside that range. By including the subnets prefix, it would redistribute the subnets.
Dealing with the external routes...
When the external route is created, the ASBR floods the Type 5 LSA throughout the area. Then, if any ABRs exist, the ABRs flood the Type 5 LSA into any normal (nonstubby) areas. Because the Type 5 LSA is defaulted to a Type 2 route (E2), the route's metric is simply the metric listed in the Type 5 LSA. While this makes cost calculations easy, it makes it difficult to calculate the best path. For example, if you have 2 possible routes, with one being the obvious winner and one requiring multiple hops, the cost for both routes would be the same, as they are both external. When a router finds multiple routes for the same E2 destination subnet, it chooses the best route based on the lowest cost to reach any ASBR(s) that advertised the lowest E2 metric. The method for choosing the best route is as follows:
1. Find the advertising ASBR(s) as listed in the type 5 LSA(s) for Type 5 LSA(s).
2. Calculate the lowest cost route to reach any of the ASBR(s) based on the intra-area LSDB topology.
3 Use the outgoing interface and net hop based on the best route to reach the ASBR.
4. The route's metric is unchanged--it is still simply the value listed in the Type 5 LSA.
Now what if the router exists in a different area than the ASBR? If a router finds multiple routes to reach a single E2 subnet, some or all may tie based on metric, because the metric is based solely on the external cost as defined by the ASBR. A router then chooses the best route based on the least-cost route to reach an ASBR that has advertised the lowest E2 cost for the subnet.
The steps are as follows:
1. Calculate the cost to reach the ABR, based on the local area's topology database.
2. Add the cost from the ABR to the ASBR, as listed in a Type 4 LSA.
ABRs create this new type of LSA -- The Type 4 LSA -- to support the logic mentioned in step 2. The Type 4 LSA lists the RID of the ASBR, and the RID of the ABR that created and flooded the Type 4 LSA. Most importantly, the Type 4 LSA lists that ABR's cost to reach the ASBR.
E2 routes work well when the design needs to choose the best route based on the external metric. OSPF routers calculate the metric of E1 routes by adding the internal cost to reach the ASBR to the external cost defined on the redistributing ASBR. One can influence the route-type by using the metric-type 1 value in the redistribution command. For routers in a different area than the ASBR, the calculation of metric follows the same general logic used when breaking E2 routes. Generally, the computation adds three items:
- The best intra-area cost to reach the ABR (per that area's LSDB)
- The cost from the ABR to the ASBR (Per Type 4 LSA)
- The external cost for the route (Per Type 5 LSA)
How does redistribution work if using NSSA areas?!
Being that you cannot redistribute routes into stubby or totally stubby areas (don't allow type 5 LSAs), you can redistribute into Not-so-stubby-areas (NSSAs).
Using the above example, the ASBR attached to the NSSA area 1 redistributes a route for subnet 1, creating a Type 7 LSA. The ASBR then proceeds to flood the Type 7 LSA throughout NSSA area 1. When ABR1 receives the Type 7 LSA, it converts it to a Type 5 LSA when forwarding into other areas!
And then things get real...
First off, lets take a look at the administrative distance table:
Administrative Distance (AD) is the measure used by Cisco routers to select the best path to a destination when there are more than one route to the same destination from two different routing protocols. By default, you would prefer the path that has the lowest administrative distance. For example: If you know a route to subnet 10.16.1.0 through both (internal) EIGRP and OSPF, you would prefer the EIGRP route (assuming default AD settings). These administrative distance costs can be changed / adjusted so to make one path preferred over another.
Issue that can happen with redistribution:
Given the following example, you have two routers performing redistribution, which is considered to be the minimum in regards to redistribution design. Because we have two distribution routers, routing loops can occur. As seen in the image, Subnet X is advertised to RD2 as both an internal EIGRP as well as an external OSPF route. With regards to redistributing between EIGRP and OSPF, the default AD settings as mentioned above prevent said loops. When RD2 considers the internal EIGRP route as the best route, because of the lower AD, and places that route in its own IP routing table. RD2 does not further mess it up by redistributing subnet x BACK into EIGRP because RD2 does not have an OSPF route for subnet X..wew!
What about when its reversed? Given the same example, but with a subnet Y being advertised from within the OSPF domain? EIGRPs default AD saves us again! Subnet X would work the same was as the example above, and when subnet Y works its way around...RD1 would prefer the route from OSPF over the external EIGRP route! The default AD for an external EIGRP route is 170, which is obviously higher than the internal OSPF AD of 110..wew!
Time for things to get messed up...RIP!
Because RIP does not have a concept of internal and external routes; the proceding references refer to internal routes as routes that exisite inside the RIP domain, and external as routes that exist outside the RIP domain. Because RIP does not have a default AD setting to defeat the domain loop problem, the different routing protocols have the ability to override the default AD.
To change the default AD values..
RIP: distance <ad-value>
EIGRP: distance eigrp <internal-ad external-ad>
OSPF: distance eigrp (external) <ad-value> (intra-area) <value> (inter-area) <value>
To defeat the OSPF-RIP domain loop problem by setting AD, just configure the AD for OSPF external routes. The AD value doesn't matter much, but it should be higher than RIP's AD on that same router.
Yay, we solved domain loops!!...wait a second..
Check this out..
With the given example, R9 advertises a route for 172.20.0.0/16 into the EIGRP domain with an AD of 170 as an external route. RD1 redistributes this EIGRP external route into the OSPF domain as a E2 external route, with an AD of 110, by default. RD2 uses the AD 110 E2 route, rather than the EIGRP external route, as its best route for 172.20.0.0/16. As a result, RD2 can then redistribute that OSPF route back into EIGRP as an external route. R4 learns of two external routes for 172.20.0.0/16, and the routes tie based on RD (170). R4 may have a better EIGRP metric through RD2, depending ont he metrics used in redistribution, preferring this long route through the OSPF domain as shown.
How could we solve an issue like this? One solution would be to cause RD2 to use a higher AD--specifically higher than the 170 AD used for EIGRP external routes--for prefix 172.20.0.0/16 as learned with OSPF. To do this, we can use an access list to match the 172.20.0.0/16 prefix!
RD2(config)# router ospf 2
RD2(config-router)# distance 171 1.1.1.1 0.0.0.0 match-172-20
RD2(config-router)# ip access-list standard match-172-20
RD2(config-std-nacl)# permit host 172.20.0.0
What we essentially did, was tell OSPF to look for LSAs owned by RID 1.1.1.1 (RD1's RID), and if the prefix is permited by the match-172-20 ACL, apply AD 171 to this route. So instead of preferring the external OSPF value of 110, it is made to believe that R1 is advertising a cost of 171 to reach 172.20.0.0/16. Because the AD is increased, RD1 now prefers its AD 170 EIGRP route for 172.20.0.0/16.
Worth noting..when using the distance command with RIP or EIGRP, the distance matches the interface IP address of the neighboring router that advertises the route.
Preventing Domain Loops by Filtering on route-tag Using Distribution Lists
A route tags is a unitless 32-bit integer that most routing protocols can assign to any given route. Route tags can be assigned by a route-map referenced by a routing protocol distribution list or redistribute command. The route tag allows other IOS tools to match routes to make a decision. It is essentially the equivalent of a post it note on a route. Using the figure above as an example, we could tag traffic coming into RD1, while denying the tagged traffic incoming into RD2 through the use of route-maps, while permitting everything else. The configuration to accomplish something like that...
R1:
router ospf 2
router-id 3.3.3.3
log-adjacency-changes
redistribute eigrp 1 subnets route-map set-tag-11
network 172.30.0.0 0.0.255.255 area 0
roure-map set-tag-11 permit 10
set tag 11
R2:
Router eigrp 1
redistribute ospf 2 metric 1000 200 255 1 1500 route-map stop-tag-11
network 172.16.0.0
no auto summary
route-map stop-tag-11 deny 10
match tag 11
route-map stop-tag-11 permit 20
Wednesday, November 2, 2011
Route Filtering (ACLs / Prefix lists / Route Maps)
I figure the best way to do this is to write out about using ACLs, prefix lists, and route maps (advantages, disadvantages, differences, etc).
Why do we even need these technologies one might ask? The above technologies are useful for route filtering, which reduces the size of routing tables, saving memory, improves router performance, and makes the internetwork more secure by limiting the flow of packets. By using distribution lists, we can classify whether a route should be permitted to be sent or received (filtered). We can also specify the direction and optionally, the specific interface on which the filter updates.
Filtering using ACLs:
ACL must match a route with a permit clause for the route to be advertised, and match with a deny clause for the route to be filtered. To apply the filter, you use the distribution-list <acl#> <direction> <interface> command. If you were to have multiple sub-interfaces, then you would need to apply the distribution list to each and ever sub-interface. You could also apply the distribution-list <acl#> <direction> command, without specifying the particular interface. Not specifying the interface would cause it to implement the distribution-list on every interface.
Filtering using IP Prefix Lists:
IP Prefix lists can examine both the prefix and the prefix length, and a range of prefixes or a range of prefix lengths. To implement with prefix lists, you use the same distribute-list command, but referencing the created prefix list. The main advantage of using prefix lists over ACLs are that IP prefix lists allow matching of prefix length, where ACLs cannot. Also, the internal processing of the IP prefix lists uses an internal tree structure that results in faster matching of routes as compared to ACLs. IP prefix lists provide mechanisms to match two components of an IP route: The route prefix (subnet number) and prefix length (subnet mask). Like the permit or deny keywords just imply whether a route is matched (permit) or not (deny). Also unlike ACLs, IP prefix lengths examine the prefix length as well.
There are 4 prefix list parameters:
Neither: configured length must equal route-length
(Example: ip prefix-list fred deny 10.0.0.0/8 matches 10.0.0.0/8, but not 10.0.0.0/20)
Both ge and le: ge-value<=route-length<=le-value
(Example: ip prefix-list fred deny 10.0.0.0/8 ge 20 le 22 matches 10.0.0.0/20, but not 10.0.0.0/23)
Only le: config-length<=route-length<=le-value
(Example: ip prefix-list fred deny 10.0.0.0/8 le 20 matches 10.0.0.0/19, but not 10.0.0.0/21)
Only ge: ge-value<=route-length<=32
(Example: ip prefix-list fred deny 10.0.0.0/8 ge 20 matches 10.0.0.0/21, but not 10.0.0.0/18)
Filtering using Route Maps:
Route-maps, the third route filtering tool that can be referenced with the distribute-list command, provides programming logic with if/than/else like capabilities. Route maps can also be used to filter routes during the redistribution process, and to set BGP path attributes (PAs) for the purpose of influencing the choice of the best routes in an internetwork.
The syntax for setting up route maps are as follows:
set <action> (In the case with distribution lists, we would leave out the set parameter, as it is not needed to filter routes).
The match portion is where this can get a bit confusing...say you have the following scenario:
route-map sample-rm permit10
match ip access-list 2
access-list 2 deny 10.17.32.0 0.0.31.255
distribute-list route-map sample out
Should the particular route be permitted per the route-map, or denied per the access-list? In the case of route maps using access lists and prefix lists, if the access list is a deny, then the match statement is not fulfilled. Basically, by having a deny in the ACL or prefix list, the IOS then consider the next route-map command!
Note: To match all packets, simply omit the match command from the route-map configuration.
Why do we even need these technologies one might ask? The above technologies are useful for route filtering, which reduces the size of routing tables, saving memory, improves router performance, and makes the internetwork more secure by limiting the flow of packets. By using distribution lists, we can classify whether a route should be permitted to be sent or received (filtered). We can also specify the direction and optionally, the specific interface on which the filter updates.
Filtering using ACLs:
ACL must match a route with a permit clause for the route to be advertised, and match with a deny clause for the route to be filtered. To apply the filter, you use the distribution-list <acl#> <direction> <interface> command. If you were to have multiple sub-interfaces, then you would need to apply the distribution list to each and ever sub-interface. You could also apply the distribution-list <acl#> <direction> command, without specifying the particular interface. Not specifying the interface would cause it to implement the distribution-list on every interface.
Filtering using IP Prefix Lists:
IP Prefix lists can examine both the prefix and the prefix length, and a range of prefixes or a range of prefix lengths. To implement with prefix lists, you use the same distribute-list command, but referencing the created prefix list. The main advantage of using prefix lists over ACLs are that IP prefix lists allow matching of prefix length, where ACLs cannot. Also, the internal processing of the IP prefix lists uses an internal tree structure that results in faster matching of routes as compared to ACLs. IP prefix lists provide mechanisms to match two components of an IP route: The route prefix (subnet number) and prefix length (subnet mask). Like the permit or deny keywords just imply whether a route is matched (permit) or not (deny). Also unlike ACLs, IP prefix lengths examine the prefix length as well.
There are 4 prefix list parameters:
Neither: configured length must equal route-length
(Example: ip prefix-list fred deny 10.0.0.0/8 matches 10.0.0.0/8, but not 10.0.0.0/20)
Both ge and le: ge-value<=route-length<=le-value
(Example: ip prefix-list fred deny 10.0.0.0/8 ge 20 le 22 matches 10.0.0.0/20, but not 10.0.0.0/23)
Only le: config-length<=route-length<=le-value
(Example: ip prefix-list fred deny 10.0.0.0/8 le 20 matches 10.0.0.0/19, but not 10.0.0.0/21)
Only ge: ge-value<=route-length<=32
(Example: ip prefix-list fred deny 10.0.0.0/8 ge 20 matches 10.0.0.0/21, but not 10.0.0.0/18)
Filtering using Route Maps:
Route-maps, the third route filtering tool that can be referenced with the distribute-list command, provides programming logic with if/than/else like capabilities. Route maps can also be used to filter routes during the redistribution process, and to set BGP path attributes (PAs) for the purpose of influencing the choice of the best routes in an internetwork.
The syntax for setting up route maps are as follows:
route-map <route-map name> <deny/permit> <sequence#>
match <criteria> (The criteria field can be left blank, this would match all)set <action> (In the case with distribution lists, we would leave out the set parameter, as it is not needed to filter routes).
The match portion is where this can get a bit confusing...say you have the following scenario:
route-map sample-rm permit10
match ip access-list 2
access-list 2 deny 10.17.32.0 0.0.31.255
distribute-list route-map sample out
Should the particular route be permitted per the route-map, or denied per the access-list? In the case of route maps using access lists and prefix lists, if the access list is a deny, then the match statement is not fulfilled. Basically, by having a deny in the ACL or prefix list, the IOS then consider the next route-map command!
- Route-map commands with the permit option either cause a route to be allowed through (if matched by the match command) or remain in the list of routes to be examined by the next route-map clause.
- Route-map commands with the deny option either filter the route (if matched by the match command) or leave the route in the list of routes to be examined by the next route-map clause)
- If a clause's match command refer to an ACL or prefix list, and the ACL or prefix list matches a route map with the deny action, the route is not necessarily filtered. Instead, it just means that the route does not match that particular match command and can then be considered by the next route-map clause.
- The route-map command includes an implied deny all clause at the end; to configure a permit all use the route-map command, with a permit action, but without the match command.
Note: To match all packets, simply omit the match command from the route-map configuration.
Routing Protocols: OSPF
OSPF:
- One of the types of link state (only other is IS-IS)
- Topology tables contains “entire roadmap” where routing table is the “best routes”
- Link-state routers don’t just know what their neighbors know; they have a roadmap for the entire area.
- Only disadvantage is very processor intensive.
- Send triggered updates to announce network changes
- Link-state refresh (once every 30 mins, will send out full topology to make sure nothing was missed)
- Network divided into multiple areas, with a group of routers.
- All areas must connect to area 0 (backbone)
- All routers in an area have the same topology table
- Goal is to localize updates within an area
- Router ID only changes when OSPF router reboots, or OSPF process is restarted. Cisco recommends hard coding the router ID to prevent issues. For example, a loopback is set and a year later the router is restarted. To prevent the confusion, if the router ID is hardcoded, a reset won’t matter.
- Hello messages sent every 10 seconds on broadcast / point to point networks
- Hello messages sent ever 30 seconds on NBMA networks (Frame relay, ATM)
- Dead timer is 4x hello message timer
- Two routers must have same: Authentication password, hello and dead timers, area ID, and network mask in order to become neighbors.
- States…
- Received hello message from R1, R2 in “init” state
- Router sends initial hello messages, but still waiting on a response back – “Down state”
- If goes from init to down, repeatedly, check the necessary parameters
- R2 sends hello back, R1 sees itself in neighbor table, put in “two-way” state
- Every time a hello message is received, will updated dead timer. If dead timer exceeds 40 seconds (default), neighbor relationship is torn down.
- “Exstart state” Exchanging of link state databases, master slave relationship.
- Master sends database descriptions (DBD) to slaves, which is a summarization of the link state database. The slave will also send a DBD back to the master, so they can compare to see what the slave does not know. During this process, their states will show as, “Loading State.” Here they load the information into memory, to determine what they need. In this process, they will go down the list, requesting details (beginning with the slave), and this is called a link-state request. “OH I don’t know that, need information!!” The master will respond back with the requested details (known as a link-state update). Once the slave has been updated, the master will send out its own LSR’s if necessary.
- Once both devices have the same link-state database, the neighbors will be at a “full state” All routers attached to DR should be the only ones showing as “full” whereas every other router show ld show as “two-way”
- DRs & BDR are used to reduce network traffic. Link updates sent to DR versus sending update to all neighbors.
- 224.0.0.6 multicast address for all OSPF devices, 224.0.0.5 used for DRs & BDRs (with shared network segments)
- One DR/BDR for ever shared segment
- Point to point links, uses 224.0.0.5 address
- DR / BDR chosen by…(highest to lowest importance & no other elections until either the DR or BDR fail)
- Router priority
- Router ID
- Link-state advertisements (LSA) are updates about individual routes. (Link state updates contain individual link state advertisements)
- Link-state acknowledgement (LSACK) is a transport layer protocol used to acknowledge everything sent between routers (no TCP in OSPF). With the use of LSACK, OSPF if considered to have reliable transport (similar to TCP).
- Router-id <#> from within OSPF sub command to define router ID
- E1 routes (increment metric), E2 routes (do not increment meric-default)
- Redistribute static subnets metric-type<1 or 2> metric <#> (configures E2) with a metric of 200
- Clear ip ospf processes – resets ospf process, tears down neighbors
- Ip ospf network point-to-point -- tricks OSPF into thinking loopback as not a loopback /24 instead of /32
- Sh ip ospf interface – used to show DR / BDR status, and other ospf info on device.
- Sh ip ospf neighbor - shows neighbor devices DR / BDR status.
- Ip ospf priority – used to configure priority numbers, higher # means DR. IF set to 0, the device will not become DR / BDR.
- Area <area #> range <summary address + subnet mask> method of summarization for OSPF
- Summary-address <summary address + subnet mask> method of summarization for ASBR (when communicating with non ospf networks, that do not understand areas.
- Cost = 100/bandwidth in mbps (cannot accurately determine cost for higher costs) Use auto-cost reference-bandwidth <whatevs> changes the default 100
- OSPF Network Types:
- Broadcast / Multi-access networks
- Example: Ethernet, Token Ring
- Single operation mode – walk into any network, should work.
- DR/BDR election, 10 sec hellos, dual multicast add
- Point-to-point networks
- Example: T1 CAS, ISDN BRI/PRI
- Single operation mode
- No DR/BDR, 10 sec hellos, single multicast add (2
- Non Broadcast Multi-access (NBMA) networks
- Example: Frame Relay, ATM
- 30 second hellos
- Five modes of operation
- Non-broadcast (RFC standard)
- Default mode for X.25, FR, ATM
- Neighbors statistically configured
- Neighbor <remote ip> priority <priority value>
- Must be one subnet
- Acts like a lan environment
- DR/BDR elected, must be fully connected
- Point-to-multipoint (RFC standard)
- Fixes issues with NBMA networks
- Requires single subnet (advantage)
- No DR/BDR elected
- Neighbors automatically form (IF pseudo broadcasts allowed)
- Point-to-point (Cisco proprietary)(Like point to point, without NBMA)
- Uses separate sub interfaces
- Requires diff subnets (Disadvantage, wastes addresses)
- No DR/BDR elected
- Neighbors automatically form
- Broadcast (Cisco proprietary)
- Like Ethernet over a cloud
- Form DR/BDR
- Point-to-multipoint, non-broadcast (Cisco proprietary)
- Fixes issues with NBMA networks
- Requires single subnet
- No DR/BDR elected
- Similar to point-to-multipoint, but neighbors do not auto form, must be configured statically.
- Ip ospf hello-interval <configured hello interval> - configures hello / dead timer so that NBMA can communicate with other devices.
- Virtual links are useful to make things work until you can fix it.
- Area <area> virtual-link <remote ID> - Used to create a virtual link (perform on device attached to area 0 (also on router connected to virtual link)
- Sh ip ospf virtual-link – Displays virtual links
- OSPF LSA types:
- Type 1: Router LSA
- The LSDB for one area contains one Type 1 LSA per router per area.
- ABRs create multiple Type 1 LSAs for themselves: one per area.
- Type 2: Network LSA (DR generated)
- Routes attached to same switch / subnet
- Type 3: Summary LSA (ABR summary route)
- ABR that passes routes from one area to another
- ABRs do not forward Type 1 and Type 2 LSAs from one area into another area
- ABRs generate a Type 3 LSA for each subnet in one area, and advertise each Type 3 LSA into the other areas.
- Used to model interarea routes
- Type 4: Summary LSA (ASBR summary route)
- Identifies ASBR
- Type 5: External LSA (ASBR summary route)
- Created when ASBR sends external routes into OSPF domain
- Type 7: Used in stub areas in place of a type 5 LSA
- Types of areas:
- Stubby area: Blocks type 5 LSAs from entering
- Under ospf configuration, use command area <area #> stub
- Totally stubby: Blocks type 3,4, and 5 LSAs from entering (Cisco proprietary)
- Under ospf configuration, use command area <area#> stub no-summary
- Not-so-stubby-area: Passes external routes through via type 7 LSA; these convert back to type 5 once they reach the backbone.
- Under ospf configuration, use command area <area#> nssa
- Passive-interface <interface> within OSPF config, will keep hello updates from being sent.
- Can use passive-interface default to turn on passive-interface on all interfaces of the router.
- Area <area #> authentication message-digest – configures authentication for OSPF, with this method it requires all routers in <area#> to have authentication turned on. Cannot enter keys, simply verifies md5 enabled. Better method is to turn authentication on interface by interface, and enter keys in that way.
- Ip ospf authentication message-digest – turns on md5 authentication
- Ip ospf authentication message-digest-key <key ID> md5 <key name> -- turns on md5 authentication for a particular interface.
- Ip ospf authentication – turns on clear text authentication
- Ip ospf authentication-key <key name> - configures key name for clear text authentication
- Debug ip ospf adj – Command used to display ospf neighbor relationship changes, and useful for troubleshooting OSPF authentication issues
- Area <area> stub – co nfigured under ospf configuration
- Area <area#> default-cost <cost number> - Sets initial cost of X
Routing Protocols: EIGRP
EIGRP
Advanced EIGRP:
- Fastest to converge (backup routes / goodbye messages)
- Easiest to configure
- Proprietary to CISCO
- Default Hello time of 5 seconds, and Hold of 15
- Only protocol that holds backup routes (DUAL)
- Feasible successor kept in topology table, and brought into routing table if successor route goes down.
- Unequal cost load balancing
- Considered distance vector (only knows what neighbor tells it), with attributes of link state.
- “TO BE CONSIDERED A FEASIBLE SUCCESSOR, THE AD MUST BE LESS THAN THE FD OF THE SUCCESSOR.”
- Active / Passive routes:
- Active: Actively trying to find a backup
- Passive: Good / working / no actions happening.
- Metric calculation:
- BW=10^7 / BW
- Delay= delay in microseconds
- Metric=256(Slowest BW+ total delay)
- Sh ip eigrp topology command: shows successors / feasible successor routes
- Ip default-network (similar to default information originate like in OSPF) used to advertise default route in EIGRP (HAS TO BE CLASSFUL). Another method is to create a static route as 0.0.0.0 and advertise through EIGRP.
- Passive-interface <interface> within eigrp config, will keep hello updates from being sent.
- Can use passive-interface default to turn on passive-interface on all interfaces of the router.
- Ip summary-address eigrp <AS #> <IP> <netmask> Used to summarize routes (sub interface command)
- Always choose more specific route than any summarized route (even if using RIP over EIGRP, etc.)
- Variance <number> command used to load balance. Number is used to determine how packets are routed. Example: will load balance across links that are 2 times as bad as my primary, if using variance 2. Looking at feasible distance of successor / feasible successors, we can see which routes will be used (if fits under multiplier).
Advanced EIGRP:
- Multipoint=same subnet, point to point=diff subnets
- NBMA (Non-Broadcast Multiple access) used in place of broadcasts
- Int s0/0.1 multipoint=used to create multipoint sub interface
- Frame-relay map ip <distance ip> <local DLCI> broadcast
- If use “neighbor “ command, disables multicast (neighbors cannot auto form)
- Split Horizon is a feature EIGRP uses to prevent routing loops. It prevents loops by not accepting routes on the same interface that a router sends updates out. This can be useful, but can also keep your network from functioning as intended.
- If frame relay is configured on a physical interface, auto disables split horizon. But with sub-interfaces, split horizon is enabled.
- Only advantage of multipoint is saving of IP addresses (only need to configure one subnet, whereas point to point are on different subnets. But other than that, point to point is more advantageous (no split horizon issues).
- No ip split-horizon eigrp <AS#> used to disable split horizon (useful in multipoint frame relay networks.) (used on interface subcommand)
- Within interface subcommand, ip summary-address eigrp <as #> <summary ip address> Summary routes sent over particular interface.
- Ip bandwidth-percent eigrp <AS#> <percentage> percentage rate to which one would increase to (PERFORMED FROM INTERFACE SUBCOMMAND). Default is 50% (limited interface bandwidth, then divided by number of neighbors) 100kbps with 2 neighbors is only 25kbps per neighbor (50% of 100kbps divided between two neighbors)
- Important to use NTP to keep time intervals correct.
- From global config, key chain <name> . Use key <number> to create keys. From within the key interface, can use key-string <key-string#> to give the keys a string names. Accept-lifetime <time day month year> <end time day month year (or infinite)> Send-lifetime <time day month year> <end time day month year (or infinite)>
- To turn on EIGRP authentication: go into interface, ip authentication mode eigrp <AS#> md5 (EIGRP ONLY USES MD5)
- Ip authentication key-chain eigrp 25 <keychain name> on each neighbor device
- Debug eigrp packet is a useful tool to test authentication process.
- Eigrp stub (used to label stub routers as a stub (helps with query process)
- K value (bandwith, delay, reliability, load, MTU) used to calculate EIGRP metric. If any K value differences, cannot create neighbor relationship
- Graceful shutdown (goodbye message): When anything done to affect EIGRP neighbor process, one final hello packet sent, setting K-values to 255
- Depending on IOS version; OLD=K-value mismatch, NEW=Goodbye received
- Once goodbye message received on neighbor device, neighbor will automatically start looking for a backup route, instead of waiting on hold down timer to expire, meaning quicker convergence.
Tuesday, November 1, 2011
Layer 2 switch operation (How the MAC address table is populated)
After using my previous post, "New device connects to a network..what's next?" one might be curious that how Client A, with a newly assigned IP address communicates with the rest of the network. In a switching environment, a switch must first learn what devices hang off which interface. The way the switch "learns" this is by passing traffic. Initially, a switch knows nothing of the devices hanging off its interfaces. Therefore, when a frame is received that is destined for a MAC address unknown to the switch, the switch broadcasts the request out of every interface (except the one from which the frame entered). First off, using the example from the Cisco press book, we can see that PC1 is trying to communicate with the server:
When SW1 receives the frame on Gi0/1 destined for an unknown MAC address, it floods out the frame out every other interface and adds PC1's MAC address of AAAA.AAAA.AAAA to the MAC address table (with exception to Gi0/4, because the interface is in a different VLAN). When SW2 receives the broadcast, it first associates PC1's MAC address of AAAA.AAAA.AAAA to Gi0/1, being that it is the interface on which PC1's frame entered. Upon receiving the broadcast, SW2 also broadcasts the request out of every other interface. When the Server receives the broadcast, it responds back with an ARP reply. Unlike the ARP request, the server responds via a unicast to PC1 with a destination MAC address of AAAA.AAAA.AAAA. When SW2 receives the ARP reply, it adds an entry for MAC address BBBB.BBBB.BBBB to its MAC address table, and forwards it out Gi0/1. When Switch 1 receives the ARP reply, it adds BBBB.BBBB.BBBB to its MAC address table, off of Gi0/2. Finally, because Switch 1 knows the interface to reach AAAA.AAAA.AAAA, Switch 1 forwards the ARP reply out of interface Gi0/1. Because PC1 knows the MAC address for the Server, PC1 can now normally connect to the server.
When SW1 receives the frame on Gi0/1 destined for an unknown MAC address, it floods out the frame out every other interface and adds PC1's MAC address of AAAA.AAAA.AAAA to the MAC address table (with exception to Gi0/4, because the interface is in a different VLAN). When SW2 receives the broadcast, it first associates PC1's MAC address of AAAA.AAAA.AAAA to Gi0/1, being that it is the interface on which PC1's frame entered. Upon receiving the broadcast, SW2 also broadcasts the request out of every other interface. When the Server receives the broadcast, it responds back with an ARP reply. Unlike the ARP request, the server responds via a unicast to PC1 with a destination MAC address of AAAA.AAAA.AAAA. When SW2 receives the ARP reply, it adds an entry for MAC address BBBB.BBBB.BBBB to its MAC address table, and forwards it out Gi0/1. When Switch 1 receives the ARP reply, it adds BBBB.BBBB.BBBB to its MAC address table, off of Gi0/2. Finally, because Switch 1 knows the interface to reach AAAA.AAAA.AAAA, Switch 1 forwards the ARP reply out of interface Gi0/1. Because PC1 knows the MAC address for the Server, PC1 can now normally connect to the server.
New device connects to a network..what's next?
The following case is if the IP address is not statically assigned:
Now where this can become confusing, is when the DHCP server does not reside on the same subnet as the requesting client. Obviously, if you were to have multiple subnets, having a DHCP server on every subnet becomes impractical. To overcome this, we can use IP helper-addresses to essentially tell the forwarding router where the DHCP server resides. Because DHCP clients use BOOTP packets that are broadcasted to all hosts(255.255.255.255) and it will be all dropped by the router. The "ip helper-address" command makes the router to forward BOOTP broadcast packets to the specific remote DHCP server.
In regards to the example on the left, we would need to implement the IP helper-address on Router A, because the subnet on which the DHCP server sits is on a different subnet, essentially invisible to the DHCP client.
Subscribe to:
Posts (Atom)