A useful tool to automatically back up your running-config is the Archive tool set.
Part of Cisco's Archive and Restore features it allows you to take the running-config and archive on to either that device or to a remote device such as a tftp server.
Set up an Archive using the following:
R1#conf t
R1(config)#archive
R1(config-archive)#path tftp://10.10.10.10/$h.txt
R1(config-archive)#write-memory
R1(config-archive)#time period 10080
In the above you set the destination server, the $h indicates that the archive will automatically be called [the host name of the router]-1.txt. The next archive will be [host name]-2 and so on...
Write-memory prompts the archive process to run every time write-mem is executed and the time period is set in minutes to automatically execute an archive backup.
So you now have your archive running. Next you decide you need an archived config to be restored.
You 'could' perform a #copy tftp run but remember that this will only merge the saved copy into the running config not totally over write it.
You 'could' perform a #copy tftp start but that would require a reload to restart the system and boot using the startup-config.
To immediately install an archived config perform a replace:
R1#configure replace tftp://10.10.10.10/r1-1.txt
What then occurs is the router compares the archive to the running config and compiles the commands needed to apply the archive to the running-config. It then executes them and the configuration the takes immediate effect.
Sunday, July 24, 2011
Sunday, July 17, 2011
CCNP - ENTERPRISE - IPv6 - Some thoughts...
In no particular order, notes that I took following from my day on a RIPE NCC training course about deploying IPv6:
1) Considering the IPv6 address is 128 bits long when you request an allocation from RIPE NCC (or who ever your RIR is) you get a minimum /32. That's 429,496,796 /64 subnets available for you to assign to your customers as you see fit! which is 18,446,744,073,709,551,616 host addresses! so you've got room to manoeuvre.
2) Best practice states that for a network assignment assign a subnet no longer than a single /64 subnet. The first 64-bits will be the network portion of your host address so the remaining 64 bits use as the host portion of the address.
Which is to say just as you would assign a single /24 , for example, to each VLAN on your network do likewise with an IPv6 /64 subnet. Now, you might only have a single mail server on a VLAN so you think that having one system using up a /64 subnet is a bit of a waste but consider that there already applications out there that expect you to be using a /64 subnet as the smallest network. If you start allocating random, non-best practice subnets, e.g. a /127, then you might potentially cause problems for your self in the future. Don't do it.
3) Don't fear the waste. Look at the numbers above, give your self plenty of addresses to play with on each VLAN and then when systems come along that have separate IPv6 addresses for individual procedure calls you're well equipped to handle it.
4) When subnetting an IPv6 address, best practice states you should allocate subnets from a 4 bit boundary. Remember that an IPv6 group is made up of 4 hexadecimal figures each of which represents a 4 bit binary figure. keeping the subnetting to nice 4bit boundaries basically stops your head imploding. The network subnets can be as follows- /32, /36, /40, /44, /48, /52, /56, /60, /64.
In our examples on the course we allocated a /48 for a single data centre, then subnetted that in to /60's for your routers/firewall/switches then within the switch infrastructure subnet your switch's /60 into /64's for each VLAN. Nice and tidy.
5) Within your business do not have an IPv6 specialist! you don't have an IPv4 specialist do you? if you avoid looking at IPv6 all that will happen is that you personally will be left behind and then when you're made redundant with no IPv6 experience/knowledge to speak of you'll be screwed.
6) Don't delay. Look at the figures in the widget provided by Hurricane Electric --> IPv6 is coming and fast. Emerging economies in Asia and Africa already have to use IPv6 natively because the IPv4 address have been exhausted. The last thing you want is a new market unable to access your website because you haven't got round to provisioning your website for IPv6.
7) My final thought is that within your organisation you should agree a policy on how to write IPv6 address and stick to it. You can choose to stick with typing out the full 128-bit address (8 groups of 4 Hexadecimal figures), You can choose to simply drop leading zero's, or agree to drop all leading zero's and replace contiguous groups of 4 zeros with a ::. Which ever method of representing an IPv6 address you choose make sure everyone sticks to it because it will make things easier when trouble shooting if the address format appears the same throughout your network.
1) Considering the IPv6 address is 128 bits long when you request an allocation from RIPE NCC (or who ever your RIR is) you get a minimum /32. That's 429,496,796 /64 subnets available for you to assign to your customers as you see fit! which is 18,446,744,073,709,551,616 host addresses! so you've got room to manoeuvre.
2) Best practice states that for a network assignment assign a subnet no longer than a single /64 subnet. The first 64-bits will be the network portion of your host address so the remaining 64 bits use as the host portion of the address.
Which is to say just as you would assign a single /24 , for example, to each VLAN on your network do likewise with an IPv6 /64 subnet. Now, you might only have a single mail server on a VLAN so you think that having one system using up a /64 subnet is a bit of a waste but consider that there already applications out there that expect you to be using a /64 subnet as the smallest network. If you start allocating random, non-best practice subnets, e.g. a /127, then you might potentially cause problems for your self in the future. Don't do it.
3) Don't fear the waste. Look at the numbers above, give your self plenty of addresses to play with on each VLAN and then when systems come along that have separate IPv6 addresses for individual procedure calls you're well equipped to handle it.
4) When subnetting an IPv6 address, best practice states you should allocate subnets from a 4 bit boundary. Remember that an IPv6 group is made up of 4 hexadecimal figures each of which represents a 4 bit binary figure. keeping the subnetting to nice 4bit boundaries basically stops your head imploding. The network subnets can be as follows- /32, /36, /40, /44, /48, /52, /56, /60, /64.
In our examples on the course we allocated a /48 for a single data centre, then subnetted that in to /60's for your routers/firewall/switches then within the switch infrastructure subnet your switch's /60 into /64's for each VLAN. Nice and tidy.
5) Within your business do not have an IPv6 specialist! you don't have an IPv4 specialist do you? if you avoid looking at IPv6 all that will happen is that you personally will be left behind and then when you're made redundant with no IPv6 experience/knowledge to speak of you'll be screwed.
6) Don't delay. Look at the figures in the widget provided by Hurricane Electric --> IPv6 is coming and fast. Emerging economies in Asia and Africa already have to use IPv6 natively because the IPv4 address have been exhausted. The last thing you want is a new market unable to access your website because you haven't got round to provisioning your website for IPv6.
7) My final thought is that within your organisation you should agree a policy on how to write IPv6 address and stick to it. You can choose to stick with typing out the full 128-bit address (8 groups of 4 Hexadecimal figures), You can choose to simply drop leading zero's, or agree to drop all leading zero's and replace contiguous groups of 4 zeros with a ::. Which ever method of representing an IPv6 address you choose make sure everyone sticks to it because it will make things easier when trouble shooting if the address format appears the same throughout your network.
Subscribe to:
Posts (Atom)