So between work and packing for a move and trying to study, I finally finished the OSPF section of the INE workbook. This covered quite a bit of the OSPF configuration and so I got a few lessons learned that bit me in the butt or things that I feel I need to remember.
When enabling OSPF on an interface with secondary addresses, the secondary is auto-magically added to OSPF unless the command ip ospf <proc-id> area <area> secondaries none is given.
I also learned that I have to get it through my thick head that the default OSPF network type for DMVPN is point-to-point. That works for when you only have one peer but let's be real. If have only one endpoint, then why would you use DMVPN? The network type needs to be changed on each site, hub and spoke, to another type.
So, we all know about DR elections and how they basically work but what about the time that it takes for the election to complete. That time is not configurable with an OSPF specific command but is equal to the dead time. So if the test says make the election process to complete in 3 seconds, make the dead time 3 seconds and WHAMMO. Just remember to do this on all the neighbors on that segment so that relationships form.
When using the P2P network type, there are not Type 2 LSAs that are sent. The Type-1 LSAs include both the network segment and the information about the neighboring OSPF router.
When using P2MP non-broadcast, there is nothing in the output of show ip ospf interface or show ip ospf interface brief that shows that it is non-broadcast. Difference can be seen in the debug output when unicast packets are send to the configured neighbors.
If you are trying to use bandwidth to manipulate routes, change the bandwidth on the interface that is in the opposite area on the ABR. This will change the metric since it will be used for calculations when the LSA is sent into the desired area.
With capability transit on by default, a router with a virtual-link does not have to use the virtual-link if the router has another path that is shorter (smaller metric). Turning this off, forces the router to use the virtual-link path. In the case of the land that I just did, there were three routers on the segment. Two of them had virtual-links to each other. The object was to force the router that had to have the virtual-link to not use the shorter path through the third router. By default, since capability transit was on, the router always picked it since it advertised a smaller metric. After turning off capability transit, the router would route to the other side of the virtual-link first and that router would then router to the third router. Basically, it created inefficient routing but was able to show the capability.
To suppress hellos, you can use the P2P network type and combine that with deman circuit functionality to suppress pacing and aging. Makes for a quiet OSPF process. It must be huntin' wabbits.
I had a lab where I had to configure multiple keys on an interface for MD5 authentication on the hub router. The routers using key 1 would not come up. Debugging showed that the router was not sending key 1. I had to remove the key and re-add it to all the needed routers and then I cleared the process. After that, all the routers came up. Only thing that I can think of is that my code hiccuped.
I tried to do SHA authentication on IOS 15.2(4)S, IOU/L 15.3(1)3T, and IOU/L 15.4(1)T. I could only use it on the 15.4 code. Great fun there. Also with SHA, HMAC-SHA-256 is the only version specified in the RFC. Wouldn't surprise me if they say on the test use the version of SHA that is in RFC 5709. Another interesting fact about SHA. It cannot be used on virtual-links. Have to stick with good ole MD5 there.
When using the area range command, the area ID that the command asks for is the area where the routes are being summarized from. This is not the area ID that is being summarized to.
NSSA Type-7 translation is done by default by the router with the highest router-id that connects to area 0 from the NSSA area.
The area filter-list command has in and out options. With the in optio, it applies the prefix-list to the area with routes coming from other areas. With the out option, it applies the filter to routes coming from the specified area to all other areas on the router.
Distribute-lists for OSPF only affect the local routing table and not the OSPF database. The same can be seen with the distance comamnd.
When using route-maps with distribute-lists, the filtering is only on traffic coming in and only for the local routing table. If does not affect the OSPF database in any way.
I need to pay more attention to the command line line listing for distribute-list when looking at it on Cisco's web page. It has again bit me in the buttocks when I looked at it for route-maps. The syntax is
distribute-list {{access-list-name | access-list-number | gateway prefix-list-name | prefix prefix-list-name [gateway prefix-list-name]} in [interface-type interface-number] | route-map route-map-name in}
When using the summary-address command with not-advertise, it will not only filter the route from the routing table as it goes out but it will also remove it from the local database. This means that it won't get advertised to the router neighbors. This functionality is done on external routes being translated at an ABR from the NSSA area. The route will still show up as a Type-7 (NSSA External) in the database of the NSSA routers.
The database filter option filters all LSAs going to a specific neighbor or out of a specific interface. It still allows relationships to form and LSAs to come in from neighbors but none are sent to the neighbor or out the interface.
24 June 2014
16 June 2014
INE EIGRP Part 2
Well, it took me a while to finish the EIGRP section of INE. With work, travel, and everything else, it took a lot longer for me to finish this section than I really wanted. Well, on to the fun that is EIGRP.
This section really wasn't that bad. I go a lot of it configured without many problems. There were a couple of gotchas. First off was dealing with setting the metric weights. In EIGRP normal mode, we all know that there are 5 k values. With EIGRP, there are 6 k values which I have talked about before. These k values deal with the EIGRP Wide Metrics that I have talked about before. So to use only delay for EIGRP standard mode, you would use the command
metric weight 0 0 0 1 0 0
When doing the same thing in EIGRP Named Mode, the command becomes
metric weight 0 0 0 1 0 0 0
This sixth value covers the extended attributes that are available.
My next gotcha is that I forgot that EIGRP hello and hold timers don't have to match. This is unlike OSPF. EIGRP hold time is also used to tell the neighbors how long to wait for a hello. It is not how long the local router will wait for a hello. The hold time is transmitted in EIGRP packets to the neighbors.
So now that the 15 code is being used, there are slight differences that are being seen. One is the stub command in EIGRP has been replaced with eigrp stub. Woo-hoo!! Something new to remember.
I also came across an interesting little pitfall. The AD for EIGRP internal routes can be changed on a per-prefix basis while external EIGRP routes cannot. This is something that I got from the INE workbook and is something worth remembering as well. That would mean you would use the distance command for EIGRP and set the external AD but it would be for all external routes.
For troubleshooting, INE gives you a little piece of help. When there is a duplicate EIGRP router-id, use either debug eigrp fsm or show ip eigrp events | include Ignored. These two commands will show if there is a duplicate from the point of view of the local router.
Well, EIGRP and RIP are done. Next is OSPF. Hopefully I can knock that out soon.
This section really wasn't that bad. I go a lot of it configured without many problems. There were a couple of gotchas. First off was dealing with setting the metric weights. In EIGRP normal mode, we all know that there are 5 k values. With EIGRP, there are 6 k values which I have talked about before. These k values deal with the EIGRP Wide Metrics that I have talked about before. So to use only delay for EIGRP standard mode, you would use the command
metric weight 0 0 0 1 0 0
When doing the same thing in EIGRP Named Mode, the command becomes
metric weight 0 0 0 1 0 0 0
This sixth value covers the extended attributes that are available.
My next gotcha is that I forgot that EIGRP hello and hold timers don't have to match. This is unlike OSPF. EIGRP hold time is also used to tell the neighbors how long to wait for a hello. It is not how long the local router will wait for a hello. The hold time is transmitted in EIGRP packets to the neighbors.
So now that the 15 code is being used, there are slight differences that are being seen. One is the stub command in EIGRP has been replaced with eigrp stub. Woo-hoo!! Something new to remember.
I also came across an interesting little pitfall. The AD for EIGRP internal routes can be changed on a per-prefix basis while external EIGRP routes cannot. This is something that I got from the INE workbook and is something worth remembering as well. That would mean you would use the distance command for EIGRP and set the external AD but it would be for all external routes.
For troubleshooting, INE gives you a little piece of help. When there is a duplicate EIGRP router-id, use either debug eigrp fsm or show ip eigrp events | include Ignored. These two commands will show if there is a duplicate from the point of view of the local router.
Well, EIGRP and RIP are done. Next is OSPF. Hopefully I can knock that out soon.
08 June 2014
EIGRP Part 1
Between studying for an Aruba wireless test and studying for my CCIE, time just gets away from me. Anyways, life goes on. I have been working on the INE workbook for EIGRP. I made it through some of the labs and most of it I have gotten right. There were a few gotchas. Feel pretty good thus far with it.
We all pretty much know what split horizon is and what it does. I know from the v4 test that you have to make sure that it was off when doing frame. Now that frame is off the blueprint, they still make you turn it off and this time with EIGRP. Not a gotcha there but an interesting. No matter the interface, split horizon is on by default. Tunnel, fast ethernet, whatever. Good to know.
Another thing that is default and this is recent to the 15 code is auto-summary is turned off. Thank goodness. Now to use it, which is rare, you have to explicitly turn it on. Hmm... A possible trouble ticket?
EIGRP now uses something called EIGRP Wide Metrics. This is where the metric is now 64 bits to accommodate super fast interfaces, such as a 10Gb or more. Gives better granularity over the metric for better routing. According to Cisco, the impact of using wide metrics is minimal except on DMVPN large scale deployments. There may be an impact there. Also, only bandwidth and delay are on and used for metric calculation by default, just like the regular metric. The delay on bandwidth that is below one gigabit is set to picoseconds and not microseconds and bandwidth above one gigabit uses a computed delay. There are two new values that can be used for metric calculation as well and they are accumulative jitter and energy and they are enabled with K6.
To use EIGRP Wide Metrics, you just have to run the 15 code. The routers will talk and if they all support the new metric, then away they go. If not, they fall back. Also, in a PE/CE environment, wide metrics will not be used and will used scaled attributes only. Also all routers that wish to use wide metrics have to use EIGRP Release 8.0 or higher. To see what version you are running, use the command show eigrp plugins as shown below from a router in my lab.
R1#show eigrp plugins
EIGRP feature plugins:::
eigrp-release : 11.00.00 : Portable EIGRP Release
: 1.00.19 : Source Component Release(rel11)
parser : 2.02.00 : EIGRP Parser Support
igrp2 : 2.00.00 : Reliable Transport/Dual Database
bfd : 2.00.00 : BFD Platform Support
mtr : 1.00.01 : Multi-Topology Routing(MTR)
eigrp-pfr : 1.00.01 : Performance Routing Support
EVN/vNets : 1.00.00 : Easy Virtual Network (EVN/vNets)
ipv4-af : 2.01.01 : Routing Protocol Support
ipv4-sf : 1.02.00 : Service Distribution Support
vNets-parse : 1.00.00 : EIGRP vNets Parse Support
ipv6-af : 2.01.01 : Routing Protocol Support
ipv6-sf : 2.01.00 : Service Distribution Support
snmp-agent : 2.00.00 : SNMP/SNMPv2 Agent Support
Authentication in EIGRP is something that I remember since learning about EIGRP and it has always been MD5. With the addition of Named Mode and the 15 code, there is now SHA 256 available. It has to done in Named Mode and it does not support the used of key chains but it is there for your use.
Speaking of Named Mode, I have to remember to use the address-family when trying to look at anything in EIGRP. Bit me in the behind a couple of times. For example, the following command is if you wanted to see the EIGRP detailed information about gi0/0.146.
show eigrp address-family ipv4 100 interfaces detail gi0/0.146
I love neighbor commands because that is like real life in that I want to know who the heck is around me at all times. Little paranoid I guess. When using neighbor commands on a tunnel interface for say DMVPN, you have to define all the neighbors. If you don't, it will drop all the others and they will not be able to register with that device. And when you are defining that neighbor, don't forget the interface that neighbor should come in on.
I hate, I repeat, HATE redistribution. For some reason, I always forget some stupid little thing and it blows my whole dag-nabbed thing up. Whether it is distance or filtering or some trivial garbage, it rarely works like anyone wants for me. Basic redistribution is fine. Fancy stuff kills me each time. But that is not the purpose here. The purpose here is to remind that the redistribution command in Named Mode falls under the topology base section.
So the last section that I did was on route summarization with poisoning. I remember in the 12 code, you could add 255 to the end of a summary-route and it would block the Null0 from being added to the routing table. No more. Now, you have to add the command summary-metric to the routing process along with the summary-route to the interface. Reading the command reference for the command, I like the command overall. It stops all recalculations for the route on each interface when a metric variable changes and makes them all standard for the ones that match the route in the command. I guess that I can also see the use of it for the distance section so that it applies to all the interfaces with the summary-route. What if you want finer granularity with this interface doing this and that one doing that? Hmm.. May need to look into that. The way the lab had it was confusing at first but was a great way to show how the command can be used to filter a route from being advertised. Not bad overall.
Well, that is it for now. Need to finish the next section.
We all pretty much know what split horizon is and what it does. I know from the v4 test that you have to make sure that it was off when doing frame. Now that frame is off the blueprint, they still make you turn it off and this time with EIGRP. Not a gotcha there but an interesting. No matter the interface, split horizon is on by default. Tunnel, fast ethernet, whatever. Good to know.
Another thing that is default and this is recent to the 15 code is auto-summary is turned off. Thank goodness. Now to use it, which is rare, you have to explicitly turn it on. Hmm... A possible trouble ticket?
EIGRP now uses something called EIGRP Wide Metrics. This is where the metric is now 64 bits to accommodate super fast interfaces, such as a 10Gb or more. Gives better granularity over the metric for better routing. According to Cisco, the impact of using wide metrics is minimal except on DMVPN large scale deployments. There may be an impact there. Also, only bandwidth and delay are on and used for metric calculation by default, just like the regular metric. The delay on bandwidth that is below one gigabit is set to picoseconds and not microseconds and bandwidth above one gigabit uses a computed delay. There are two new values that can be used for metric calculation as well and they are accumulative jitter and energy and they are enabled with K6.
To use EIGRP Wide Metrics, you just have to run the 15 code. The routers will talk and if they all support the new metric, then away they go. If not, they fall back. Also, in a PE/CE environment, wide metrics will not be used and will used scaled attributes only. Also all routers that wish to use wide metrics have to use EIGRP Release 8.0 or higher. To see what version you are running, use the command show eigrp plugins as shown below from a router in my lab.
R1#show eigrp plugins
EIGRP feature plugins:::
eigrp-release : 11.00.00 : Portable EIGRP Release
: 1.00.19 : Source Component Release(rel11)
parser : 2.02.00 : EIGRP Parser Support
igrp2 : 2.00.00 : Reliable Transport/Dual Database
bfd : 2.00.00 : BFD Platform Support
mtr : 1.00.01 : Multi-Topology Routing(MTR)
eigrp-pfr : 1.00.01 : Performance Routing Support
EVN/vNets : 1.00.00 : Easy Virtual Network (EVN/vNets)
ipv4-af : 2.01.01 : Routing Protocol Support
ipv4-sf : 1.02.00 : Service Distribution Support
vNets-parse : 1.00.00 : EIGRP vNets Parse Support
ipv6-af : 2.01.01 : Routing Protocol Support
ipv6-sf : 2.01.00 : Service Distribution Support
snmp-agent : 2.00.00 : SNMP/SNMPv2 Agent Support
Authentication in EIGRP is something that I remember since learning about EIGRP and it has always been MD5. With the addition of Named Mode and the 15 code, there is now SHA 256 available. It has to done in Named Mode and it does not support the used of key chains but it is there for your use.
Speaking of Named Mode, I have to remember to use the address-family when trying to look at anything in EIGRP. Bit me in the behind a couple of times. For example, the following command is if you wanted to see the EIGRP detailed information about gi0/0.146.
show eigrp address-family ipv4 100 interfaces detail gi0/0.146
I love neighbor commands because that is like real life in that I want to know who the heck is around me at all times. Little paranoid I guess. When using neighbor commands on a tunnel interface for say DMVPN, you have to define all the neighbors. If you don't, it will drop all the others and they will not be able to register with that device. And when you are defining that neighbor, don't forget the interface that neighbor should come in on.
I hate, I repeat, HATE redistribution. For some reason, I always forget some stupid little thing and it blows my whole dag-nabbed thing up. Whether it is distance or filtering or some trivial garbage, it rarely works like anyone wants for me. Basic redistribution is fine. Fancy stuff kills me each time. But that is not the purpose here. The purpose here is to remind that the redistribution command in Named Mode falls under the topology base section.
So the last section that I did was on route summarization with poisoning. I remember in the 12 code, you could add 255 to the end of a summary-route and it would block the Null0 from being added to the routing table. No more. Now, you have to add the command summary-metric to the routing process along with the summary-route to the interface. Reading the command reference for the command, I like the command overall. It stops all recalculations for the route on each interface when a metric variable changes and makes them all standard for the ones that match the route in the command. I guess that I can also see the use of it for the distance section so that it applies to all the interfaces with the summary-route. What if you want finer granularity with this interface doing this and that one doing that? Hmm.. May need to look into that. The way the lab had it was confusing at first but was a great way to show how the command can be used to filter a route from being advertised. Not bad overall.
Well, that is it for now. Need to finish the next section.
03 June 2014
EIGRP Wide Metrics
I was going through the EIGRP section of INE's v5 workbook and was doing the EIGRP Named Mode section. They started talking about EIGRP Wide metrics and I had to go and figure this out. A quick Google search came back with a white paper from Cisco that was talking about now that bandwidth is getting to be high (10 gig in places), metrics have to be adjusted to support this. Cisco came up with Wide Metrics which, and I am paraphrasing from my quick reading, that it is where they now can go into greater detail about the metrics and also where they add two new metrics.
More detail, you say? How? So they expanded the metric fields for namely bandwidth and delay. This way bandwidth, which is still measured in Kb, is greater and allows for higher speeds. Delay is measured in picoseconds on one gigabit links or less and it is scaled on links greater than one gigabit since the delay is harder to calculate. Both of these together will help an engineer to further refine their routing plan within their network.
Now for the two newly added metrics. These are accumulative jitter and accumulative energy. Really, I don't see these being used that much but in case some crazy person does want to, they are activated by activating K6.
Another cool fact about this new metric "type" is that the routers can all send both metrics to their peers. This can hog some bandwidth but on normal links this won't kill them and still allow the links to carry other traffic. On large-scale DMVPN networks, Cisco says that this can be a problem and may need to be looked at or just run the same metric type on all the routers. If the routers all support Wide Metrics, then they will all use them and skip the classic style. Cool, interesting fact.
Let's now say you are running EIGRP in a PE/CE situation. Because of the redistribution that will be happening, Wide Metrics are not used. Thought that was good to know for when someone asks. Which will probably be never.
To use Wide Metrics, Cisco says to use IOS or IOS XE and either one had to support EIGRP Release 8.0 or higher. I am running IOS 15.2(4)S3 in my lab so they all picked up the new type with no problem. To check the release that you are running, use the command show eigrp plugins. As you can see below my IOS is running 11.0.
R1#show eigrp plugins
EIGRP feature plugins:::
eigrp-release : 11.00.00 : Portable EIGRP Release
: 1.00.19 : Source Component Release(rel11)
parser : 2.02.00 : EIGRP Parser Support
igrp2 : 2.00.00 : Reliable Transport/Dual Database
bfd : 2.00.00 : BFD Platform Support
mtr : 1.00.01 : Multi-Topology Routing(MTR)
eigrp-pfr : 1.00.01 : Performance Routing Support
EVN/vNets : 1.00.00 : Easy Virtual Network (EVN/vNets)
ipv4-af : 2.01.01 : Routing Protocol Support
ipv4-sf : 1.02.00 : Service Distribution Support
vNets-parse : 1.00.00 : EIGRP vNets Parse Support
ipv6-af : 2.01.01 : Routing Protocol Support
ipv6-sf : 2.01.00 : Service Distribution Support
snmp-agent : 2.00.00 : SNMP/SNMPv2 Agent Support
So, this is all fine and dandy, but what does this all mean to me when I am troubleshooting. To find out, let's look at a route from my network.
R1#show eigrp address-family ipv4 100 topology 150.1.2.2/32
EIGRP-IPv4 VR(MULTI-AF) Topology Entry for AS(100)/ID(150.1.1.1) for 150.1.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 10485841920, RIB is 81920640
Descriptor Blocks:
155.1.0.5 (Tunnel0), from 155.1.0.5, Send flag is 0x0
Composite metric is (10485841920/7209041920), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 60001250000 picoseconds
Reliability is 255/255
Load is 2/255
Minimum MTU is 1400
Hop count is 2
Originating router is 150.1.2.2
155.1.13.3 (GigabitEthernet0/0.13), from 155.1.13.3, Send flag is 0x0
Composite metric is (10486497280/10485841920), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 60011250000 picoseconds
Reliability is 255/255
Load is 2/255
Minimum MTU is 1400
Hop count is 3
Originating router is 150.1.2.2
You can see that the delay is now in picoseconds and not microseconds. It also does not mention using Wide Metrics and also does not show the jitter or energy. It does show a really big metric for these routes. Truly other than the picoseconds, there isn't much change. Thank goodness.
Time to get off here now and study more. Oh, before I leave. Here is the link to Cisco's white paper so someone can read it and tell me where I am wrong. :)
Cisco_White_Paper
More detail, you say? How? So they expanded the metric fields for namely bandwidth and delay. This way bandwidth, which is still measured in Kb, is greater and allows for higher speeds. Delay is measured in picoseconds on one gigabit links or less and it is scaled on links greater than one gigabit since the delay is harder to calculate. Both of these together will help an engineer to further refine their routing plan within their network.
Now for the two newly added metrics. These are accumulative jitter and accumulative energy. Really, I don't see these being used that much but in case some crazy person does want to, they are activated by activating K6.
Another cool fact about this new metric "type" is that the routers can all send both metrics to their peers. This can hog some bandwidth but on normal links this won't kill them and still allow the links to carry other traffic. On large-scale DMVPN networks, Cisco says that this can be a problem and may need to be looked at or just run the same metric type on all the routers. If the routers all support Wide Metrics, then they will all use them and skip the classic style. Cool, interesting fact.
Let's now say you are running EIGRP in a PE/CE situation. Because of the redistribution that will be happening, Wide Metrics are not used. Thought that was good to know for when someone asks. Which will probably be never.
To use Wide Metrics, Cisco says to use IOS or IOS XE and either one had to support EIGRP Release 8.0 or higher. I am running IOS 15.2(4)S3 in my lab so they all picked up the new type with no problem. To check the release that you are running, use the command show eigrp plugins. As you can see below my IOS is running 11.0.
R1#show eigrp plugins
EIGRP feature plugins:::
eigrp-release : 11.00.00 : Portable EIGRP Release
: 1.00.19 : Source Component Release(rel11)
parser : 2.02.00 : EIGRP Parser Support
igrp2 : 2.00.00 : Reliable Transport/Dual Database
bfd : 2.00.00 : BFD Platform Support
mtr : 1.00.01 : Multi-Topology Routing(MTR)
eigrp-pfr : 1.00.01 : Performance Routing Support
EVN/vNets : 1.00.00 : Easy Virtual Network (EVN/vNets)
ipv4-af : 2.01.01 : Routing Protocol Support
ipv4-sf : 1.02.00 : Service Distribution Support
vNets-parse : 1.00.00 : EIGRP vNets Parse Support
ipv6-af : 2.01.01 : Routing Protocol Support
ipv6-sf : 2.01.00 : Service Distribution Support
snmp-agent : 2.00.00 : SNMP/SNMPv2 Agent Support
So, this is all fine and dandy, but what does this all mean to me when I am troubleshooting. To find out, let's look at a route from my network.
R1#show eigrp address-family ipv4 100 topology 150.1.2.2/32
EIGRP-IPv4 VR(MULTI-AF) Topology Entry for AS(100)/ID(150.1.1.1) for 150.1.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 10485841920, RIB is 81920640
Descriptor Blocks:
155.1.0.5 (Tunnel0), from 155.1.0.5, Send flag is 0x0
Composite metric is (10485841920/7209041920), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 60001250000 picoseconds
Reliability is 255/255
Load is 2/255
Minimum MTU is 1400
Hop count is 2
Originating router is 150.1.2.2
155.1.13.3 (GigabitEthernet0/0.13), from 155.1.13.3, Send flag is 0x0
Composite metric is (10486497280/10485841920), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 60011250000 picoseconds
Reliability is 255/255
Load is 2/255
Minimum MTU is 1400
Hop count is 3
Originating router is 150.1.2.2
You can see that the delay is now in picoseconds and not microseconds. It also does not mention using Wide Metrics and also does not show the jitter or energy. It does show a really big metric for these routes. Truly other than the picoseconds, there isn't much change. Thank goodness.
Time to get off here now and study more. Oh, before I leave. Here is the link to Cisco's white paper so someone can read it and tell me where I am wrong. :)
Cisco_White_Paper
RIP Routing
I did the INE v5 RIP section of the workbook. The majority of the RIP configuration wasn't too bad. There wasn't a triggered-update command section but that's cool. Triggered updates aren't that bad and typically used for WANs anyways. I can see it being used at a DMVPN spoke with "low" bandwidth, so that is something to keep in mind. Well on to the other stuff I forgot and learned and found interesting.
One thing I forgot was that when using distribute-lists to filter traffic from gateways, it is better to use the /32 notation on the end of the gateway in the prefix-list. I also wasn't thinking when it came to filtering all routes from a particular gateway that it is better to have a permit all prefix-list as well as the gateway. The commands look like the following for matching any route that comes in any interface and deny it if it comes from the specific source.
ip prefix-list NOT_FROM_R4 deny 155.1.0.4/32
ip prefix-list NOT_FROM_R4 permit 0.0.0.0/0 le 32
!
ip prefix-list PERMIT_ALL permit 0.0.0.0/0 le 32
!
router rip
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in
I also forgot that there are changes within RIP that don't happen auto-magically. You have to have patience and let the timers flush the routes out from the table. Keep running show ip route and watch the timers. If they go above the advertise timer, then the route is probably not being received any more and once it hits the invalid timer, it will hang out until it is flushed. Patience, young grasshopper.
I always seem to get it wrong with extended ACLs being used to filter routes. I knew that one some, the source meant one thing and the destination something else and then on other route types, it all meant something different. INE explained this a little better so I just have to keep it in that rock that I call a head. For BGP, the source field is the network address and the destination field is the subnet mask. For IGPs, the source field is the update source (get it; source is the source) and the destination is the network address. Now I just have to remember.
Ran into a another gotcha with RIP and default routing. Completely wasn't thinking about it and forgot that RIP doesn't install a discard route on the originating router when it originates a default route. It is added to the RIP database so that is cool.
Had a brain fart when it came to reliable default route origination. Knew that it took IP SLA and a route map. I was having issue with the middle piece because I am so used to it being that static routes are bad and should not be used on any of the labs. Add a static route to a BOGON and use trac with that.
Learned something interesting from this all too. I did not know that when you use ip unnumbered on an interface, RIP will no longer do validation source checking for RIP updates coming into that interface. Good information to know.
Well now that RIP is done, on to EIGRP.
One thing I forgot was that when using distribute-lists to filter traffic from gateways, it is better to use the /32 notation on the end of the gateway in the prefix-list. I also wasn't thinking when it came to filtering all routes from a particular gateway that it is better to have a permit all prefix-list as well as the gateway. The commands look like the following for matching any route that comes in any interface and deny it if it comes from the specific source.
ip prefix-list NOT_FROM_R4 deny 155.1.0.4/32
ip prefix-list NOT_FROM_R4 permit 0.0.0.0/0 le 32
!
ip prefix-list PERMIT_ALL permit 0.0.0.0/0 le 32
!
router rip
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in
I also forgot that there are changes within RIP that don't happen auto-magically. You have to have patience and let the timers flush the routes out from the table. Keep running show ip route and watch the timers. If they go above the advertise timer, then the route is probably not being received any more and once it hits the invalid timer, it will hang out until it is flushed. Patience, young grasshopper.
I always seem to get it wrong with extended ACLs being used to filter routes. I knew that one some, the source meant one thing and the destination something else and then on other route types, it all meant something different. INE explained this a little better so I just have to keep it in that rock that I call a head. For BGP, the source field is the network address and the destination field is the subnet mask. For IGPs, the source field is the update source (get it; source is the source) and the destination is the network address. Now I just have to remember.
Ran into a another gotcha with RIP and default routing. Completely wasn't thinking about it and forgot that RIP doesn't install a discard route on the originating router when it originates a default route. It is added to the RIP database so that is cool.
Had a brain fart when it came to reliable default route origination. Knew that it took IP SLA and a route map. I was having issue with the middle piece because I am so used to it being that static routes are bad and should not be used on any of the labs. Add a static route to a BOGON and use trac with that.
Learned something interesting from this all too. I did not know that when you use ip unnumbered on an interface, RIP will no longer do validation source checking for RIP updates coming into that interface. Good information to know.
Well now that RIP is done, on to EIGRP.
01 June 2014
Static and Policy Based and GRE...Oh My
So I have been working through the workbook from INE. I skipped the Layer 2 section because while I have the switches, they are not hooked up. I created a base topology in GNS3 using 20 routers connected to a single dumb layer 2 switch and it works for testing everything else. I am okay with doing this right now since I am only learning the technology but for full labs, I will have to go back to using physical switches and a break out switch and Q-in-Q trunking.
I need to correct something I said in an earlier post as well. I have now noticed that there is one Foundation Lab at the bottom of the workbook. That is a full blown lab so that will be good but first I want to get through all of the Technology Labs first.
So, anyways, on to the fun stuff. I did the IP Routing section of the workbook. Most of it was pretty much common knowledge. Things like longest match routing, PBR, floating static routes, and GRE tunneling. All in all, it wasn't bad. But there were a couple of things that I didn't know and found interesting.
First, I learned about a new command that can be useful. It is show ip static route. It shows what static routes are installed in the route table and how they got there. I can see this being useful not only for floating static routes but also think about when doing summary addresses and it creates a NULL route. Be useful to fully check that.
I also had to change how I do tracking. I remember tracking SLA stats being track # rtr #. I had to do it this time as track # ip sla # <state|reachability>. Just a syntax change that is good to know.
Basic GRE routing wasn't really a problem before. I just had to remember to add the command tunnel mode gre ip so that the mode was correctly set. Again, a quick little learn.
Now what if there are two GRE tunnels and one is a backup. What do you do? Well, I didn't know that you can add the backup interface command to a tunnel so that when the primary tunnel goes down a backup one will come up. The primary tunnel though has to be a point-to-point tunnel. This cannot work on a multipoint GRE tunnel. Also there is a problem with this. If one tunnel interface goes down on one router, the other router doesn't know and will still try to route down it.
How do you fix the two tunnels not acting together? Use keepalives. These can be set up on one side of the tunnel but for better tracking do it on both. Great way to test your main tunnel and bring up the backup if it fails.
While routing over tunnels is not much of an issue, I never did really understand how the tunnels operate. I didn't realize that the tunnels will come up on each side so long as there is a route to the tunnel destination in the route table. Without it, the tunnel won't come up on that router but it can be up on the far end side. This is again where keepalives come in to play to help know if the tunnel is really working for end to end connectivity.
The place where tunnels don't use the destination to bring up the tunnel is multipoint tunnels. There is no true destination for them so they can't consult the routing table to bring them up on the hub. The spokes do have one check. That is the NHS. As long as there is a route to it then it will bring up the interface. Got a feeling that will be part of troubleshooting. Definitely can see that.
So my final thing that I learned from this section and that is CDP. No, not actually learning CDP but learning that it is disabled by default on mGRE tunnel interfaces. Again, a quick troubleshooting problem.
Again, a nice place to start. Now I am working on RIPv2. Hard to know which I like more, that or ODR. ODR is so easy. Also I included a pic of my GNS3 topology. Nothing special there.
I need to correct something I said in an earlier post as well. I have now noticed that there is one Foundation Lab at the bottom of the workbook. That is a full blown lab so that will be good but first I want to get through all of the Technology Labs first.
So, anyways, on to the fun stuff. I did the IP Routing section of the workbook. Most of it was pretty much common knowledge. Things like longest match routing, PBR, floating static routes, and GRE tunneling. All in all, it wasn't bad. But there were a couple of things that I didn't know and found interesting.
First, I learned about a new command that can be useful. It is show ip static route. It shows what static routes are installed in the route table and how they got there. I can see this being useful not only for floating static routes but also think about when doing summary addresses and it creates a NULL route. Be useful to fully check that.
I also had to change how I do tracking. I remember tracking SLA stats being track # rtr #. I had to do it this time as track # ip sla # <state|reachability>. Just a syntax change that is good to know.
Basic GRE routing wasn't really a problem before. I just had to remember to add the command tunnel mode gre ip so that the mode was correctly set. Again, a quick little learn.
Now what if there are two GRE tunnels and one is a backup. What do you do? Well, I didn't know that you can add the backup interface command to a tunnel so that when the primary tunnel goes down a backup one will come up. The primary tunnel though has to be a point-to-point tunnel. This cannot work on a multipoint GRE tunnel. Also there is a problem with this. If one tunnel interface goes down on one router, the other router doesn't know and will still try to route down it.
How do you fix the two tunnels not acting together? Use keepalives. These can be set up on one side of the tunnel but for better tracking do it on both. Great way to test your main tunnel and bring up the backup if it fails.
While routing over tunnels is not much of an issue, I never did really understand how the tunnels operate. I didn't realize that the tunnels will come up on each side so long as there is a route to the tunnel destination in the route table. Without it, the tunnel won't come up on that router but it can be up on the far end side. This is again where keepalives come in to play to help know if the tunnel is really working for end to end connectivity.
The place where tunnels don't use the destination to bring up the tunnel is multipoint tunnels. There is no true destination for them so they can't consult the routing table to bring them up on the hub. The spokes do have one check. That is the NHS. As long as there is a route to it then it will bring up the interface. Got a feeling that will be part of troubleshooting. Definitely can see that.
So my final thing that I learned from this section and that is CDP. No, not actually learning CDP but learning that it is disabled by default on mGRE tunnel interfaces. Again, a quick troubleshooting problem.
Again, a nice place to start. Now I am working on RIPv2. Hard to know which I like more, that or ODR. ODR is so easy. Also I included a pic of my GNS3 topology. Nothing special there.
Subscribe to:
Posts (Atom)