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.
28 May 2014
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.
DMVPN with OSPF
So I re-did my DMVPN lab and this time I used OSPF on the internal network. At first, before the tunnels were built, there was nothing spectacular happening. Even when I built the first tunnel, it all worked pretty good. Issue can when I added the second tunnel. All hell starting happening. The hub was flapping every few seconds. I couldn't figure out why. I thought I messed up and I kinda did and didn't. After some Google searches, I realized that I needed to add ip ospf network point-to-multipoint to the tunnel interfaces. I didn't know that. I checked the network type to start with and there was the issue. All the tunnels were point-to-point by default. I changed them over to point-to-multipoint and the flapping stopped.
I got to thinking about my issue and it makes sense all the way around. Tunnels are typically from one location to one location. A point-to-point tunnel. Makes sense that the default OSPF network type is the same. So with only one spoke, everything would work like a charm. Add another spoke and this is no longer a point-to-point link but since the network type is, the older neighbor is dropped causing it to re-register and this causes the other one to drop. Well with three neighbors, my hub went nuts and started to drop and come back every couple seconds and ran the CPU up all the way. Thank goodness it settled once I changed the network type.
Changing the network type did fix my flapping issue but I looked at a spoke and noticed that all my routes had the hub as the next hop. That made my DMVPN only work in phase 1. Not cool because that meant that I would have no spoke to spoke traffic. I pulled out some OSPF notes that I had and found what I needed to fix it. I changed the network type to broadcast. I also for safety set the spoke OSPF priority to 0. Once all this was done, each route had the correct next hop router and DMVPN phase 2 was a go. Whew!!!
I tested full connectivity after all this and it all worked. I was so glad. I learned quite a bit from doing this and I want to run BGP and RIP over DMVPN now to see how they act. Figure that with RIP I will have to turn off split horizon. Have to see what else is needed.
Here again is my network diagram.
I got to thinking about my issue and it makes sense all the way around. Tunnels are typically from one location to one location. A point-to-point tunnel. Makes sense that the default OSPF network type is the same. So with only one spoke, everything would work like a charm. Add another spoke and this is no longer a point-to-point link but since the network type is, the older neighbor is dropped causing it to re-register and this causes the other one to drop. Well with three neighbors, my hub went nuts and started to drop and come back every couple seconds and ran the CPU up all the way. Thank goodness it settled once I changed the network type.
Changing the network type did fix my flapping issue but I looked at a spoke and noticed that all my routes had the hub as the next hop. That made my DMVPN only work in phase 1. Not cool because that meant that I would have no spoke to spoke traffic. I pulled out some OSPF notes that I had and found what I needed to fix it. I changed the network type to broadcast. I also for safety set the spoke OSPF priority to 0. Once all this was done, each route had the correct next hop router and DMVPN phase 2 was a go. Whew!!!
I tested full connectivity after all this and it all worked. I was so glad. I learned quite a bit from doing this and I want to run BGP and RIP over DMVPN now to see how they act. Figure that with RIP I will have to turn off split horizon. Have to see what else is needed.
Here again is my network diagram.
DMVPN with EIGRP Named
I created a base DMVPN lab with 17 routers so that I could play with different routing protocols running across a DMVPN. The first protocol was a basic EIGRP named configuration. Nothing much to it. Made sure that split horizon was off. as well as turning off next hop self on the hub. Had full layer three reachability. Even went in and played with a couple of options in EIGRP since I have only done named mode once before. Not that bad.
Here is the config that I made for the EIGRP section of the hub.
router eigrp INTERNAL
!
address-family ipv4 unicast autonomous-system 100
!
af-interface default
authentication mode md5
authentication key-chain EIGRP
passive-interface
exit-af-interface
!
af-interface GigabitEthernet1/0
no passive-interface
exit-af-interface
!
af-interface Tunnel0
summary-address 192.168.8.0 255.255.248.0
summary-address 192.168.16.0 255.255.248.0
no next-hop-self
no passive-interface
no split-horizon
exit-af-interface
!
topology base
exit-af-topology
network 3.3.3.3 0.0.0.0
network 192.168.0.3 0.0.0.0
network 192.168.23.3 0.0.0.0
eigrp router-id 3.3.3.3
exit-address-family
!
There weren't any real gotchas on this one. Pretty straight forward.
Here is a pic of the lab that I made as well.
Here is the config that I made for the EIGRP section of the hub.
router eigrp INTERNAL
!
address-family ipv4 unicast autonomous-system 100
!
af-interface default
authentication mode md5
authentication key-chain EIGRP
passive-interface
exit-af-interface
!
af-interface GigabitEthernet1/0
no passive-interface
exit-af-interface
!
af-interface Tunnel0
summary-address 192.168.8.0 255.255.248.0
summary-address 192.168.16.0 255.255.248.0
no next-hop-self
no passive-interface
no split-horizon
exit-af-interface
!
topology base
exit-af-topology
network 3.3.3.3 0.0.0.0
network 192.168.0.3 0.0.0.0
network 192.168.23.3 0.0.0.0
eigrp router-id 3.3.3.3
exit-address-family
!
There weren't any real gotchas on this one. Pretty straight forward.
Here is a pic of the lab that I made as well.
24 May 2014
DMVPN Part 2
The other night I did the first video on YouTube from INE dealing with DMVPN. This morning I did the second video. While the first video was more about the phase 1 setup and theory behind this technology, video 2 was how to build upon that and make it dynamic and encrypted. These two videos are not going to make anyone an expert on DMVPN but they will help someone, such as myself, who is clueless about it that has never seen nor used the technology. Well on to the fun stuff.
These two videos are done using EIGRP as the internal routing protocol. Two reasons in my book for this. One that is what Cisco used in their configuration and two is that this protocol has some pitfalls and examples that make it great for the show case of the different phases. First things first. All traffic goes in and out of one tunnel when looking at the config and routing table. So each spoke will not get the routing updates for another spoke from the hub because of that great and pain in the butt technology that is split horizon (it is a pain in the butt at 0300 in the morning when you are troubleshooting why something won't work or in the 11th hour of the IE test and you can't get routes to show up). Turn that off on the hub's tunnel interface. This allows routes to come into the hub on the tunnel interface and re-leave the interface to go to other spokes.
But wait. There is an issue still. So spoke 2 can see routes from spoke 3 but the next hop is still the hub. This means that the hub is still in the data and the control planes. Not acceptable. This will cause the hub to work harder decrypting and routing packets that it shouldn't care one bit about. Send that crap straight to the other spoke. Use no ip next-hop-self eigrp <AS_number> and the hub will not inject itself as the next hop. This will allow the spokes to talk directly with each other.
Now that the spokes know the other spokes are there, how do they get there? This is where NHRP comes in. They query the hub for the NBMA (think public) address of the other spoke and away they go. There is more to it than that but the gist is that the hub introduces the spokes and then politely bows out. Think of it as a match maker. Sets them up and then bids adieu.
At this point, the spokes are talking, but is it permanent? Nope. There is a lifetime of everything. The lifetime by default is two hours. This can all be adjusted on the tunnel interface with ip nhrp holdtime.
Another thing to remember when setting up NHRP and DMVPN is multicast and how to make it work. The command ip nhrp map multicast <hub_IP/dynamic> will allow multicast to function correctly over the tunnels. As Brian said in the video, think of this as adding the broadcast word to a frame relay map statement.
Oh, crap. Something seems to be wrong with NHRP. What ever will I use to troubleshoot it? How about the command debug nhrp? That will turn on basic NHRP debugging and help show issues that might arise. I find this interesting since the command to use nhrp is ip nhrp and the command for debugging doesn't have the keyword ip. Oh, well.
Okay. So what do we have now? We have dynamic tunnels from spoke to spoke and a static tunnel from each spoke to the hub. Perfect, right? Nope. If this is traveling the wonder that is the Internet, that means that this is subject to monitoring and that ain't cool. How to fix that is the use of IPSec. Now according to Brian in the video, the traditional way of doing IPSec (I have never done it on a router or firewall; always used other devices) was through crypto maps but these require each spoke to know about each other. Kinds makes DMVPN more like MVPN. Why use a match maker if you have her number already? To beat this little bugger, you can now use crypto profiles. Make the profile and attach it to the interface and WAMMO, instant get-the-hell-off-my-lawn scenario to anyone listening in.
You want to tell if IPSec is working? Why? Always trust the configuration. Isn't that always correct? Yeah, right. Use show crypto isakmp sa to see what IKEv1 sessions are active and show crypto ipsec sa to see what IPSec sessions are active and with what parameters. You can also use show dmvpn detail for specific DMVPN information. These commands will only show the initial connection to the hub from each spoke until a spoke wants to get his freak on with another spoke. At that time, the encrypted tunnel (Internet condom?) is made and away they go.
Brian listed a couple of articles to help with learning more about DMVPN. The first is the design guide off of Cisco's Design Zone. The other is the DMVPN articles on Cisco Live 365. Not bad places to learn a little more.
Now I don't feel like an expert with DMVPN, but I can say that I feel better than I did.
Below is the video that I watched and followed along with.
These two videos are done using EIGRP as the internal routing protocol. Two reasons in my book for this. One that is what Cisco used in their configuration and two is that this protocol has some pitfalls and examples that make it great for the show case of the different phases. First things first. All traffic goes in and out of one tunnel when looking at the config and routing table. So each spoke will not get the routing updates for another spoke from the hub because of that great and pain in the butt technology that is split horizon (it is a pain in the butt at 0300 in the morning when you are troubleshooting why something won't work or in the 11th hour of the IE test and you can't get routes to show up). Turn that off on the hub's tunnel interface. This allows routes to come into the hub on the tunnel interface and re-leave the interface to go to other spokes.
But wait. There is an issue still. So spoke 2 can see routes from spoke 3 but the next hop is still the hub. This means that the hub is still in the data and the control planes. Not acceptable. This will cause the hub to work harder decrypting and routing packets that it shouldn't care one bit about. Send that crap straight to the other spoke. Use no ip next-hop-self eigrp <AS_number> and the hub will not inject itself as the next hop. This will allow the spokes to talk directly with each other.
Now that the spokes know the other spokes are there, how do they get there? This is where NHRP comes in. They query the hub for the NBMA (think public) address of the other spoke and away they go. There is more to it than that but the gist is that the hub introduces the spokes and then politely bows out. Think of it as a match maker. Sets them up and then bids adieu.
At this point, the spokes are talking, but is it permanent? Nope. There is a lifetime of everything. The lifetime by default is two hours. This can all be adjusted on the tunnel interface with ip nhrp holdtime.
Another thing to remember when setting up NHRP and DMVPN is multicast and how to make it work. The command ip nhrp map multicast <hub_IP/dynamic> will allow multicast to function correctly over the tunnels. As Brian said in the video, think of this as adding the broadcast word to a frame relay map statement.
Oh, crap. Something seems to be wrong with NHRP. What ever will I use to troubleshoot it? How about the command debug nhrp? That will turn on basic NHRP debugging and help show issues that might arise. I find this interesting since the command to use nhrp is ip nhrp and the command for debugging doesn't have the keyword ip. Oh, well.
Okay. So what do we have now? We have dynamic tunnels from spoke to spoke and a static tunnel from each spoke to the hub. Perfect, right? Nope. If this is traveling the wonder that is the Internet, that means that this is subject to monitoring and that ain't cool. How to fix that is the use of IPSec. Now according to Brian in the video, the traditional way of doing IPSec (I have never done it on a router or firewall; always used other devices) was through crypto maps but these require each spoke to know about each other. Kinds makes DMVPN more like MVPN. Why use a match maker if you have her number already? To beat this little bugger, you can now use crypto profiles. Make the profile and attach it to the interface and WAMMO, instant get-the-hell-off-my-lawn scenario to anyone listening in.
You want to tell if IPSec is working? Why? Always trust the configuration. Isn't that always correct? Yeah, right. Use show crypto isakmp sa to see what IKEv1 sessions are active and show crypto ipsec sa to see what IPSec sessions are active and with what parameters. You can also use show dmvpn detail for specific DMVPN information. These commands will only show the initial connection to the hub from each spoke until a spoke wants to get his freak on with another spoke. At that time, the encrypted tunnel (Internet condom?) is made and away they go.
Brian listed a couple of articles to help with learning more about DMVPN. The first is the design guide off of Cisco's Design Zone. The other is the DMVPN articles on Cisco Live 365. Not bad places to learn a little more.
Now I don't feel like an expert with DMVPN, but I can say that I feel better than I did.
Below is the video that I watched and followed along with.
22 May 2014
DMVPN Part 1
I watched INE's YouTube video tonight for DMVPN part 1. Seeing it broken down like that by Brian McGahan is actually quite interesting. Didn't realize how easy it was. Definitely learned a few things following along in my lab as he did it in the video. Also not having the initial config was fun too because I had to figure out based on his output what he had configured for basic routing and configure my lab to match. Made me feel something good that I could do that even if it was a super easy lab to configure for the initial setup.
What did I learn? I learned that taking the initial config from Cisco's website is a great way to start since it is commented very well. Great starting place to 1) understand and 2) get a basic config for the exam.
I also learned that DMVPN is a lot more like frame relay than I suspected. I had an inkling that it was and I can see it being used for OSPF DR and DROTHER usage as well as great tickets in the TS section. And not only is it like frame relay with hub and spoke technology but also when thinking of mappings and how it works when looking at the output of show ip nhrp. As Brian put it, think of the NMBA address as the DLCI in frame.
So, with no crypto it really isn't that hard to get the basics of but knowing Cisco there will be gotchas in it that will cause someone and more than likely everyone to scream.
Now what is DMVPN? It is basically a way to connect multiple sites using a hub location that all other sites connect to. From here the mappings are made and stored for these remote locations so that the remote sites can find neighbors and then connect directly to each on an as needed basis. Add crypto and you got yourself a completely meshed network that is secure and can be run over that pesky, ole internet. Sounds hard but not really. Issue, as Brian put it, was that it can be more complicated with more sites and needing redundancy. Well, luckily v5 only requires one hub. Yay for the little things in life.
Video part 1 covers the basic theory of DMVPN and the rudimentary CLI needed to get phases 1 completed. Phase 1 is where all traffic flows through the hub site. Nope. Not very dynamic there. Phases 2 and 3 are where the true power of the technology comes in and that is video part 2. That will be tomorrow night for and I can't wait.
Was going to embed the video below but the Blogger site can't seem to find the video. Instead here is the link
https://www.youtube.com/watch?v=CIWcYSClbio
What did I learn? I learned that taking the initial config from Cisco's website is a great way to start since it is commented very well. Great starting place to 1) understand and 2) get a basic config for the exam.
I also learned that DMVPN is a lot more like frame relay than I suspected. I had an inkling that it was and I can see it being used for OSPF DR and DROTHER usage as well as great tickets in the TS section. And not only is it like frame relay with hub and spoke technology but also when thinking of mappings and how it works when looking at the output of show ip nhrp. As Brian put it, think of the NMBA address as the DLCI in frame.
So, with no crypto it really isn't that hard to get the basics of but knowing Cisco there will be gotchas in it that will cause someone and more than likely everyone to scream.
Now what is DMVPN? It is basically a way to connect multiple sites using a hub location that all other sites connect to. From here the mappings are made and stored for these remote locations so that the remote sites can find neighbors and then connect directly to each on an as needed basis. Add crypto and you got yourself a completely meshed network that is secure and can be run over that pesky, ole internet. Sounds hard but not really. Issue, as Brian put it, was that it can be more complicated with more sites and needing redundancy. Well, luckily v5 only requires one hub. Yay for the little things in life.
Video part 1 covers the basic theory of DMVPN and the rudimentary CLI needed to get phases 1 completed. Phase 1 is where all traffic flows through the hub site. Nope. Not very dynamic there. Phases 2 and 3 are where the true power of the technology comes in and that is video part 2. That will be tomorrow night for and I can't wait.
Was going to embed the video below but the Blogger site can't seem to find the video. Instead here is the link
https://www.youtube.com/watch?v=CIWcYSClbio
21 May 2014
EIGRP Named Configuration
So today I tried my hand at configuring EIGRP using named configuration. I watched the YouTube video from iPexpert on the differences of it and followed along with a couple of routers in my lab. It was a great way to begin to learn it and see the differences between traditional and named.
So the first thing that I thought of with named configuration is "Holy Crap. That's a lot of typing." After that I got to see the real power of named mode. It is a great way to see all of your EIGRP configuration in one place without having to look at interfaces for more configuration options.
It is also great so that not only can you configure IPv4 but also IPv6 all in one place. This is done through the use of address-families (think BGP with VRFs or EIGRP traditional mode with VRFs). This again keeps the configuration clean and keeps everything in one place. I like this and may actually start to use this no matter.
So, some more about named mode. Like I said, it used address families to configure EIGRP networks. Autonomous system numbers are assigned to specific families as well. Network commands are placed directly under the address family and this gets a little confusing at first. Network commands are used to identify interfaces to advertise into EIGRP so they help to make up the topology. Now there is a topology section under each address family and no network commands go under there. What goes there are distribute-lists, redistributes, and things that affect the topology of the network. Network commands since they have dual duty don't belong under the topology section.
Also under each address family is where you configure interface information. All the commands that the traditional method uses under and interface are now here. Again, think cleaner. This is done with the af-interface section and there is default for all interfaces or you can specify the exact interface. Under it you have all the typical traditional options and the ability to do passive or not on the interface.
Now, ready for a kicker. Where do you think that summary-addresses are configured? Under af-interface or topology? It is changing some of the topology but it is really configured under the af-interface section and cannot be done under default. It has to be done on the specific interface. Just a little gotcha.
So what is the difference for named versus traditional when it comes to IPv6? Well with IPv6, it all comes under named mode. Nothing is done on the interfaces. Also all interfaces are auto-magically added to EIGRP. This can be stopped by adding shutdown to the af-interface section for that interface or under af-interface default. I can see little things like that being a great trouble ticket on the new R&S test.
Okay. I talked about it but what does it all look like. Below is the configuration that I made from following the video. You will see it looks scary but truly looking at it shows that it ain't so bad.
router eigrp cisco
!
address-family ipv4 unicast autonomous-system 12
!
af-interface default
authentication mode md5
authentication key-chain E12
passive-interface
exit-af-interface
!
af-interface GigabitEthernet0/0
summary-address 2.0.0.0 255.0.0.0
no passive-interface
exit-af-interface
!
af-interface GigabitEthernet1/0
summary-address 2.0.0.0 255.0.0.0
no passive-interface
exit-af-interface
!
af-interface GigabitEthernet2/0
summary-address 2.0.0.0 255.0.0.0
no authentication mode
no passive-interface
exit-af-interface
!
topology base
distribute-list prefix MyFilter in
redistribute connected metric 1 1 1 1 1 route-map Lo0
exit-af-topology
network 10.100.2.0 0.0.0.255
network 192.168.12.0
network 192.168.21.0
network 192.168.102.0
exit-address-family
!
address-family ipv6 unicast autonomous-system 12
!
af-interface default
shutdown
passive-interface
exit-af-interface
!
af-interface GigabitEthernet0/0
no shutdown
no passive-interface
exit-af-interface
!
topology base
redistribute connected metric 10000 10 255 1 1500 route-map Lo0
exit-af-topology
exit-address-family
!
Hope this helps. I know that I feel a lot better about it now.
The video is below as well in case anyone was curious.
So the first thing that I thought of with named configuration is "Holy Crap. That's a lot of typing." After that I got to see the real power of named mode. It is a great way to see all of your EIGRP configuration in one place without having to look at interfaces for more configuration options.
It is also great so that not only can you configure IPv4 but also IPv6 all in one place. This is done through the use of address-families (think BGP with VRFs or EIGRP traditional mode with VRFs). This again keeps the configuration clean and keeps everything in one place. I like this and may actually start to use this no matter.
So, some more about named mode. Like I said, it used address families to configure EIGRP networks. Autonomous system numbers are assigned to specific families as well. Network commands are placed directly under the address family and this gets a little confusing at first. Network commands are used to identify interfaces to advertise into EIGRP so they help to make up the topology. Now there is a topology section under each address family and no network commands go under there. What goes there are distribute-lists, redistributes, and things that affect the topology of the network. Network commands since they have dual duty don't belong under the topology section.
Also under each address family is where you configure interface information. All the commands that the traditional method uses under and interface are now here. Again, think cleaner. This is done with the af-interface section and there is default for all interfaces or you can specify the exact interface. Under it you have all the typical traditional options and the ability to do passive or not on the interface.
Now, ready for a kicker. Where do you think that summary-addresses are configured? Under af-interface or topology? It is changing some of the topology but it is really configured under the af-interface section and cannot be done under default. It has to be done on the specific interface. Just a little gotcha.
So what is the difference for named versus traditional when it comes to IPv6? Well with IPv6, it all comes under named mode. Nothing is done on the interfaces. Also all interfaces are auto-magically added to EIGRP. This can be stopped by adding shutdown to the af-interface section for that interface or under af-interface default. I can see little things like that being a great trouble ticket on the new R&S test.
Okay. I talked about it but what does it all look like. Below is the configuration that I made from following the video. You will see it looks scary but truly looking at it shows that it ain't so bad.
router eigrp cisco
!
address-family ipv4 unicast autonomous-system 12
!
af-interface default
authentication mode md5
authentication key-chain E12
passive-interface
exit-af-interface
!
af-interface GigabitEthernet0/0
summary-address 2.0.0.0 255.0.0.0
no passive-interface
exit-af-interface
!
af-interface GigabitEthernet1/0
summary-address 2.0.0.0 255.0.0.0
no passive-interface
exit-af-interface
!
af-interface GigabitEthernet2/0
summary-address 2.0.0.0 255.0.0.0
no authentication mode
no passive-interface
exit-af-interface
!
topology base
distribute-list prefix MyFilter in
redistribute connected metric 1 1 1 1 1 route-map Lo0
exit-af-topology
network 10.100.2.0 0.0.0.255
network 192.168.12.0
network 192.168.21.0
network 192.168.102.0
exit-address-family
!
address-family ipv6 unicast autonomous-system 12
!
af-interface default
shutdown
passive-interface
exit-af-interface
!
af-interface GigabitEthernet0/0
no shutdown
no passive-interface
exit-af-interface
!
topology base
redistribute connected metric 10000 10 255 1 1500 route-map Lo0
exit-af-topology
exit-address-family
!
Hope this helps. I know that I feel a lot better about it now.
The video is below as well in case anyone was curious.
19 May 2014
MST
So tonight I watched a video on MST. MST is one of those things that has caused me headaches and watching Marko M. from iPexpert, it sounds like it is a headache from everyone. It is can be very simple and very complex.
I knew that VLANs mapped to instances. I knew that it reduced the amount of instances per switch to reduce the amount of traffic/BPDUs going over a link. I didn't realize some of the behind the scenes junk.
For example, I didn't realize that MST didn't take effect until you exited its config mode. Good to know. I can see that biting me in the behind when I configuring it and checking my config with do show commands.
I also didn't realize that VLANs can be mapped that aren't even created. I never really thought about it. Allows for future growth and it is already configured when the VLAN is configured and set up. This is more of a planning and design aspect but still good to know.
Also found out how instance and VLAN mappings are shared. This comes from the MST CONFIG DIGEST within the BPDU. This is a hash that will match from switch to switch if they are mapped the same way. The revision number and region name have no sway in the hash what so ever. This makes me thing of a good diagnostic question or part of a question for the v5 test.
Finally comes the MSTI, CST, and IST. I either didn't know about them all or forgot about them. Good to see how they all fit together. CST is used to connect to another STP mode (PVST or Rapid PVST). IST is used inside the MST and MSTI is an instance of MST that uses IST to traverse essentially. Because of the CST that connects a region to another mode, it makes the region look like one switch. Again, a cool concept.
Can't wait to try this in my lab again. And speaking of that, there will be some labbing but not a lot until INE and iPexpert release more labs. I do have the Cisco Press v5 Configuration Prep book. May do a little but also thinking of watching videos and also knocking out my Brocade Certified Network Engineer (BNCE) real quick and my CCNA Voice. I have access to the study guides and they seem pretty easy. Just a though.
I knew that VLANs mapped to instances. I knew that it reduced the amount of instances per switch to reduce the amount of traffic/BPDUs going over a link. I didn't realize some of the behind the scenes junk.
For example, I didn't realize that MST didn't take effect until you exited its config mode. Good to know. I can see that biting me in the behind when I configuring it and checking my config with do show commands.
I also didn't realize that VLANs can be mapped that aren't even created. I never really thought about it. Allows for future growth and it is already configured when the VLAN is configured and set up. This is more of a planning and design aspect but still good to know.
Also found out how instance and VLAN mappings are shared. This comes from the MST CONFIG DIGEST within the BPDU. This is a hash that will match from switch to switch if they are mapped the same way. The revision number and region name have no sway in the hash what so ever. This makes me thing of a good diagnostic question or part of a question for the v5 test.
Finally comes the MSTI, CST, and IST. I either didn't know about them all or forgot about them. Good to see how they all fit together. CST is used to connect to another STP mode (PVST or Rapid PVST). IST is used inside the MST and MSTI is an instance of MST that uses IST to traverse essentially. Because of the CST that connects a region to another mode, it makes the region look like one switch. Again, a cool concept.
Can't wait to try this in my lab again. And speaking of that, there will be some labbing but not a lot until INE and iPexpert release more labs. I do have the Cisco Press v5 Configuration Prep book. May do a little but also thinking of watching videos and also knocking out my Brocade Certified Network Engineer (BNCE) real quick and my CCNA Voice. I have access to the study guides and they seem pretty easy. Just a though.
18 May 2014
Redistribution Fun Part 2
router ospf 1
redistribute rip subnets route-map R2O
!
router rip
redistribute ospf 1 metric 3 route-map O2R
!
route-map R2O deny 10
match tag 110
!
route-map R2O permit 20
match tag 70
set tag 70
!
route-map R2O permit 30
set tag 120
!
route-map O2R deny 10
match tag 120
!
route-map O2R permit 20
match tag 70
set tag 70
!
route-map O2R permit 30
set tag 110
!
Without the route-maps, no loops formed and the route-maps were to guarantee this. The only issue I saw was sub-optimal routing, which I will get to another time. This is so that I can solidify in my mind the way to redistribute. Thinking that I got this somewhat.
While I did this scenario I came up with another one to try. Probably won't be able to lab it up tonight but I will try to this week.
Distance Command
And this is why I like to lab. So I was working on the first of my redistribution scenarios today and I learned some important stuff. First off, if an OSPF ABR injects a default route into a NSSA, the route is not added to the route table by default. If redistribution brings that default route back to the router through another means, then the route can be injected into the route table as a new route and that will cause a loop to form. Oh what fun.
So this scenario is something that I was looking at trying to cause. I wanted to see how to filter the default route out so that the initiator wouldn't see it and cause a loop. I tried using the distance command and nothing seemed to work. I was using an ACL that was matching but the route was always there. I modified the ACL to include another route and it worked for the other route but not the default route. I am thinking that since this is a default route, it was basically like, piss off. You can't touch me.
This caused me to look at another way to kill it. I went to my all time favorite...distibute-list. Did a quick prefix-list to deny that route and allow all others coming in the correct interface and BAM, it worked like a charm. That is something that is definitely good to know.
So one last mention about this scenario is that I used a triple route-map setup since I had three routing protocols. This worked on filtering routes correctly but did cause some sub-optimal routing. May come back to fixing that later but for now this is a test to know that I can do route redistribution with no loops.
So this scenario is something that I was looking at trying to cause. I wanted to see how to filter the default route out so that the initiator wouldn't see it and cause a loop. I tried using the distance command and nothing seemed to work. I was using an ACL that was matching but the route was always there. I modified the ACL to include another route and it worked for the other route but not the default route. I am thinking that since this is a default route, it was basically like, piss off. You can't touch me.
This caused me to look at another way to kill it. I went to my all time favorite...distibute-list. Did a quick prefix-list to deny that route and allow all others coming in the correct interface and BAM, it worked like a charm. That is something that is definitely good to know.
So one last mention about this scenario is that I used a triple route-map setup since I had three routing protocols. This worked on filtering routes correctly but did cause some sub-optimal routing. May come back to fixing that later but for now this is a test to know that I can do route redistribution with no loops.
17 May 2014
Route Redistribution
So today I watched the iPexpert video on route redistribution and came up with a couple of scenarios to lab up on GNS3. I also made some notes for a problem that has been bugging the crap out of me since my last lab attempt. I am working on labbing it up as well since there was a problem with redistribution on there that I know caused me an issue.
So scenario one involves a problem that was gone over in the video and I want to make sure that I can find out the answer. It involves blocking routes when they are distributed in with redistribution. It has the three major routing protocol (RIPv2, OSPF, and EIGRP) and can cause a major loop but I know how to beat that. Using route maps will beat that. The tricky part is when I will inject default route into an NSSA area. To beat this I know that I can use distance, ACLs, or distribute lists. Gonna try to do this with distance.
The second scenario is another triple route injection problem just for me to cement my ability.
The other scenario is what I said earlier. It is a topology from my last attempt and something I won't talk about much here. I will have to figure out how to talk about that one without breaking the NDA which may not happen.
So with redistribution, I do like iPexpert's way of handling redistribution. No matter the task scenario given, always break it up into little pieces. Configure each protocol first and then worry about redistribution. It may not give you points until they are all done but so what. Make life easier for you. Having seen multiple scenarios, I would suggest following those guidelines as well. Configure RIP. Configure OSPF. Configure EIGRP. Configure redistribution based on what is asked. Like I said, this is great way of approaching it.
So how to fix a three way distribution. The easiest way if you can do it is to route-maps. Set the tags to the AD of the originating routing protocol. Block the routes with the tag of the same AD as the destination of the route. Copy all other tags. Finally set the tag to the AD of the source protocol. Do that on every router for each protocol with very little changing and BAM. What a great and awesome loop free topology. Well nearly loop free.
Supposedly, and I am still looking at this in scenario 1 from above, a loop can form if a route is injected using a non-normal way of making the route. Think of injecting a default route in a NSSA area. Like I said, this is supposedly. Will hopefully know more tomorrow.
My final gotcha of the night. When redistributing connected routes using route-maps, be careful to make sure that interfaces are redistributed correctly. Not including all the correct interfaces can cause full connectivity to fail and fail hard. Thank goodness for TCL scripts to quickly check this all out.
Well, for now, that is all. Hopefully I can keep this going. I am liking it because it is really helping me to cement what I am learning.
So scenario one involves a problem that was gone over in the video and I want to make sure that I can find out the answer. It involves blocking routes when they are distributed in with redistribution. It has the three major routing protocol (RIPv2, OSPF, and EIGRP) and can cause a major loop but I know how to beat that. Using route maps will beat that. The tricky part is when I will inject default route into an NSSA area. To beat this I know that I can use distance, ACLs, or distribute lists. Gonna try to do this with distance.
The second scenario is another triple route injection problem just for me to cement my ability.
The other scenario is what I said earlier. It is a topology from my last attempt and something I won't talk about much here. I will have to figure out how to talk about that one without breaking the NDA which may not happen.
So with redistribution, I do like iPexpert's way of handling redistribution. No matter the task scenario given, always break it up into little pieces. Configure each protocol first and then worry about redistribution. It may not give you points until they are all done but so what. Make life easier for you. Having seen multiple scenarios, I would suggest following those guidelines as well. Configure RIP. Configure OSPF. Configure EIGRP. Configure redistribution based on what is asked. Like I said, this is great way of approaching it.
So how to fix a three way distribution. The easiest way if you can do it is to route-maps. Set the tags to the AD of the originating routing protocol. Block the routes with the tag of the same AD as the destination of the route. Copy all other tags. Finally set the tag to the AD of the source protocol. Do that on every router for each protocol with very little changing and BAM. What a great and awesome loop free topology. Well nearly loop free.
Supposedly, and I am still looking at this in scenario 1 from above, a loop can form if a route is injected using a non-normal way of making the route. Think of injecting a default route in a NSSA area. Like I said, this is supposedly. Will hopefully know more tomorrow.
My final gotcha of the night. When redistributing connected routes using route-maps, be careful to make sure that interfaces are redistributed correctly. Not including all the correct interfaces can cause full connectivity to fail and fail hard. Thank goodness for TCL scripts to quickly check this all out.
Well, for now, that is all. Hopefully I can keep this going. I am liking it because it is really helping me to cement what I am learning.
16 May 2014
Lab Environment
So, for the v5 exam, there are choices when it comes to the lab. Same thing with the v4 exam. Choices, choices, choices.
So the first and obvious choice is physical equipment. INE is calling for 20 routers and 4 switches. IPExpert is calling for 11 routers and 4 switches at a minimum. That is a lot of equipment, a lot of power, a lot of cooling and a lot of money. I can't do that.
Next option is rack rentals. Good choice. Let someone else pay for the cost of all the equipment, cooling, and power. My problem is again money for the rack time and the time it takes. I travel a lot for work and have a wife so being able to to schedule time and use all that time is hard. Again, another option I can't do.
Third option is using physical switches with 1000 CSRs running on an ESXi box. This is doable and I have the box to run all those devices. My issue is that the CSRs don't seem to be able to have serial connections. While INE, thus far, isn't calling for serial links, IPExpert is. Since I plan on using both, not really going to work for me.
To me, that leaves me one last choice. I am going to use GNS3 going to a breakout switch then to four physical switches. My switches are two 3560v2's and two 3560E's. My breakout that is doing QinQ is a 3750-48TS switch. The switches are on lone so if they are called back then that leaves me a fifth option.
Option five is using GNS3 totally with integrated switching. Since I contributed to GNS3, I have access to GNS3 Alpha releases. I have tried it and I like it but either I am doing something wrong (strong possibility) or it just isn't ready for me yet with my studies. I have a hard time with the IOL keeping configs. A lot of work to make it work but it is a possibility if option 4 falls through.
So now that my way of studying the labs is set up, let's talk about the server. The server is a Dell OptiPlex with an Intel Xeon W3550 proc running at 3.07 GHz and has 12 GB of RAM. It is running Windows 7 64-bit as well.
Well that is the lab set up. Now all I need to do is wait a little longer for the IPExpert workbooks to finalize and the INE to flesh out a little more. Until then, I will continue to read and keep an eye on their sites.
So the first and obvious choice is physical equipment. INE is calling for 20 routers and 4 switches. IPExpert is calling for 11 routers and 4 switches at a minimum. That is a lot of equipment, a lot of power, a lot of cooling and a lot of money. I can't do that.
Next option is rack rentals. Good choice. Let someone else pay for the cost of all the equipment, cooling, and power. My problem is again money for the rack time and the time it takes. I travel a lot for work and have a wife so being able to to schedule time and use all that time is hard. Again, another option I can't do.
Third option is using physical switches with 1000 CSRs running on an ESXi box. This is doable and I have the box to run all those devices. My issue is that the CSRs don't seem to be able to have serial connections. While INE, thus far, isn't calling for serial links, IPExpert is. Since I plan on using both, not really going to work for me.
To me, that leaves me one last choice. I am going to use GNS3 going to a breakout switch then to four physical switches. My switches are two 3560v2's and two 3560E's. My breakout that is doing QinQ is a 3750-48TS switch. The switches are on lone so if they are called back then that leaves me a fifth option.
Option five is using GNS3 totally with integrated switching. Since I contributed to GNS3, I have access to GNS3 Alpha releases. I have tried it and I like it but either I am doing something wrong (strong possibility) or it just isn't ready for me yet with my studies. I have a hard time with the IOL keeping configs. A lot of work to make it work but it is a possibility if option 4 falls through.
So now that my way of studying the labs is set up, let's talk about the server. The server is a Dell OptiPlex with an Intel Xeon W3550 proc running at 3.07 GHz and has 12 GB of RAM. It is running Windows 7 64-bit as well.
Well that is the lab set up. Now all I need to do is wait a little longer for the IPExpert workbooks to finalize and the INE to flesh out a little more. Until then, I will continue to read and keep an eye on their sites.
Way Ahead
So how am I going to study? This is going to be a different way than I was before for v4. In v4, I read the Cisco Press book and then use the workbooks from INE and IPExpert. I also did a bootcamp with IPExpert. I also listened to the audio from IPExpert and watched the videos from INE. I was trying to mainly study through the use of pure force with labs and after three lab attempts, it definitely didn't work.
This time, I am still going to brute force my way through labs and watch the videos from both vendors. Labs are the key to all of my studying but I know I was missing something. That something seems to be the Configuration Guides from Cisco. I am going to try and read the majority of those guides and see where I can go.
To start with, I am going to begin with the routing ones and then on to MPLS, QOS, DMVPN, and switching. So starting with routing, I have been working on the protocol independent routing and I can say that I have learned a few things and new ways of looking at things. It really has already been a good idea and I can't complain.
First thing was finally understanding distribution lists and their use. I get it now. It is showing what is going out and coming in. Combine that with the distance command and how you can use it to filter routes from a specific neighbor/router and BAM, it is a cool thing. Makes me realize what I missed on my last attempt in one task. Well, at least I have learned.
So, as it can be seen, my studying method is already paying off somewhat. Only time will tell what will happen.
This time, I am still going to brute force my way through labs and watch the videos from both vendors. Labs are the key to all of my studying but I know I was missing something. That something seems to be the Configuration Guides from Cisco. I am going to try and read the majority of those guides and see where I can go.
To start with, I am going to begin with the routing ones and then on to MPLS, QOS, DMVPN, and switching. So starting with routing, I have been working on the protocol independent routing and I can say that I have learned a few things and new ways of looking at things. It really has already been a good idea and I can't complain.
First thing was finally understanding distribution lists and their use. I get it now. It is showing what is going out and coming in. Combine that with the distance command and how you can use it to filter routes from a specific neighbor/router and BAM, it is a cool thing. Makes me realize what I missed on my last attempt in one task. Well, at least I have learned.
So, as it can be seen, my studying method is already paying off somewhat. Only time will tell what will happen.
What This is About
So, I am starting on my journey for CCIE R&S v5. I have seen people that blogged and it gave them a way to express what they learned so that they could document it and make sure that they understood it. It seemed to help because I have seen them pass. Not going to say that happens with me but thought that it might be worth a shot.
Over the course of my study, I will try to update this as I go. I can't promise it will be updated often, the content will be exciting or educational, or that it will be a benefit to anyone. I can promise that it will be my words and my thoughts about this journey.
So here we go. Time to start this journey.
Over the course of my study, I will try to update this as I go. I can't promise it will be updated often, the content will be exciting or educational, or that it will be a benefit to anyone. I can promise that it will be my words and my thoughts about this journey.
So here we go. Time to start this journey.
Subscribe to:
Posts (Atom)