11 October 2014
Security or Stopping Users from Wasting Time and Money
Security is one of the things that first brought me into IT. It is just one of those fun and awesome topics. I also liked it because there is always someone smarter than you out there and you have to stay on top of your game. I went with R&S for my CCIE because it was just what I was doing at the time. Security is something I will be looking at later on. And on to the fun we go.
What I am gathering is that if you have the if-authenticated method for an authorization AAA policy and that method is used, the policy will assign the privilege that is located in the line configuration. In other words, if you have privilege level 15 in the line configuration and if-authenticated is the method used by exec, the user will get level 15 privileges. This can be used as a backup for TACACS too which could be a possibility on the test.
When configuring the command privilege <mode> level <#> <command>, be specific with the commands allowed. If all commands are allowed for a specific subset, include the keyword all. To include all the ip commands under the interface mode, use privilege interface all level 4 ip. Also when using those commands with AAA, include the commands aaa authorization exec <method> local and under the line configuration authorization exec <method>.
I always seem to forget this and I don't know why. To allow path MTU discovery to work, you have to allow icmp packet-too-big in and/or out. Since traceroute sends 30 probes by default, you can set an ACL for tracoute from UDP port 33434 to 33464. You can add in a couple of extras if need be. The replies will either be ICMP time-excceded or ICMP port-unreachable.
Using PBR to match packets to route to Null0 is a good idea it seems. But say you want to keep unreachable messages from getting back out. You can add the no ip unreachables to the null interface and this will block them just as if it was a regular interface.
And here I thought that for uRPF you had to create an ACL for the addresses to block automatically. Got that wrong. The ACL is checked only for packets that violate RPF. If the ACL has a permit for a violation, then the packet still goes on through. If you add the internal subnets, you can potentially allow in spoofed traffic which is what you are really trying to avoid.
Holy Crap. I just spent a lot of time on how to use NBAR for Content-Based Matching thinking that I was looking for some security feature. All they want to know is can you turn on NBAR in a class-map. I did that in the QoS section but sure. Let's do it again. Frustrated not at the task but that I wasted all that time. Well, wasted is the wrong word. Used it in a different learning environment.
Didn't know that. Hmm... NBAR will classify traffic independent of the way the policy-map is set up. It applies to both directions of the flow. So you can apply the policy-map looking out and still catch everything coming in
The command ip access-list log-update threshold is for saying how often a packet is logged. The command ip access-list logging interval tells the device how often to kick a packet up to be process switched. Making that a low number and the log-update threshold higher can reduce the load on the device. This doesn't take into consideration packets heading to the router since they are process switched anyway.
VLAN filters are ingress only. To do outbound, you can do an access-list on an SVI. Think of them also as route-maps in structure that then are applied to VLANs. They also not only hit transit traffic but anything generated locally on the device as well. And finally, always re-apply the vlan filter after making a change. They are not dynamic and more static in nature. After upgrading my IOL Layer 2 images, I finally got one that didn't crash. Problem is that the previous image and this one does NOT have vlan filters. Just awesome.
Protocol numbers for MAC access-lists suck. After some digging, I think that I found some.
ARP - 0x806
STP - lsap 0x4242 and 0x010b
VTP - 0x2003
CDP - 0x2000
DTP - 0x2004
UDLD - 0x0111
When setting the maximum number of mac-addresses on a trunk port per VLAN, include the maximum number as well. The VLAN portion will allow that number per VLAN but if you allow 2 addresses in, since the default maximum for the port is 1, it won't work.
Using port-security on a port connected to a device with HSRP can lead to violations unless one of two things is corrected. One can be to increase the allowed MAC addresses to 2 to account for the extra MAC. The other is to issue the standby use-bia address on the HSRP device. This causes HSRP to use the burned in address for the HSRP MAC instead of the dynamically generated one.
The command ip dhcp snooping trust is applied to ports that connect to either DHCP servers or other switches (uplinks). This command also has to be on any port where a DHCP packet is received with a non-zero "giaddr". It also causes messages received on the configured upon port to not create entries in the DHCP Snooping binding database. Also to make an IOS DHCP server take in an all zero giaddr packets, use one of three options:
1) at the global level, use ip dhcp relay information trust-all
2) at the interface level, use ip dhcp relay information trusted
3) configure the DHCP snooper with no ip dhcp snooping information option to not insert Option 82
There is the other option of trusting where the information came from on the snooper but that doesn't really help anything on ports attached to clients.
By default a switch that is snooping will not accept DHCP packets with Option 82 coming into untrusted ports. This can be changed with the command ip dhcp snooping information option allow-untrusted. It still rejects packets with a giaddr of 0. Fix this by trusting ports where that comes in to the switch.
Dynamic ARP Inspection (DAI) looks at ARP packets received on untrusted ports, which by default is all of them. It allows the packet if it matches what is in the ARP inspection table. While good for preventing some attacks, ARP poisoning, it can break other things, like PROXY ARP. To trust a port, use the interface command ip arp inspection trust. You can also configure DAI to validate source and destination MACs in ARP packets and/or validate the IP, which seems to make sure that 255.255.255.255 or 0.0.0.0 are not bound. By default, DAI uses the DHCP bindings tables to build mapping information. For those that use static IPs, you have to use an ARP access-list. This list is checked first, followed by the DHCP table. This behaviour can be changed with an explicit deny on the end of the table. To do logging with DAI, you need to have the log keyword in the ACL and turn logging on with ip arp inspection vlan <VLAN_ID> logging acl-match <matchlog|none>. You can also log probes and DHCP bindings.
Oh, great. Another layer 2 security feature that throws me. IP source guard helps to beat MitM attacks by applying a layer 3 filter to configured ports. It is dependent upon having DHCP snooping enabled first. Once you enable it, only packets that match the DHCP snooping database or static IP/MAC assignments are allowed. DHCP packets are allowed so that clients can get layer 3 addresses. It can also be combined with DAI. When you configure IP source guard with the port-security option, you have to also have port-security enabled. If you configure IP source guard on a trunk port, you have to have DHCP snooping trust on that port too.
Interesting. ACLs applied to switch interfaces can only be applied to traffic coming in. It cannot be applied to traffic leaving the interface. Now on SVI interfaces, you can do both. Maybe that is why they are SVI, they swing both ways. Swinging Virtual Interfaces.
Messed that up. Was setting up a user to be able to telnet into a router and then only allow them out to a specific router. Instead what I did was limit all users. I needed the access-class option for the username. Well, shoot.
Beautiful. The commands login on-failure and login on-success are not in the master command guide. Just wonderful. Luckily the commands are not that hard to figure out.
Setting up views can be great to limit commands and setting them up isn't so bad. Just have to remember to do some initial things. One is to enable aaa new-model. Two is to have an enable password. Three is for interfaces, you not only need to include the command for the interface you are allowing the view into but also to include the interface command. Not that hard after all that.
The command ip icmp rate-limit is not in the Security section. It is in the IP Application Services section. It is basically saying send an unreachable every so many milliseconds. If you use the df keyword, it specifies the number to send for each packet with the df bit set. All others fall under the rate with the non-df bit set.
When setting up control plane policing and you need to match ARP, you can do match protocol arp. Other NBAR matching doesn't work. Also in the policy map, there are only two options available for the traffic: drop and police. Police also allows the use of the rate keyword which comes in handy for limiting inbound and outbound traffic. But that is only one option. You can still police by speed. The configuration guide of this is under QoS and again, not under the security section. I believe this is because of the MQC being used.
You can silently drop all packets with IP options using the command ip options drop. If you want some, then use ACLs. Packets with IP options are process-switched on a router and increase the proc load on the router.
19 September 2014
Quirky Operational Situations or QoS
QoS is something that I never had to deal with in a work environment. The only time I ever have to deal with it is on the tests. Makes it something interesting to do. Honestly, though, it really ain't so bad on the routers. Switch QoS is something that is a little different.
Order is important in a policy-map. It applies from the top down. Screw the order up and you can mess up what was intended. A class that matches TCP before a class matching HTTP will never get to the HTTP class.
A lot of tasks for INE and iPexpert (v4) seem to want to try to transfer images from one device to another. Good idea for testing to make sure that HTTP, FTP, ACLs, QoS, etc, is working. Problem is in GNS3, it is hard to do that. I just fire up SLA and run it. May not be the best for some aspects of testing but it works. It won't flood a link but it at least will match HTTP traffic. Commands that I use are
ip sla 1
tcp-connect 155.1.146.1 80
threshold 1000
timeout 1000
frequency 1
ip sla schedule 1 life forever start-time now
To limit the size of the FIFO queues for traffic classes, use the queue-limit command. Starting in 15.2(2)T, the default for this was packets. In other words, a queue-limit 24 would mean that the queue had a size of 24 packets. This command can be used for queue sizes in other queuing methods as seen in a minute.
Turning on WFQ for the class-default class is done through the fair-queue command under that class in the policy map. Once turned on, you can modify the queue sizes with the queue-limit command.
Nested service policies have always gotten me and I don't know why. I can do nested loops in programming. Anyways, say you want to make the overall bandwidth of an interface to be shaped to a specific number and also for the classes to have certain attributes as well. What what you do is create a parent policy that only has class-default as a class, apply the shaping to it, and then use the service-policy command to apply a child policy that has your classes broken out in it. Not really that hard and yet I still screw it up every time. Cisco only allows up to three policy maps to be in a nest. Say you shape with the first one (all traffic), shape even more for the second (TCP traffic), and the third is super specific (HTTP).
As soon as the bandwidth command is given under a class in a policy map, CBWFQ is used. Each bandwidth commands means that that class-map has a FIFO queue attached to it as well. If you configure a bandwidth command under the default class, you turn off fair-queuing. This turns it into a single FIFO queue. If all you have is class-default and you do a bandwidth statement, you have turned the entire interface into a FIFO queue.
If you try to mix bandwidth and bandwidth percent in the same policy-map, it won't work. All units must be the same across all the classes. Didn't do this, but figured that it was was still a good thing to know.
When coming up with a LLQ policy, you need to always remember your Layer 2 overhead. LLQ accounts for that and can screw you up if you forget it.
A task was asking for dropping of packets using random-detect. I figured out how to get it on, but as for actually getting the dropping working, I didn't get that. Solution was to use random-detect precedence, which now makes sense. With random-detect precedence, you tell it what precedence, the minimum and maximum thresholds and the probability. But the question I had was how do you know the precedence to filter on and only get the packets you want? Another portion of this task was to mark all packets of a certain type with IP precedence 2. I took that to mean as they left the interface. They did it as the packets moved in to the ingress interface and then did random-detect on the egress. Sneaky.
CBWFQ has three main drop policies
1) Tail-drop
-- default for user-defined classes
2) Congestive Discard for WFQ
3) Random Early Detection (RED)
To enable random drops on unclassified traffic, the configuration seems to need fair-queue to be enabled in the policy. Do that and then enable random-detect also.
When doing RED with ECN, you may need to enable TCP ECN. Do this with ip tcp ecn. And of course, that command doesn't seem to be available in 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.2(4)S3. Awesome.
Fun times configuring CIR and Bc values. Bc stands for Burst Committed. CIR is Committed Information Rate. AR is Access Rate (line speed). Tc is Time Committed. Shapers send packets every Tc milliseconds, essentially separating them by Tc time periods. Tc cannot be configured manually on a device but you can use it come up with CIR and Bc. Bc = CIR * (Tc/1000) which means that the Bc is equal to the CIR times the Tc in seconds. The lower the Tc the more the processor will work. There is also Excess Burst (Be) which comes into play. The maximum Be value is equal to the AR minus the CIR all multiplied by the Tc in seconds or maxBe = (AR - CIR) * (Tc/1000).
Single-Rate Three Color Marker (srTCM) is a system that has always boggled my mind. Think I am starting to understand it now. For every 1/CIR milliseconds a token is put into the bucket. The space between those tokens is Ti ms. The size of the bucket is Bc. Excess tokens that are not used are transferred to the excess bucket for size Be. I am thinking that a token is the amount of information that can be send in Tc. So when a packet comes in that is size X, it is checked first against the Bc bucket. If it is less than or equal to the amount of tokens it is marked with the conform action and the Bc bucket is deducted the size of the packet. If it is less than or equal to the Be bucket, then it is marked with the exceed action and the Be bucket is deducted the size of the packet. Finally, it's marked with the violate action if it fails the others.
To account for the sliding window content correctly, it is better to set the policer Bc to the shaper burst size plus the average packet size. This will also give you a little wiggle room.
Two-Rate Three Color Marker (trTCM) uses two different buckets that fill with tokens based on the time intervals configured with Bc and Be. One is for the CIR and the other is for the Peak Information Rate (PIR). There are still three possible outcomes like with srTCM. If the packet is greater than the tokens in the PIR bucket is violates. If the packet is greater than the tokens in the CIR bucket, it exceeds and the PIR bucket is docked the size of the packet. Finally, if the other two are are not met, the packet conforms and the PIR and CIR buckets are docked the size of the packet. Cool. Think I am getting this now.
QoS pre-classify can only be done on tunnel interfaces, virtual templates, and crypto maps. The command is unavailable on any other interface types. It can only be enabled for IP packets as well. This command allows the IOS to apply QoS before the data is encrypted and tunneled. Without this, the interface that has the service-policy applied to it will treat the tunnel as one flow and not respective flows. This command will cause the router to see the header before being put in a tunnel and then use that header for matching class-maps. Class-based traffic shaping doesn't work for DMVPN, so it looks like qos pre-classify is the way to go.
Order is important in a policy-map. It applies from the top down. Screw the order up and you can mess up what was intended. A class that matches TCP before a class matching HTTP will never get to the HTTP class.
A lot of tasks for INE and iPexpert (v4) seem to want to try to transfer images from one device to another. Good idea for testing to make sure that HTTP, FTP, ACLs, QoS, etc, is working. Problem is in GNS3, it is hard to do that. I just fire up SLA and run it. May not be the best for some aspects of testing but it works. It won't flood a link but it at least will match HTTP traffic. Commands that I use are
ip sla 1
tcp-connect 155.1.146.1 80
threshold 1000
timeout 1000
frequency 1
ip sla schedule 1 life forever start-time now
To limit the size of the FIFO queues for traffic classes, use the queue-limit command. Starting in 15.2(2)T, the default for this was packets. In other words, a queue-limit 24 would mean that the queue had a size of 24 packets. This command can be used for queue sizes in other queuing methods as seen in a minute.
Turning on WFQ for the class-default class is done through the fair-queue command under that class in the policy map. Once turned on, you can modify the queue sizes with the queue-limit command.
Nested service policies have always gotten me and I don't know why. I can do nested loops in programming. Anyways, say you want to make the overall bandwidth of an interface to be shaped to a specific number and also for the classes to have certain attributes as well. What what you do is create a parent policy that only has class-default as a class, apply the shaping to it, and then use the service-policy command to apply a child policy that has your classes broken out in it. Not really that hard and yet I still screw it up every time. Cisco only allows up to three policy maps to be in a nest. Say you shape with the first one (all traffic), shape even more for the second (TCP traffic), and the third is super specific (HTTP).
As soon as the bandwidth command is given under a class in a policy map, CBWFQ is used. Each bandwidth commands means that that class-map has a FIFO queue attached to it as well. If you configure a bandwidth command under the default class, you turn off fair-queuing. This turns it into a single FIFO queue. If all you have is class-default and you do a bandwidth statement, you have turned the entire interface into a FIFO queue.
If you try to mix bandwidth and bandwidth percent in the same policy-map, it won't work. All units must be the same across all the classes. Didn't do this, but figured that it was was still a good thing to know.
When coming up with a LLQ policy, you need to always remember your Layer 2 overhead. LLQ accounts for that and can screw you up if you forget it.
A task was asking for dropping of packets using random-detect. I figured out how to get it on, but as for actually getting the dropping working, I didn't get that. Solution was to use random-detect precedence, which now makes sense. With random-detect precedence, you tell it what precedence, the minimum and maximum thresholds and the probability. But the question I had was how do you know the precedence to filter on and only get the packets you want? Another portion of this task was to mark all packets of a certain type with IP precedence 2. I took that to mean as they left the interface. They did it as the packets moved in to the ingress interface and then did random-detect on the egress. Sneaky.
CBWFQ has three main drop policies
1) Tail-drop
-- default for user-defined classes
2) Congestive Discard for WFQ
3) Random Early Detection (RED)
To enable random drops on unclassified traffic, the configuration seems to need fair-queue to be enabled in the policy. Do that and then enable random-detect also.
When doing RED with ECN, you may need to enable TCP ECN. Do this with ip tcp ecn. And of course, that command doesn't seem to be available in 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.2(4)S3. Awesome.
Fun times configuring CIR and Bc values. Bc stands for Burst Committed. CIR is Committed Information Rate. AR is Access Rate (line speed). Tc is Time Committed. Shapers send packets every Tc milliseconds, essentially separating them by Tc time periods. Tc cannot be configured manually on a device but you can use it come up with CIR and Bc. Bc = CIR * (Tc/1000) which means that the Bc is equal to the CIR times the Tc in seconds. The lower the Tc the more the processor will work. There is also Excess Burst (Be) which comes into play. The maximum Be value is equal to the AR minus the CIR all multiplied by the Tc in seconds or maxBe = (AR - CIR) * (Tc/1000).
Single-Rate Three Color Marker (srTCM) is a system that has always boggled my mind. Think I am starting to understand it now. For every 1/CIR milliseconds a token is put into the bucket. The space between those tokens is Ti ms. The size of the bucket is Bc. Excess tokens that are not used are transferred to the excess bucket for size Be. I am thinking that a token is the amount of information that can be send in Tc. So when a packet comes in that is size X, it is checked first against the Bc bucket. If it is less than or equal to the amount of tokens it is marked with the conform action and the Bc bucket is deducted the size of the packet. If it is less than or equal to the Be bucket, then it is marked with the exceed action and the Be bucket is deducted the size of the packet. Finally, it's marked with the violate action if it fails the others.
To account for the sliding window content correctly, it is better to set the policer Bc to the shaper burst size plus the average packet size. This will also give you a little wiggle room.
Two-Rate Three Color Marker (trTCM) uses two different buckets that fill with tokens based on the time intervals configured with Bc and Be. One is for the CIR and the other is for the Peak Information Rate (PIR). There are still three possible outcomes like with srTCM. If the packet is greater than the tokens in the PIR bucket is violates. If the packet is greater than the tokens in the CIR bucket, it exceeds and the PIR bucket is docked the size of the packet. Finally, if the other two are are not met, the packet conforms and the PIR and CIR buckets are docked the size of the packet. Cool. Think I am getting this now.
QoS pre-classify can only be done on tunnel interfaces, virtual templates, and crypto maps. The command is unavailable on any other interface types. It can only be enabled for IP packets as well. This command allows the IOS to apply QoS before the data is encrypted and tunneled. Without this, the interface that has the service-policy applied to it will treat the tunnel as one flow and not respective flows. This command will cause the router to see the header before being put in a tunnel and then use that header for matching class-maps. Class-based traffic shaping doesn't work for DMVPN, so it looks like qos pre-classify is the way to go.
12 September 2014
iPexpert Workbook Topology and My Plan
iPexpert has released the topology that they are using for their study materials. You will find it below.
What I find interesting about this topology, is the sheer scale of it. Rough count was about 35 routes and 8 switches. Looking at the interfaces and I am thinking that this was done in IOU/IOL. I am good with that. I cannot wait to get playing with it. Cannot wait for the workbooks to start rolling more and more from both vendors.
My plan for studying is the following:
1) Finish the ATC section of INE's material (hopefully this month)
2) Read the workbook vol 1 from iPexpert and work areas that are unknown or shaky
3) Work through Cisco Press's v5 book
4) Work through iPexpert's vol 2 workbook
5) Do the INE full labs
6) Re-take my bootcamp with iPexpert in December
7) After the test, continue on things I was weak, and keep doing full labs
8) Take the lab exam in January
9) After passing the test, get drunk
Well, enough of that. Time to move on to QoS.
What I find interesting about this topology, is the sheer scale of it. Rough count was about 35 routes and 8 switches. Looking at the interfaces and I am thinking that this was done in IOU/IOL. I am good with that. I cannot wait to get playing with it. Cannot wait for the workbooks to start rolling more and more from both vendors.
My plan for studying is the following:
1) Finish the ATC section of INE's material (hopefully this month)
2) Read the workbook vol 1 from iPexpert and work areas that are unknown or shaky
3) Work through Cisco Press's v5 book
4) Work through iPexpert's vol 2 workbook
5) Do the INE full labs
6) Re-take my bootcamp with iPexpert in December
7) After the test, continue on things I was weak, and keep doing full labs
8) Take the lab exam in January
9) After passing the test, get drunk
Well, enough of that. Time to move on to QoS.
IPv6: It's Just a Fad That is Becoming MainStream
IPv6 is something that I haven't gotten to play with at work. I have taken a class on it. I have played with it in the lab. I have studied it for tests. Production, though...NOPE!! I do like it. I remember when I first heard about it and someone was saying that it HAD to have IPSec because it was built in. Well, it is, but thankfully, it is not required. Could you imagine the implementation mess that would make.
When using autoconfiguration on an interface, add the default keyword to have the router add a default gateway to the router it is learning its prefix from. Also since routing is enabled essentially on the autoconfiguration-passing router, may be a good idea to turn on ipv6 unicast-routing. Apparently Ethernet interfaces by default have router advertisements turned off. If you are wanting to do some autoconfiguration, you may want to use the command no ipv6 nd suppress-ra but you definitely need to turn on unicast routing for it to work.
In IPv4, you could disable the split horizon per interface for RIP. For IPv6, it is done on the process level. That means you are turning off split horizon on all interfaces that that RIP process is configured on. That seems like a bad idea because what if you don't want it off on all interfaces. Also the EIGRPv6 split horizon is still per interface.
So with IPv6 EIGRP, there apparently isn't a leak map. Interesting. Fun trying to let some prefixes out and hide others then when doing a summary. Think about when doing that for a default route injection but still want to show some routes. Have to redistribute the route and use distribute-lists for the other routes to advertise.
So even though the command reference doesn't mention it, you can still use in and out keywords when doing a distribute-list prefix-list in IPv6 EIGRP. Messed me up since it wasn't shown.
Just read that right now, IPv6 EIGRP can only do equal-cost load balancing. That may be something to look at. Apparently you can tell EIGRPv6 to find paths with unequal metrics but it will say screw you and only balance across them equally.
Two things about summarizing routes in OSPF between areas. One, and this doesn't matter where the summarization is, remember to change the OSPF network type for loopbacks otherwise they come in as /128 or /32 depending on the protocol. Next, the area range command still throws me. It is saying pull from this area anything that matches this range. I don't know why I can't get that. Getting frustrating.
And here I was looking for how to turn on PIM on interfaces. Crap. When you enable multicast routing for IPv6 on a router, it does so for ALL interfaces. You have turn it off on the interfaces you don't want with no ipv6 pim. Also replace ip igmp with ipv6 mld and you just about got it all. Other interesting note is that the documentation for PIM is broken on Cisco's website for the 15 code. I am having to use the 12.4T documentation for PIM.
IPv6 tunnelling has been moved to the Interface and Hardware Component configuration guide. Well, ain't that something. Figured it would have been kept in the IPv6 guide but that was too easy I guess.
So according to what I read, you have to do static routing with Automatic 6to4 Tunnelling. Since 6to4 is a multipoint technology, dynamic routing seems to be an issue. INE says that the common thing is to do a static for the full 2002::/16 network pointing to the created tunnel. Also since ISATAP tunnels cannot extract the destination automatically, static routes have to be used there as well.
When using autoconfiguration on an interface, add the default keyword to have the router add a default gateway to the router it is learning its prefix from. Also since routing is enabled essentially on the autoconfiguration-passing router, may be a good idea to turn on ipv6 unicast-routing. Apparently Ethernet interfaces by default have router advertisements turned off. If you are wanting to do some autoconfiguration, you may want to use the command no ipv6 nd suppress-ra but you definitely need to turn on unicast routing for it to work.
In IPv4, you could disable the split horizon per interface for RIP. For IPv6, it is done on the process level. That means you are turning off split horizon on all interfaces that that RIP process is configured on. That seems like a bad idea because what if you don't want it off on all interfaces. Also the EIGRPv6 split horizon is still per interface.
So with IPv6 EIGRP, there apparently isn't a leak map. Interesting. Fun trying to let some prefixes out and hide others then when doing a summary. Think about when doing that for a default route injection but still want to show some routes. Have to redistribute the route and use distribute-lists for the other routes to advertise.
So even though the command reference doesn't mention it, you can still use in and out keywords when doing a distribute-list prefix-list in IPv6 EIGRP. Messed me up since it wasn't shown.
Just read that right now, IPv6 EIGRP can only do equal-cost load balancing. That may be something to look at. Apparently you can tell EIGRPv6 to find paths with unequal metrics but it will say screw you and only balance across them equally.
Two things about summarizing routes in OSPF between areas. One, and this doesn't matter where the summarization is, remember to change the OSPF network type for loopbacks otherwise they come in as /128 or /32 depending on the protocol. Next, the area range command still throws me. It is saying pull from this area anything that matches this range. I don't know why I can't get that. Getting frustrating.
And here I was looking for how to turn on PIM on interfaces. Crap. When you enable multicast routing for IPv6 on a router, it does so for ALL interfaces. You have turn it off on the interfaces you don't want with no ipv6 pim. Also replace ip igmp with ipv6 mld and you just about got it all. Other interesting note is that the documentation for PIM is broken on Cisco's website for the 15 code. I am having to use the 12.4T documentation for PIM.
IPv6 tunnelling has been moved to the Interface and Hardware Component configuration guide. Well, ain't that something. Figured it would have been kept in the IPv6 guide but that was too easy I guess.
So according to what I read, you have to do static routing with Automatic 6to4 Tunnelling. Since 6to4 is a multipoint technology, dynamic routing seems to be an issue. INE says that the common thing is to do a static for the full 2002::/16 network pointing to the created tunnel. Also since ISATAP tunnels cannot extract the destination automatically, static routes have to be used there as well.
Multicast: When everyone gets it but not everyone understands
Got to play with multicast. When broken down step by step like the INE workbook, it wasn't so bad. Hopefully I can maintain that understanding as I move forward. Now, I did notice something interesting before moving on. For the switch portion of this lab, I used IOU. I got snooping working but I could not get profiles or MVR. Really hoping that is not on the test since they are virtual as well.
A big gotcha for this multicast section is that I cannot open the PIM section of the 15 code configuration guide. Any release. To do the multicast section, I has to revert back to the 12.4T configuration guide. The 15 code guide just returns a HTTP 404.
Interesting. There is a command to check the RPF for a source. It is show ip rpf <source_ip>. It shows the following:
R5#show ip rpf 155.1.146.6
RPF information for ? (155.1.146.6)
RPF interface: GigabitEthernet0/0.45
RPF neighbor: ? (155.1.45.4)
RPF route/mask: 155.1.146.0/24
RPF type: unicast (eigrp 100)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
To debug RFP, you can disable the CEF switching on interfaces that multicast packets are received on and sent out of with no ip mfib cef output and no ip mfib cef input. Then do a debug of the process switched multicast packets and signal any RFP issues. This will let you know what interface the multicast packets are coming in on and what happened with them. If the packet is accepted (sent on), it will show that too and what interface it is sent out of. The no ip mroute-cache command is deprecated. Cisco is wanting us to use the no ip mfib commands now. Good to know.
When using ip mroute, be as specific as possible for the source. Too loose and you can mess up other multicast sources. It will cause a source to fail RPF by having it look to be coming from the interface in the mroute. Tighter is always better.
So in dynamic routing protocols, the static entries are king. In multicast, static RP entries lose to dynamic entries. Way to beat that is the use of the override option when configuring a static RP. Using override will, you guessed it, override the dynamic option and force the use of the static.
PIM Sparse mode uses tunnels to talk with the RP from the sender. The sender and RP use the tunnel to encapsulate joins. The RP gets two tunnels. One for encapsulating and one for un-encapsulating. These tunnels can mess up configs too. If you paste a config into a router, and the multicast tunnle gets made before a manual tunnel, the manual tunnel will fail if they share the same number. The tunnels are not configurable and can be seen with show derived-config interface tunnel#. An example is below.
R6#show derived-config int tun0
Building configuration...
Derived configuration : 205 bytes
!
interface Tunnel0
description Pim Register Tunnel (Encap) for RP 150.1.5.5
ip unnumbered GigabitEthernet0/0.146
tunnel source GigabitEthernet0/0.146
tunnel destination 150.1.5.5
tunnel tos 192
end
To prevent the fallback from Sparse-mode to Dense-mode in PIM, use no ip dm-fallback. Good for when you have only a couple of groups that you want to be dense without any way of the others coming back to it. Helps keep traffic from going all over.
PIM Assert is used so that only one router on a broadcast segment sends multicast traffic. To determine the winner, the routers let each other know the AD and metric of the routing protocol to get to the source. Best AD wins, followed by best metric. If both are a tie, then highest IP wins. An ip mroute with no distance specified beats EIGRP in AD for example.
When assigning a router to be the RP for a network via AutoRP, I have to remember to enable it for PIM as well. And since two multicast addresses have to propagate throughout the network, sparse-dense-mode is the best choice for multicast. Just remember though that this can be a problem if a negative any (deny any) list is used for the RP any where in the network. This will cause all networks to become dense mode operational.
With the ip pim rp-announce-filter command, if you omit the rp-list option, all announcements with groups matching the group-list are matched. If you don't use the group-list option, then all updates from the RPs in the rp-list are matched. Good way to deny or allow all based on RP or group.
Now I get the use of ip pim autorp listener. If all the interfaces are in sparse mode, it allows the router to still flood 224.0.1.39 and 224.0.1.40 in dense mode. It makes sure that there is no failback to dense mode for any other groups.
PIM NBMA mode only works with sparse mode. Good to know. And since Auto RP works only in dense mode, you have to make changes to the network. One way is to create a tunnel from spoke to spoke so that if the cRP is behind one and the mapping agent behind another, they can talk.
When setting the multicast boundary and wanting to filter AutoRP messages, you have to use a standard ACL. You cannot base it on the source or the RP. It looks at any incoming IGMP and PIM messages to see if needs to drop or allow the traffic. Unicast PIM Register messages are not affected by this.
Where AutoRP floods information about who the RP is or who wants to be it, BSR just goes hop by hop. Should make boundaries easier to configure. No multicast out an interface and done. If only it was that easy. Also have to remember that BSR messages are subject to RPF. Yep. Another one of those bite ya in butt things.
The highest hash-value that you can apply to ip pim bsr-candidate is 31. Good to know if comes up. Using that value with more than one RP, will cause them to load balance. You take one, I take on scenario.
Multicast stub routing is a way to help out smaller sites. It limits what PIM and IGMP information is sent across to the stub router to limit traffic. You configure it on the border router to the stub and then on the stub facing the clients, configure ip igmp helper-address <main router>. The stub router can be set completely to dense mode as well just to make sure that all traffic gets to the distro router and clients. No PIM adjacency is ever formed from the hub to the client router via the ip pim neighbor-filter <ACL> which denies and permits who can form a neighborship.
Yep. It's another Cisco-ism. Multiple ways to do things. You can do ip multicast boundary to filter multicast traffic of course. But there is also ip igmp access-group as well. This filters based on the multicast groups that is trying to be joined. According to INE, it is more common method. When doing the filter, you can use either standard or extended ACLs. Standard ACLs are used to filter ICMP v1, v2, and v3 receivers. Extended ACLs allow you to filter IGMPv3 reports.
To limit the aggregate number of multicast groups that are joined by receivers that are directly connected, use the ip igmp limit command. This can be done globally or per interface. Basically it limits the amount of mroute states created due to IGMP reports.
The designated querier, one that makes sure someone is still listening, is based on the lowest IP address. The PIM DR is based on the highest IP address. Can't overload one router on the segment. Share the wealth.
Periodic IGMP queries are sent based on the ip igmp query-interval command. If a non-designated router running multicast doesn't hear any membership queries based on the time in the command ip igmp querier-timeout, it will try to become the new designated querier. Without that command, the timeout is two times the query-interval of that same interface with the default being 60 seconds. To shorten leave times, you can configure the ip igmp query-max-response-time so that everyone knows to send responses in a timely manner. The ip igmp last-member-query-interval is how fast special IGMP Leave messages need to be seen to be counted. Nothing else, just put on the interface ip igmp immediate-leave with and ACL and that interface no longer cares about multicast once it gets a Leave message.
Steps to make a multicast helper map
1) Set up a multicast network between the two broadcast domains
2) Enable broadcast forwarding on the ingress router to the multicast network with ip forward-protocol
3) On the ingress router to the multicast network, at the interface connecting to the broadcast domain, enter the ip multicast helper-map broadcast command. The ACL for this command has to be extended for the UDP matching.
4) Enable broadcast forwarding on the multicast network egress router with ip forward-protocol as well as put ip multicast helper-map on the interface connected to the multicast network. Again the ACL has to be extended.
5) Enable directed-broadcast on the interface connected to the broadcast network on the egress router. Can also specify a different broadcast address with ip broadcast-address
You can test helper maps with DNS. Enable DNS name resolution on the first broadcast network and don't enter a DNS server. The router will eventually broadcast for 255.255.255.255 and if the ACL for the helper map is any any or specific for that entry, then it gets hit. You can also use an extended traceroute.
When enabling bidirectional PIM, make sure that you enable bi-directional PIM with ip pim bidir-enable. Also learned that the rp-candidate command is particular about its options. Contrary to what the documentation says about the placement of the group-list option in relation to the bidir option, the bidir option has to come last.
When setting up source specific multicast, you don't need an RP if that is all you are doing. The receiver (ip igmp join-group <group> source <source>) and everyone in between builds the shortest path to the source based on the source specified. SSM also uses either the default range (232.0.0.0/8) or can be given a range with an ACL. No shared trees are used for either range and (*,G) joins are dropped. IGMP version 3 only has to be enabled on the receiving interface. Not on all.
To be able to exchange multicast traffic between two different ASs, you need to do the following:
1) Turn on PIM between the two ASs. PIM SM is most common. Limit BSR/AutoRP leaks.
2) Exchange route information using a routing protocol. BGP is most common since it has an extension for this.
When applying the multicast address-family to BGP, make sure to activate all neighbors. Without this, not everyone is going to know about multicast routes. You can also use pre-pending to manipulate routes. If allowed, redistribute the IGP into the multicast address-family for help with RPF checks and routing.
After some initial headaches with finding a Layer 2 image in IOU that does IGMP snooping, I just hit the same problem with MVR (Multicast VLAN Registration). Just beautiful. Anyways, on to MVR. There are four basic steps to configure MVR.
1) Enable it with mvr and mvr group <multicast-group>
2) Set the MVR VLAN with mvr vlan <vlan-id>. This is the VLAN that carries all the multicast traffic and spans all the switches. Feel free to define the mode here as well.
3) Tell the switch what the sending and receiving interfaces are with mvr type <source|receiver> at the interface level.
4) Optionally, create a static group join with mvr vlan <vlan-id> group <ip-address>. This is done on the receiving ports.
IGMP profiles are another one that I cannot do in IOU/IOL. That is fine. I think that I have it figured out. IGMP profiles are for when you want to permit and deny at the switch level. It looks a lot like named ACLs but with numbers instead of a name. I do like the hierarchical way of configuring things. You apply the profile to the interface with ip igmp filter #.
A big gotcha for this multicast section is that I cannot open the PIM section of the 15 code configuration guide. Any release. To do the multicast section, I has to revert back to the 12.4T configuration guide. The 15 code guide just returns a HTTP 404.
Interesting. There is a command to check the RPF for a source. It is show ip rpf <source_ip>. It shows the following:
R5#show ip rpf 155.1.146.6
RPF information for ? (155.1.146.6)
RPF interface: GigabitEthernet0/0.45
RPF neighbor: ? (155.1.45.4)
RPF route/mask: 155.1.146.0/24
RPF type: unicast (eigrp 100)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
To debug RFP, you can disable the CEF switching on interfaces that multicast packets are received on and sent out of with no ip mfib cef output and no ip mfib cef input. Then do a debug of the process switched multicast packets and signal any RFP issues. This will let you know what interface the multicast packets are coming in on and what happened with them. If the packet is accepted (sent on), it will show that too and what interface it is sent out of. The no ip mroute-cache command is deprecated. Cisco is wanting us to use the no ip mfib commands now. Good to know.
When using ip mroute, be as specific as possible for the source. Too loose and you can mess up other multicast sources. It will cause a source to fail RPF by having it look to be coming from the interface in the mroute. Tighter is always better.
So in dynamic routing protocols, the static entries are king. In multicast, static RP entries lose to dynamic entries. Way to beat that is the use of the override option when configuring a static RP. Using override will, you guessed it, override the dynamic option and force the use of the static.
PIM Sparse mode uses tunnels to talk with the RP from the sender. The sender and RP use the tunnel to encapsulate joins. The RP gets two tunnels. One for encapsulating and one for un-encapsulating. These tunnels can mess up configs too. If you paste a config into a router, and the multicast tunnle gets made before a manual tunnel, the manual tunnel will fail if they share the same number. The tunnels are not configurable and can be seen with show derived-config interface tunnel#. An example is below.
R6#show derived-config int tun0
Building configuration...
Derived configuration : 205 bytes
!
interface Tunnel0
description Pim Register Tunnel (Encap) for RP 150.1.5.5
ip unnumbered GigabitEthernet0/0.146
tunnel source GigabitEthernet0/0.146
tunnel destination 150.1.5.5
tunnel tos 192
end
To prevent the fallback from Sparse-mode to Dense-mode in PIM, use no ip dm-fallback. Good for when you have only a couple of groups that you want to be dense without any way of the others coming back to it. Helps keep traffic from going all over.
PIM Assert is used so that only one router on a broadcast segment sends multicast traffic. To determine the winner, the routers let each other know the AD and metric of the routing protocol to get to the source. Best AD wins, followed by best metric. If both are a tie, then highest IP wins. An ip mroute with no distance specified beats EIGRP in AD for example.
When assigning a router to be the RP for a network via AutoRP, I have to remember to enable it for PIM as well. And since two multicast addresses have to propagate throughout the network, sparse-dense-mode is the best choice for multicast. Just remember though that this can be a problem if a negative any (deny any) list is used for the RP any where in the network. This will cause all networks to become dense mode operational.
With the ip pim rp-announce-filter command, if you omit the rp-list option, all announcements with groups matching the group-list are matched. If you don't use the group-list option, then all updates from the RPs in the rp-list are matched. Good way to deny or allow all based on RP or group.
Now I get the use of ip pim autorp listener. If all the interfaces are in sparse mode, it allows the router to still flood 224.0.1.39 and 224.0.1.40 in dense mode. It makes sure that there is no failback to dense mode for any other groups.
PIM NBMA mode only works with sparse mode. Good to know. And since Auto RP works only in dense mode, you have to make changes to the network. One way is to create a tunnel from spoke to spoke so that if the cRP is behind one and the mapping agent behind another, they can talk.
When setting the multicast boundary and wanting to filter AutoRP messages, you have to use a standard ACL. You cannot base it on the source or the RP. It looks at any incoming IGMP and PIM messages to see if needs to drop or allow the traffic. Unicast PIM Register messages are not affected by this.
Where AutoRP floods information about who the RP is or who wants to be it, BSR just goes hop by hop. Should make boundaries easier to configure. No multicast out an interface and done. If only it was that easy. Also have to remember that BSR messages are subject to RPF. Yep. Another one of those bite ya in butt things.
The highest hash-value that you can apply to ip pim bsr-candidate is 31. Good to know if comes up. Using that value with more than one RP, will cause them to load balance. You take one, I take on scenario.
Multicast stub routing is a way to help out smaller sites. It limits what PIM and IGMP information is sent across to the stub router to limit traffic. You configure it on the border router to the stub and then on the stub facing the clients, configure ip igmp helper-address <main router>. The stub router can be set completely to dense mode as well just to make sure that all traffic gets to the distro router and clients. No PIM adjacency is ever formed from the hub to the client router via the ip pim neighbor-filter <ACL> which denies and permits who can form a neighborship.
Yep. It's another Cisco-ism. Multiple ways to do things. You can do ip multicast boundary to filter multicast traffic of course. But there is also ip igmp access-group as well. This filters based on the multicast groups that is trying to be joined. According to INE, it is more common method. When doing the filter, you can use either standard or extended ACLs. Standard ACLs are used to filter ICMP v1, v2, and v3 receivers. Extended ACLs allow you to filter IGMPv3 reports.
To limit the aggregate number of multicast groups that are joined by receivers that are directly connected, use the ip igmp limit command. This can be done globally or per interface. Basically it limits the amount of mroute states created due to IGMP reports.
The designated querier, one that makes sure someone is still listening, is based on the lowest IP address. The PIM DR is based on the highest IP address. Can't overload one router on the segment. Share the wealth.
Periodic IGMP queries are sent based on the ip igmp query-interval command. If a non-designated router running multicast doesn't hear any membership queries based on the time in the command ip igmp querier-timeout, it will try to become the new designated querier. Without that command, the timeout is two times the query-interval of that same interface with the default being 60 seconds. To shorten leave times, you can configure the ip igmp query-max-response-time so that everyone knows to send responses in a timely manner. The ip igmp last-member-query-interval is how fast special IGMP Leave messages need to be seen to be counted. Nothing else, just put on the interface ip igmp immediate-leave with and ACL and that interface no longer cares about multicast once it gets a Leave message.
Steps to make a multicast helper map
1) Set up a multicast network between the two broadcast domains
2) Enable broadcast forwarding on the ingress router to the multicast network with ip forward-protocol
3) On the ingress router to the multicast network, at the interface connecting to the broadcast domain, enter the ip multicast helper-map broadcast command. The ACL for this command has to be extended for the UDP matching.
4) Enable broadcast forwarding on the multicast network egress router with ip forward-protocol as well as put ip multicast helper-map on the interface connected to the multicast network. Again the ACL has to be extended.
5) Enable directed-broadcast on the interface connected to the broadcast network on the egress router. Can also specify a different broadcast address with ip broadcast-address
You can test helper maps with DNS. Enable DNS name resolution on the first broadcast network and don't enter a DNS server. The router will eventually broadcast for 255.255.255.255 and if the ACL for the helper map is any any or specific for that entry, then it gets hit. You can also use an extended traceroute.
When enabling bidirectional PIM, make sure that you enable bi-directional PIM with ip pim bidir-enable. Also learned that the rp-candidate command is particular about its options. Contrary to what the documentation says about the placement of the group-list option in relation to the bidir option, the bidir option has to come last.
When setting up source specific multicast, you don't need an RP if that is all you are doing. The receiver (ip igmp join-group <group> source <source>) and everyone in between builds the shortest path to the source based on the source specified. SSM also uses either the default range (232.0.0.0/8) or can be given a range with an ACL. No shared trees are used for either range and (*,G) joins are dropped. IGMP version 3 only has to be enabled on the receiving interface. Not on all.
To be able to exchange multicast traffic between two different ASs, you need to do the following:
1) Turn on PIM between the two ASs. PIM SM is most common. Limit BSR/AutoRP leaks.
2) Exchange route information using a routing protocol. BGP is most common since it has an extension for this.
When applying the multicast address-family to BGP, make sure to activate all neighbors. Without this, not everyone is going to know about multicast routes. You can also use pre-pending to manipulate routes. If allowed, redistribute the IGP into the multicast address-family for help with RPF checks and routing.
After some initial headaches with finding a Layer 2 image in IOU that does IGMP snooping, I just hit the same problem with MVR (Multicast VLAN Registration). Just beautiful. Anyways, on to MVR. There are four basic steps to configure MVR.
1) Enable it with mvr and mvr group <multicast-group>
2) Set the MVR VLAN with mvr vlan <vlan-id>. This is the VLAN that carries all the multicast traffic and spans all the switches. Feel free to define the mode here as well.
3) Tell the switch what the sending and receiving interfaces are with mvr type <source|receiver> at the interface level.
4) Optionally, create a static group join with mvr vlan <vlan-id> group <ip-address>. This is done on the receiving ports.
IGMP profiles are another one that I cannot do in IOU/IOL. That is fine. I think that I have it figured out. IGMP profiles are for when you want to permit and deny at the switch level. It looks a lot like named ACLs but with numbers instead of a name. I do like the hierarchical way of configuring things. You apply the profile to the interface with ip igmp filter #.
IPSec VPNS and DMVPNS
Finally got to do some DMVPN stuff and I have to say, it ain't so bad. It truly reminds me a lot of Frame Relay. I didn't mind FR. I kinda miss it. But then I am a little off when it comes to technology. :) Well, enough rambling. On to my notes.
To make IPSec tunnels be robust off two interfaces, use crypto map <name> local-address <inteface>. This will allow a crypto connection to be made to one location on the device and not drop if an interface dies. Well, not exactly true. Traffic will be routed out the other interface so a couple of packets may disappear but it is automatic and not a manual process. You just have to be sure to use the address on the other side of the tunnel on the peer.
I never really had to create VPNS before. Trying to do this isn't really that bad. From what I understand, you create the ISAKMP policy, which includes the initial encryption, DH group, hash type, and authentication type. Outside of that, you configure the authentication type parameters, with pre-share being super easy. Next, define the IPSec transform-set with encryption and hash types along with a name. Also don't forget to set the mode to tunnel or transport. Configure ACLs to define what traffic is being encrypted with source and destination. Create a crypto map where you set the peer, the transform-set to use, and the traffic ACL. Finally apply that to an external interface and done. This will allow encrypted and unencrypted traffic out of the interface.
When doing GRE over IPSec, have the ACL for the traffic match protocol GRE and apply the crypto map to the external interface and not the tunnel. GRE over IPSec allows the use of dynamic routing protocols. GRE over IPSec also means fewer SAs. More entries in the ACL for traffic to be encrypted means that there are more SAs needed. One for each entry. With GRE over IPSec, there is only one entry for each location and that means one SA per location. Also by default, the DF bit is not copied from the original IP header to the GRE payload to the ESP header. This may cause you to want to lower the MTU on the tunnel. You can also modify the MSS window in TCP with ip tcp adjust-mss <NEW_MSS> to help reduce packet size and decrease fragmentation.
With a crypto map you have to define peers but with a crypto profile, the peer is pulled from the tunnel. Really only seems that you are putting in the crypto commands to secure the information riding in the tunnel. All other transport information is handled by the tunnel. You also don't have to worry about an ACL to specify what traffic is encrypted. If it goes over the tunnel, it gets encrypted.
I was wondering what the difference between a Virtual Tunnel Interface (VTI) and GRE IPSec tunnel was when I first starting seeing the terms in the workbook. The difference is that the VTI is directly encapsulated in ESP and doesn't need another header to move it from place to place. It also ahs a smaller overhead. With GRE and IPSec, to help increase the payload and decrease the overhead, you have to set the IPSec mode to transport. For VTI, you can leave it as tunnel. Another big difference is that VTIs only carry IP. GRE IPSec tunnels can carry just about anything from IS-IS to your momma. Also interesting that the tunnel interface for a VTI accounts for the ESP header in its MTU auto-magically. Do a show interface tunnel# to see it. This also means you don't have to enter the MTU for the tunnel since it is smarter than the average tunnel. Wonder if a VTI also looks for picnic baskets. There is a thought. Still, setting the ip tcp adjust-mss is a good idea.
DMVPNs aren't really all that scary. At first, I was thinking that with the dynamic nature of them and the encryption, that it was super tough. They really aren't. Set the spokes to point to the NHS (hub) and agree on NHRP authentication, GRE tunnel key number, and whether or not multicast will be used. After that check the hub for registrations and voila. Use show dmvpn and show ip nhrp for verification.
By default multicast is not used within DMVPN tunnels. You have to turn it on with the ip nhrp map multicast command. On the spokes, you put in the "external" IP of the hub. At the hub, you add the word dynamic. Think of doing this like adding the word broadcast to that wonderful protocol called Frame Relay. Also multicast packets are not replicated to other spokes. No spoke to spoke there people.
So what I am gathering is that DMVPN has phases. Phase 1 is spoke to hub only and not good for a lot of traffic going spoke to spoke. Phases 2 and 3 are where traffic can go from spoke to spoke. Phase 2 is where traffic goes from spoke to spoke via asking the hub where each spoke is located. Route updates are sent to the spokes with the next-hop unchanged. Phase 3 is where the spokes respond to NHRP resolution requests.
When creating a DMVPN with IPSec and you want to make it so that the spokes only securely talk with the hub, set the crypto isakmp key to the external tunnel interface. For the hub, you can set it to 0.0.0.0. Gonna have to see if you can enter multiple entries for each spoke. Only problem with that is the hub has to be modified for each spoke added. PKI is the real way to go.
DMVPN uses crypto profiles and crypto maps to add security. If it used maps, it would require the set peer option. Using set peer removes the dynamic portion of DMVPN. Also setting the mode to Transport over Tunnel saves overhead by not encapsulating a header with another header. To make sure that the DMVPN is working, check the hub has ISAKMP and IPSec SAs for each spoke. Only after IPSec connections are made are the NHRP connections made and can be checked.
To do DMVPN Phase 1 with EIGRP, set up the hub like before but the spokes are now going to get tunnel destination and take out tunnel mode gre multipoint. This makes sure that the spokes don't talk with each other and that all traffic goes through the hub. The hub is king in Phase 1.
When doing DMVPN with OSPF, there are three choices. One is to make the hub point-to-multipoint and change the hello-interval to match the spokes. Two is the change the hub to point-to-multipoint and change the spokes' hello-interval to match the hub. Three is to make the hub and spokes all point-to-multipoint OSPF type. The third option cannot be used in Phase 1. The hub always has to be point-to-multipoint. By default tunnel interfaces are point-to-point. Again, sounds more and more like Frame Relay. Frame Relay, my old friend, you come around, again and again.
To do DMVPN Phase 2, two key criteria have to be met. One is that the hub doesn't do any summarization. When done, the next hop is changed to the hub so the spoke sends it there. That brings in key point 2, which is that the next hop cannot be changed. Again, if the next-hop is changed then, all traffic goes to the new next-hop. Other interesting fact with DMVPN Phase 2 is that adjacencies are only formed from the spokes to the hub. No spoke to spoke adjacencies are there. Again, sounds more and more like Frame Relay.
To make IPSec tunnels be robust off two interfaces, use crypto map <name> local-address <inteface>. This will allow a crypto connection to be made to one location on the device and not drop if an interface dies. Well, not exactly true. Traffic will be routed out the other interface so a couple of packets may disappear but it is automatic and not a manual process. You just have to be sure to use the address on the other side of the tunnel on the peer.
I never really had to create VPNS before. Trying to do this isn't really that bad. From what I understand, you create the ISAKMP policy, which includes the initial encryption, DH group, hash type, and authentication type. Outside of that, you configure the authentication type parameters, with pre-share being super easy. Next, define the IPSec transform-set with encryption and hash types along with a name. Also don't forget to set the mode to tunnel or transport. Configure ACLs to define what traffic is being encrypted with source and destination. Create a crypto map where you set the peer, the transform-set to use, and the traffic ACL. Finally apply that to an external interface and done. This will allow encrypted and unencrypted traffic out of the interface.
When doing GRE over IPSec, have the ACL for the traffic match protocol GRE and apply the crypto map to the external interface and not the tunnel. GRE over IPSec allows the use of dynamic routing protocols. GRE over IPSec also means fewer SAs. More entries in the ACL for traffic to be encrypted means that there are more SAs needed. One for each entry. With GRE over IPSec, there is only one entry for each location and that means one SA per location. Also by default, the DF bit is not copied from the original IP header to the GRE payload to the ESP header. This may cause you to want to lower the MTU on the tunnel. You can also modify the MSS window in TCP with ip tcp adjust-mss <NEW_MSS> to help reduce packet size and decrease fragmentation.
With a crypto map you have to define peers but with a crypto profile, the peer is pulled from the tunnel. Really only seems that you are putting in the crypto commands to secure the information riding in the tunnel. All other transport information is handled by the tunnel. You also don't have to worry about an ACL to specify what traffic is encrypted. If it goes over the tunnel, it gets encrypted.
I was wondering what the difference between a Virtual Tunnel Interface (VTI) and GRE IPSec tunnel was when I first starting seeing the terms in the workbook. The difference is that the VTI is directly encapsulated in ESP and doesn't need another header to move it from place to place. It also ahs a smaller overhead. With GRE and IPSec, to help increase the payload and decrease the overhead, you have to set the IPSec mode to transport. For VTI, you can leave it as tunnel. Another big difference is that VTIs only carry IP. GRE IPSec tunnels can carry just about anything from IS-IS to your momma. Also interesting that the tunnel interface for a VTI accounts for the ESP header in its MTU auto-magically. Do a show interface tunnel# to see it. This also means you don't have to enter the MTU for the tunnel since it is smarter than the average tunnel. Wonder if a VTI also looks for picnic baskets. There is a thought. Still, setting the ip tcp adjust-mss is a good idea.
DMVPNs aren't really all that scary. At first, I was thinking that with the dynamic nature of them and the encryption, that it was super tough. They really aren't. Set the spokes to point to the NHS (hub) and agree on NHRP authentication, GRE tunnel key number, and whether or not multicast will be used. After that check the hub for registrations and voila. Use show dmvpn and show ip nhrp for verification.
By default multicast is not used within DMVPN tunnels. You have to turn it on with the ip nhrp map multicast command. On the spokes, you put in the "external" IP of the hub. At the hub, you add the word dynamic. Think of doing this like adding the word broadcast to that wonderful protocol called Frame Relay. Also multicast packets are not replicated to other spokes. No spoke to spoke there people.
So what I am gathering is that DMVPN has phases. Phase 1 is spoke to hub only and not good for a lot of traffic going spoke to spoke. Phases 2 and 3 are where traffic can go from spoke to spoke. Phase 2 is where traffic goes from spoke to spoke via asking the hub where each spoke is located. Route updates are sent to the spokes with the next-hop unchanged. Phase 3 is where the spokes respond to NHRP resolution requests.
When creating a DMVPN with IPSec and you want to make it so that the spokes only securely talk with the hub, set the crypto isakmp key to the external tunnel interface. For the hub, you can set it to 0.0.0.0. Gonna have to see if you can enter multiple entries for each spoke. Only problem with that is the hub has to be modified for each spoke added. PKI is the real way to go.
DMVPN uses crypto profiles and crypto maps to add security. If it used maps, it would require the set peer option. Using set peer removes the dynamic portion of DMVPN. Also setting the mode to Transport over Tunnel saves overhead by not encapsulating a header with another header. To make sure that the DMVPN is working, check the hub has ISAKMP and IPSec SAs for each spoke. Only after IPSec connections are made are the NHRP connections made and can be checked.
To do DMVPN Phase 1 with EIGRP, set up the hub like before but the spokes are now going to get tunnel destination and take out tunnel mode gre multipoint. This makes sure that the spokes don't talk with each other and that all traffic goes through the hub. The hub is king in Phase 1.
When doing DMVPN with OSPF, there are three choices. One is to make the hub point-to-multipoint and change the hello-interval to match the spokes. Two is the change the hub to point-to-multipoint and change the spokes' hello-interval to match the hub. Three is to make the hub and spokes all point-to-multipoint OSPF type. The third option cannot be used in Phase 1. The hub always has to be point-to-multipoint. By default tunnel interfaces are point-to-point. Again, sounds more and more like Frame Relay. Frame Relay, my old friend, you come around, again and again.
To do DMVPN Phase 2, two key criteria have to be met. One is that the hub doesn't do any summarization. When done, the next hop is changed to the hub so the spoke sends it there. That brings in key point 2, which is that the next hop cannot be changed. Again, if the next-hop is changed then, all traffic goes to the new next-hop. Other interesting fact with DMVPN Phase 2 is that adjacencies are only formed from the spokes to the hub. No spoke to spoke adjacencies are there. Again, sounds more and more like Frame Relay.
07 September 2014
MPLS or Major Protocol Looking Suite
I was running through the MPLS section of the INE workbook. Nothing too major at first and then the fun started. I have to say, I kinda like MPLS. It has this funny way of looking all sweet and innocent and then biting you on the buttocks with all the underlying complexity. Anyways, on to my lessons learned and things I found fun or interesting.
So when running VRF Lite, you can do a static route from one VRF to another through the use of ip route vrf and stating the interface the traffic will flow out of. This can get cumbersome in some situations but in others, it is fine for a few small fine tunings. Think small deployments. Large deployments and static routes just suck.
When configuring MPLS LDP and you want to use the physical interface IP as the transport IP, use the command mpls ldp discovery transport address interface in config-if or subif mode. Or if nothing else you can just state the IP. Good for when not having the IGP send out the loopbacks or just to be different. :)
With MPLS, not only configure MPLS globally but it is good to also do it on each interface with mpls ip. If using OSPF and say you want it enabled on all the OSPF interfaces, use the command mpls ldp autoconfig under the OSPF process.
So I keep forgetting that when I set up MP-BGP, you have to source it from the loopback and it has to have a /32 subnet-mask. Crap. Also need to realize the routes are to be redistributed with either static or connected. Combine that with not sending communities and well I just jacked up that config horribly. I was right in my thinking, just not in the execution. I just need to get the steps correct now.
When using export maps, set the export route-targets based on the prefixes as wanted and then if there is a default target, don't forget to use a match any statement. Think of it as the catch all.
So, you want OSPF rouutes traveling across the MP-BGP to be recognized on the far side as external. No worries. Configure the PEs in different OSPF domains. This will force the routes to be external. Also if the routes are being blackholed., look at turning on capability vrf-lite which will cause the routes to not look at the down bit.
For an OSPF sham-link, the interface is usually a loopback for the source and destination and has to be known in the VRF. You can advertise this into BGP directly on the PE, since it is a good idea to advertise these into the VRF with a method other than OSPF. Good ole network statement in BGP address-family for the vrf.
Site of Origin is a filtering technique for when a network is multi-homed. When using it, you don't have to use EIGRP route tags and BGP communities to filter routes. You configure it with a route-map that sets the extcommunity soo value to ASN:XX. That route map is applied at the interface level via ip vrf sitemap <ROUTE_MAP>. Now as the route leaves a router, it is tagged and if the router sees it again or a route with the same SoO, it drops it. This is a lot like using route tags but with a lot less work. Don't apply it on the MPLS links. Apply it on the links to the customer site and the links for the backbone. That way all routes that enter and leave that interface are checked. Also a router doesn't ahve to be running VRF to use the sitemap command.
There are two ways to apply a sitemap. One is on the PE interface facing the CE routers using the same SoO on every PE router. Doing this does not allow the MPLS core to be used as a backup between sites. The second way is to apply different SoO values at every PE router. I like the idea of using the same SoO value at each site becaue then you make sure that the route doesn't get put back in at the same location but still allow the use of all links.
With BGP SoO, you configure it per neighbor on the PE router. It is used to prevent routing loops in a multi-homed scenario. Hmm... What does this sound like? Maybe EIGRP SoO. You can do it via route-maps and neighbor route-map commands but to me neighbor soo is much more elegant. You can use a different value on each PE to the CE and then the CEs can match their respective PEs to each other. Keeps the backdoor link a backdoor and allows full route table "respect". If you disrespect the route table, it will make loops that will drive you insane. And if you want to see how many prefixes are getting filtered via SoO, look in the neighbor information under BGP (show bgp vpnv4 unicast vrf <NAME> <NEIGHBOR>). It will list the SoO loop information.
So you have this MPLS cloud connecting multiple sites to each other. Great. Awesome. How about Internet? There are two ways to get the routes to the users for Internet access. You can set the connection to the Internet as a VRF and import and export the routes using route-targets for one. That works pretty easy. Path 2 is to have the Internet connected to the global route table and then create static routes for the VRFs. Easiest way is to the it with the default route for the VRF pointed to the global table and interface. You may then need to do NAT on the addresses as they go out if they are private. I like the VRF method. Just seesm easier and I am all about that.
Think that MPLS MP-BGP is fast? Want it to go faster? There are three factors for how the speed is affected.
1) Time for an IGP update to be redistributed into BGP. This is more event-driven now in newer code, so it is nearly instantaneous.
2) Time to send updates to peers. This can be done faster with setting the neighbor advertisement-interval to 0. This will send the updates not and not wait for a batch job. For newer code, this is the default. Still, I like to be explicit.
3) Time needed to import MP-BGP VPNv4 prefixes into the local table. You can use bgp scan-time under the VPNv4 address-family but that is deprecated. Instead, you can use import path selection all under the vrf address-family in BGP.
So when running VRF Lite, you can do a static route from one VRF to another through the use of ip route vrf and stating the interface the traffic will flow out of. This can get cumbersome in some situations but in others, it is fine for a few small fine tunings. Think small deployments. Large deployments and static routes just suck.
When configuring MPLS LDP and you want to use the physical interface IP as the transport IP, use the command mpls ldp discovery transport address interface in config-if or subif mode. Or if nothing else you can just state the IP. Good for when not having the IGP send out the loopbacks or just to be different. :)
With MPLS, not only configure MPLS globally but it is good to also do it on each interface with mpls ip. If using OSPF and say you want it enabled on all the OSPF interfaces, use the command mpls ldp autoconfig under the OSPF process.
So I keep forgetting that when I set up MP-BGP, you have to source it from the loopback and it has to have a /32 subnet-mask. Crap. Also need to realize the routes are to be redistributed with either static or connected. Combine that with not sending communities and well I just jacked up that config horribly. I was right in my thinking, just not in the execution. I just need to get the steps correct now.
When using export maps, set the export route-targets based on the prefixes as wanted and then if there is a default target, don't forget to use a match any statement. Think of it as the catch all.
So, you want OSPF rouutes traveling across the MP-BGP to be recognized on the far side as external. No worries. Configure the PEs in different OSPF domains. This will force the routes to be external. Also if the routes are being blackholed., look at turning on capability vrf-lite which will cause the routes to not look at the down bit.
For an OSPF sham-link, the interface is usually a loopback for the source and destination and has to be known in the VRF. You can advertise this into BGP directly on the PE, since it is a good idea to advertise these into the VRF with a method other than OSPF. Good ole network statement in BGP address-family for the vrf.
Site of Origin is a filtering technique for when a network is multi-homed. When using it, you don't have to use EIGRP route tags and BGP communities to filter routes. You configure it with a route-map that sets the extcommunity soo value to ASN:XX. That route map is applied at the interface level via ip vrf sitemap <ROUTE_MAP>. Now as the route leaves a router, it is tagged and if the router sees it again or a route with the same SoO, it drops it. This is a lot like using route tags but with a lot less work. Don't apply it on the MPLS links. Apply it on the links to the customer site and the links for the backbone. That way all routes that enter and leave that interface are checked. Also a router doesn't ahve to be running VRF to use the sitemap command.
There are two ways to apply a sitemap. One is on the PE interface facing the CE routers using the same SoO on every PE router. Doing this does not allow the MPLS core to be used as a backup between sites. The second way is to apply different SoO values at every PE router. I like the idea of using the same SoO value at each site becaue then you make sure that the route doesn't get put back in at the same location but still allow the use of all links.
With BGP SoO, you configure it per neighbor on the PE router. It is used to prevent routing loops in a multi-homed scenario. Hmm... What does this sound like? Maybe EIGRP SoO. You can do it via route-maps and neighbor route-map commands but to me neighbor soo is much more elegant. You can use a different value on each PE to the CE and then the CEs can match their respective PEs to each other. Keeps the backdoor link a backdoor and allows full route table "respect". If you disrespect the route table, it will make loops that will drive you insane. And if you want to see how many prefixes are getting filtered via SoO, look in the neighbor information under BGP (show bgp vpnv4 unicast vrf <NAME> <NEIGHBOR>). It will list the SoO loop information.
So you have this MPLS cloud connecting multiple sites to each other. Great. Awesome. How about Internet? There are two ways to get the routes to the users for Internet access. You can set the connection to the Internet as a VRF and import and export the routes using route-targets for one. That works pretty easy. Path 2 is to have the Internet connected to the global route table and then create static routes for the VRFs. Easiest way is to the it with the default route for the VRF pointed to the global table and interface. You may then need to do NAT on the addresses as they go out if they are private. I like the VRF method. Just seesm easier and I am all about that.
Think that MPLS MP-BGP is fast? Want it to go faster? There are three factors for how the speed is affected.
1) Time for an IGP update to be redistributed into BGP. This is more event-driven now in newer code, so it is nearly instantaneous.
2) Time to send updates to peers. This can be done faster with setting the neighbor advertisement-interval to 0. This will send the updates not and not wait for a batch job. For newer code, this is the default. Still, I like to be explicit.
3) Time needed to import MP-BGP VPNv4 prefixes into the local table. You can use bgp scan-time under the VPNv4 address-family but that is deprecated. Instead, you can use import path selection all under the vrf address-family in BGP.
04 September 2014
My BGP Experience and Thoughts and Overall Screaming at Myself
So after working the BGP labs from INE, I came across some gotchas, some oh crap moments, and some what the hell was I thinking. Below are those times so that I can relive them over and over.
BGP auto-summarization only happens if there is a network command with a classful subnet or if prefixes are redistributed into BGP. With the network statement, the aggregate is installed into the BGP table if there is a subnet of the prefix in the IGP table. Also auto-summarized routes do not have the aggregator or atomic aggregator attributes in them. This happens because of where the summarization is is performed. It does it on the IGP prefixes and not the BGP prefixes.
Best-path selection excludes some prefixes based on certain criteria:
1. No valid next-hop. If you can't get to the next-hop, how can it be the best-path. Duh. That is hy for eBGP neighbors, you may want to include next-hop-self
2. BGP synchronization is enabled and the prefix is not found in the IGP table. Basic synchronization there. Thank goodness it is off by default.
3. The received prefix has your AS number. Must have come from you so goodbye.
BGP best-path looks at the following list to determine what is a better way to send that prefix out.
1. Ignore paths that don't work. See above list.
2. Highest weight. (Time where more weight is a good thing).
3. Highest local preference
4. Locally originated prefixes. Come in by network, aggregate-address, or redistribution commands.
5. Shortest AS-Path.
6. Lowest Origin Type code where IGP < EGP < Incomplete
7. Lowest MED, so long as the first AS is the same
8. External BGP routes over Internal BGP routes
9. Smallest IGP metric to next-hop
10. Lowest BGP originating router-id
By default MED is only compared when the prefix is received from the same AS. If the prefix comes from into you from AS 54 and 55, then it won't be used. But if they both list AS 54 as the first AS, then it can be.
You can route based on the IGP or the MED. If you use the IGP, that is "hot potato" routing and "cold potato" routing using the MED. With the IGP, you want that traffic away from you as soon as possible. With MED, you are willing to hold onto it a little longer.
If a path contains route reflector attributes (Originator-ID, Cluster-ID), the originator ID is substituted for the router ID in the path selection process. But if you make it this far down the list for the best-selection, then wow. That is one heck of a selection.
So, you have prefixes that are failing to show up in the route table. You check the BGP table and you see that there are RIB failures. Why? Well, there is a command to see why. Use show bgp ipv4 unicast rib-failure and it will out put the following (or something close):
R1#show bgp ipv4 unicast rib-failure
Network Next Hop RIB-failure RIB-NH Matches
150.1.77.0/24 155.1.13.3 Higher admin distance n/a
So, I had a major brain fart. I had to aggregate some routes. No issue, right? Do aggregate-address under the BGP process and all is good? Nope. I did a stupid mistake and forgot about getting the routes into to the BGP table first. Doh!!
There are routes coming into your router or your AS that have communities set. You want a clean slate. Under a route-map use set community none. I was trying to use a no set community no-export. That didn't work.
The advertise-map option of aggregate-address is for showing what prefixes are added to an aggregate.
I got so focused in setting community-lists that I forgot about the comm-list delete option for set in a route-map. Gotta read my command options more carefully in the documentation.
Conditional advertisements come from using an advertise-map with a neighbor statement. They can either be for as long as a prefix exists, broadcast this; or when this doesn't exist, broadcast this.
A BGP inject-map requires two route-maps. One to show what is being injected with any parameters as well. This is done with a set ip address prefix-list. The second route-map includes the match for the aggregated address with a match ip address prefix-list and the second requirement of a match ip route-source prefix-list, which matches where the aggregation originated from. This is not the next-hop but the aggregation origination. This source can change when moving from iBGP to eBGP. Inject maps are great for deconstructing an aggregation.
Filtering with BGP is applied in two different orders depending on the direction, inbound or outbound. Inbound does route-map, filter-list, prefix-list/distribution/list. Outbound does prefix-list/distribution-list, filter-list, and route-map.
So with the no-prepend option of neighbor local-as, the old AS is not prepended to the AS list. The new AS, the one configured with router bgp <AS>, is. This helps so that you can run a new AS number on your borders and run the old AS number internally until everyone is moved over. Without this, the internal routers would reject the route. This also only applies to inbound routes. All external routes have the old AS and the new AS prepended to the them.
Using the replace-as option with the no-prepend option of neighbor local-as, allows the router to replace all instances of the new AS number with the old one. This allows the new AS number to be hidden from the outside world.
The command bgp scan-time is used to adjust the amount of time that BGP process allows before initiating a scan of the BGP routing information. INE used it in their lab talking about the amount of time that the BGP process will wait to process a conditional route advertisement. I was looking for the advertisement coming in and they were talking about it going out. The defautl is 60 seconds.
Outbound route filtering (ORF) has to be applied using neighbor prefix-list in. Needs to be done once the capability has been enabled.
BGP ttl-security needs to be set the same on both sides of a link to make sure that the links stay secure and expect the same value. Also you can use it or ebgp-multihop but not both for the same neighbor.
The neighbor allowas-in is not in the BGP command-list. It is in the MPLS section instead. Makes sense when you think about it. The option is for discontinuous systems and that can happen easily with an MPLS backbone.
BGP auto-summarization only happens if there is a network command with a classful subnet or if prefixes are redistributed into BGP. With the network statement, the aggregate is installed into the BGP table if there is a subnet of the prefix in the IGP table. Also auto-summarized routes do not have the aggregator or atomic aggregator attributes in them. This happens because of where the summarization is is performed. It does it on the IGP prefixes and not the BGP prefixes.
Best-path selection excludes some prefixes based on certain criteria:
1. No valid next-hop. If you can't get to the next-hop, how can it be the best-path. Duh. That is hy for eBGP neighbors, you may want to include next-hop-self
2. BGP synchronization is enabled and the prefix is not found in the IGP table. Basic synchronization there. Thank goodness it is off by default.
3. The received prefix has your AS number. Must have come from you so goodbye.
BGP best-path looks at the following list to determine what is a better way to send that prefix out.
1. Ignore paths that don't work. See above list.
2. Highest weight. (Time where more weight is a good thing).
3. Highest local preference
4. Locally originated prefixes. Come in by network, aggregate-address, or redistribution commands.
5. Shortest AS-Path.
6. Lowest Origin Type code where IGP < EGP < Incomplete
7. Lowest MED, so long as the first AS is the same
8. External BGP routes over Internal BGP routes
9. Smallest IGP metric to next-hop
10. Lowest BGP originating router-id
By default MED is only compared when the prefix is received from the same AS. If the prefix comes from into you from AS 54 and 55, then it won't be used. But if they both list AS 54 as the first AS, then it can be.
You can route based on the IGP or the MED. If you use the IGP, that is "hot potato" routing and "cold potato" routing using the MED. With the IGP, you want that traffic away from you as soon as possible. With MED, you are willing to hold onto it a little longer.
If a path contains route reflector attributes (Originator-ID, Cluster-ID), the originator ID is substituted for the router ID in the path selection process. But if you make it this far down the list for the best-selection, then wow. That is one heck of a selection.
So, you have prefixes that are failing to show up in the route table. You check the BGP table and you see that there are RIB failures. Why? Well, there is a command to see why. Use show bgp ipv4 unicast rib-failure and it will out put the following (or something close):
R1#show bgp ipv4 unicast rib-failure
Network Next Hop RIB-failure RIB-NH Matches
150.1.77.0/24 155.1.13.3 Higher admin distance n/a
So, I had a major brain fart. I had to aggregate some routes. No issue, right? Do aggregate-address under the BGP process and all is good? Nope. I did a stupid mistake and forgot about getting the routes into to the BGP table first. Doh!!
There are routes coming into your router or your AS that have communities set. You want a clean slate. Under a route-map use set community none. I was trying to use a no set community no-export. That didn't work.
The advertise-map option of aggregate-address is for showing what prefixes are added to an aggregate.
I got so focused in setting community-lists that I forgot about the comm-list delete option for set in a route-map. Gotta read my command options more carefully in the documentation.
Conditional advertisements come from using an advertise-map with a neighbor statement. They can either be for as long as a prefix exists, broadcast this; or when this doesn't exist, broadcast this.
A BGP inject-map requires two route-maps. One to show what is being injected with any parameters as well. This is done with a set ip address prefix-list. The second route-map includes the match for the aggregated address with a match ip address prefix-list and the second requirement of a match ip route-source prefix-list, which matches where the aggregation originated from. This is not the next-hop but the aggregation origination. This source can change when moving from iBGP to eBGP. Inject maps are great for deconstructing an aggregation.
Filtering with BGP is applied in two different orders depending on the direction, inbound or outbound. Inbound does route-map, filter-list, prefix-list/distribution/list. Outbound does prefix-list/distribution-list, filter-list, and route-map.
So with the no-prepend option of neighbor local-as, the old AS is not prepended to the AS list. The new AS, the one configured with router bgp <AS>, is. This helps so that you can run a new AS number on your borders and run the old AS number internally until everyone is moved over. Without this, the internal routers would reject the route. This also only applies to inbound routes. All external routes have the old AS and the new AS prepended to the them.
Using the replace-as option with the no-prepend option of neighbor local-as, allows the router to replace all instances of the new AS number with the old one. This allows the new AS number to be hidden from the outside world.
The command bgp scan-time is used to adjust the amount of time that BGP process allows before initiating a scan of the BGP routing information. INE used it in their lab talking about the amount of time that the BGP process will wait to process a conditional route advertisement. I was looking for the advertisement coming in and they were talking about it going out. The defautl is 60 seconds.
Outbound route filtering (ORF) has to be applied using neighbor prefix-list in. Needs to be done once the capability has been enabled.
BGP ttl-security needs to be set the same on both sides of a link to make sure that the links stay secure and expect the same value. Also you can use it or ebgp-multihop but not both for the same neighbor.
The neighbor allowas-in is not in the BGP command-list. It is in the MPLS section instead. Makes sense when you think about it. The option is for discontinuous systems and that can happen easily with an MPLS backbone.
Back to Labbing
It felt so good to be labbing again. I missed it. Started back where I needed to with INE's workbook and watched videos from iPexpert. Kinda missed labbing. But I am hitting it now. I finished out the BGP section and I am working on MPLS. I have to go back and hit the Redistribution section but that can wait until the rest of the book is done. My goal is to finish the individual sections, go to Cisco Press's book, move to iPexpert and INE full labs, and then take the bootcamp in December. After that I plan to study as I can over Christmas and then take the test towards the end of January. Heck of a plan. We will see what happens.
28 July 2014
Still Going
So I haven't posted anything lately I know. I have had to take a couple weeks off of studying for personal and work events. I moved 900 miles from my old location to a new one. Had to knock out one Aruba cert and working on another. Had to reset up my lab and remote access as well. Lots to work on. Hoping that by the end of this week I can get it all fleshed out and get back to working on studying. Guess we will see.
01 July 2014
BGP Part 1
Well with work and my upcoming move, I will post when I can about what I get done. Some posts may be far and in between but I will be doing what I can. Also for work I have to study for the Aruba Certified Mobility Associate (ACMA) and pass it as well in the next two weeks. Well, enough belly-aching. On to the fun stuff.
Most engineers know about the ebgp-multihop option for the neighbor command in BGP but there is also the disable-connected-check option as well. What I understand about this option is that it is used when you are peering with a device that is directly connected but you are not using the next-hop interface. Think about peering with the loopback of the remote device. The updates are still sent out with a TTL of 1 but the router with the option doesn't worry about it since it can tell that the router is directly connected. This can be seen if you simulate a failure and the packets are routed over a third router. The third router drops the updates since the TTL is 1. Can be usA ned when you want to peer with a router's loopback but want to make sure that the device is only peering over a direct connection.
When using route-reflectors, clusters are formed, but what is a cluster? A cluster is the router reflector and its clients. A nice way to talk about 2 to the n number of routers.
Route reflectors have the following rules when it comes to sending updates:
BGP confederation AS_CONFED_SET is only seen as one AS. This means that sometimes the straightest path is not always chosen. AS_CONFED_SET (65437 65238) can be chosen over AS_CONFED_SET (65186) if the router-id is lower on the advertising router for the longer set. This can possibly lead to sub-optimal routing.
With synchronization, a route is not eligible to be used or advertised unless it is known by the IGP and in the routing table. That means that for external routes, you have to redistribute the routes from the eBGP borders to the IGP routers. Without doing that, BGP cannot use the route. Well, there is another option and that would be to create static routes on the router and that will add the route to the routing table but would you really want to do that?
RIB-failures in BGP are when there is a path that can be used via Best-Path Selection but cannot be installed in the routing table because there is a static or IGP route with a lower administrative distance. By default, these routes can still be advertised to other neighbors. If the command bgp suppress-inactive is used then RIB-failure routes are not advertised.
When redistributing from BGP to an IGP, by default only eBGP routes are redistributed. To redistribute iBGP routes, you have to use the bgp redistribute-internal command. This can cause routing loops so the administrative distances may need to be adjusted on some router's IGPs to combat this.
Most engineers know about the ebgp-multihop option for the neighbor command in BGP but there is also the disable-connected-check option as well. What I understand about this option is that it is used when you are peering with a device that is directly connected but you are not using the next-hop interface. Think about peering with the loopback of the remote device. The updates are still sent out with a TTL of 1 but the router with the option doesn't worry about it since it can tell that the router is directly connected. This can be seen if you simulate a failure and the packets are routed over a third router. The third router drops the updates since the TTL is 1. Can be usA ned when you want to peer with a router's loopback but want to make sure that the device is only peering over a direct connection.
When using route-reflectors, clusters are formed, but what is a cluster? A cluster is the router reflector and its clients. A nice way to talk about 2 to the n number of routers.
Route reflectors have the following rules when it comes to sending updates:
- routes learned form eBGP can be sent to eBGP peers, reflector clients, and non-clients
- routes learned from reflector clients can be sent to eBGP peers, other reflector clients, and non-clients
- routes learned from non-client peers can be sent to eBGP peers and reflector clients
- they CANNOT be sent to non-clients
BGP confederation AS_CONFED_SET is only seen as one AS. This means that sometimes the straightest path is not always chosen. AS_CONFED_SET (65437 65238) can be chosen over AS_CONFED_SET (65186) if the router-id is lower on the advertising router for the longer set. This can possibly lead to sub-optimal routing.
With synchronization, a route is not eligible to be used or advertised unless it is known by the IGP and in the routing table. That means that for external routes, you have to redistribute the routes from the eBGP borders to the IGP routers. Without doing that, BGP cannot use the route. Well, there is another option and that would be to create static routes on the router and that will add the route to the routing table but would you really want to do that?
RIB-failures in BGP are when there is a path that can be used via Best-Path Selection but cannot be installed in the routing table because there is a static or IGP route with a lower administrative distance. By default, these routes can still be advertised to other neighbors. If the command bgp suppress-inactive is used then RIB-failure routes are not advertised.
When redistributing from BGP to an IGP, by default only eBGP routes are redistributed. To redistribute iBGP routes, you have to use the bgp redistribute-internal command. This can cause routing loops so the administrative distances may need to be adjusted on some router's IGPs to combat this.
24 June 2014
OSPF
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.
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.
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.
28 May 2014
Static Routes
Interesting fun tonight with static routes. I started working the INE labs for routing and realized some fun stuff. One, I forgot about proxy ARP. I forgot that when you set a static route out a multi-access broadcast interface such as Ethernet, it is better to set the next-hop as the IP address and not the exiting interface. With proxy ARP and going to a router that is on the same segment, it is no problem since the far-end router will respond. Without proxy ARP, the far-end router won't respond and the local router won't know what to do. Way to beat this is to add a static ARP entry on the local router. Ah, the little things.
Next fun thing was when using the exit interface on a static route is good and not good with DMVPN. Didn't realize that if you specify the tunnel interface on the hub router, it won't work because it can't query itself as the NHS to find the NBMA to send the inner traffic. The spokes are good like this since they can query the hub/NHS. How to fix this you ask? Well there are two ways. Specify the next hop IP address in the static route or create NHRP maps on the hub tunnel interface that matches the inner and outer address. That is good to know because I can see this being a ticket in the troubleshooting section.
Next fun thing was when using the exit interface on a static route is good and not good with DMVPN. Didn't realize that if you specify the tunnel interface on the hub router, it won't work because it can't query itself as the NHS to find the NBMA to send the inner traffic. The spokes are good like this since they can query the hub/NHS. How to fix this you ask? Well there are two ways. Specify the next hop IP address in the static route or create NHRP maps on the hub tunnel interface that matches the inner and outer address. That is good to know because I can see this being a ticket in the troubleshooting section.
27 May 2014
INE CCIE R&S v5 Labs
I have had the INE v5 material downloaded now for a little over a week or two and haven't done anything with it. I was waiting to see if any more guidance came out on the initial configuration and also to see if any more changes happened. Well, it seems that things are settled so I figured that it was time to start getting my lab ready.
The first thing that I noticed is that the topology really doesn't need any switches if you are only looking at Layer 3 technologies. So, what I am doing is creating a base network in GNS3 with 20 routers running on 15.2(4)S3 code. I have them going to a "dumb" layer 2 ethernet switch where all the ports are dot1q trunks. Also off that switch is a connection to my NIC so that I can go to real switches but that is for when I do Layer 2 more than anything.
I was used to the old setup from them, one of their competitors, and even the IE test itself where routers went to switches. Not having that is a little awkward for me and I was trying to get more guidance. I realized though that this is something I can finish worrying about later and for now just work on the technology itself.
I am in the process of updating all the initial configurations to work in my lab. Thinking that I will dust off my Perl knowledge and knock that out so that they can come back later with new configs and I won't be losing hours doing more updates.
I have thus far only done one of the labs from the new workbook and I am indifferent. Not sure I like the no Layer 2 stuff but then this is a technology based workbook it feels like so I can't really complain too much. Just hoping that there is more to come with full labs that use all of the routers and the switches that I have. Full labs are where the fun stuff is.
When iPexpert officially releases their new material, I will download it and take a look at it and see how that goes. They have released their "base" network diagram and it looks like their v4 diagram. Didn't seem to be updated much at all. Oh, well. Guess I will know more when it comes out.
Here is what my network looks like in GNS3. Pretty simple.
The first thing that I noticed is that the topology really doesn't need any switches if you are only looking at Layer 3 technologies. So, what I am doing is creating a base network in GNS3 with 20 routers running on 15.2(4)S3 code. I have them going to a "dumb" layer 2 ethernet switch where all the ports are dot1q trunks. Also off that switch is a connection to my NIC so that I can go to real switches but that is for when I do Layer 2 more than anything.
I was used to the old setup from them, one of their competitors, and even the IE test itself where routers went to switches. Not having that is a little awkward for me and I was trying to get more guidance. I realized though that this is something I can finish worrying about later and for now just work on the technology itself.
I am in the process of updating all the initial configurations to work in my lab. Thinking that I will dust off my Perl knowledge and knock that out so that they can come back later with new configs and I won't be losing hours doing more updates.
I have thus far only done one of the labs from the new workbook and I am indifferent. Not sure I like the no Layer 2 stuff but then this is a technology based workbook it feels like so I can't really complain too much. Just hoping that there is more to come with full labs that use all of the routers and the switches that I have. Full labs are where the fun stuff is.
When iPexpert officially releases their new material, I will download it and take a look at it and see how that goes. They have released their "base" network diagram and it looks like their v4 diagram. Didn't seem to be updated much at all. Oh, well. Guess I will know more when it comes out.
Here is what my network looks like in GNS3. Pretty simple.
26 May 2014
DMVPN with RIP
So I took my base network and created a DMVPN network again and this time I ran RIP as the internal routing protocol. Pretty straight forward implementation. Nothing too special about it. Only real gotcha when I configured it was making sure that split horizon was off on the hub tunnel. Next hop on all the routes were correct by default.
The thing that I did notice though about this lab was that there is a potential for trouble shooting and configuration tickets and tasks in the v5 test. One possibility I see is if they make the internal and the external network be a subnet of the same classful network. Something like using 172.16.16.0/24 and 172.16.13.0/24. Both of these in RIP would be advertised with the network 172.16.0.0 command. Filtering would then be used to kill the external routes.
Overall pretty straight forward implementation.
The thing that I did notice though about this lab was that there is a potential for trouble shooting and configuration tickets and tasks in the v5 test. One possibility I see is if they make the internal and the external network be a subnet of the same classful network. Something like using 172.16.16.0/24 and 172.16.13.0/24. Both of these in RIP would be advertised with the network 172.16.0.0 command. Filtering would then be used to kill the external routes.
Overall pretty straight forward implementation.
Subscribe to:
Posts (Atom)