Just about every time I have to type in an FTP URL that contains both the username and password I have to look up what the syntax is. The syntax is:
ftp://username:password@hostname/
That syntax is a standard and works in most web browsers, the Cisco CLI and others.
Wednesday, July 30, 2008
Tuesday, July 29, 2008
Variables in banners
Sometimes it is handy to display the name of the device, the line number you are connected to or other details about a device in the banner. A complete list of the variables (and which banners they can be used in) is available in the Cisco document Slip-PPP and Banner Tokens.
I thought it would be handy to use those tokens in the name of the file for the archive command.... unfortunately it doesn't work. If you use:
archive
log config
hidekeys
path tftp://192.168.1.1/$(hostname)
write-memory
time-period 86400
All you end up with is a file called $(hostname)-0 on your tftp server. Hopefully it will be there in a future release.
I thought it would be handy to use those tokens in the name of the file for the archive command.... unfortunately it doesn't work. If you use:
archive
log config
hidekeys
path tftp://192.168.1.1/$(hostname)
write-memory
time-period 86400
All you end up with is a file called $(hostname)-0 on your tftp server. Hopefully it will be there in a future release.
Sunday, July 27, 2008
MPLS Fundamentals
I've finally finished reading and noting the CiscoPress MPLS Fundamentals book. It's only appropriate that I give my thoughts on the book. I was hoping it would be a bit like the Routing TCP/IP book - an easy read which slowly builds your knowledge until you look back and say "Oh my gawd how did I learn all that?". Well it was nothing like that. Some chapters were really "crunchy" full of facts and not enough words to make it clear or easy to read. Other chapters were just plain repetitive (the QoS one for example). I found it a little annoying how it introduced subjects. Often there would be two alternatives presented in a reasonable amount of depth followed up by a paragraph saying... "Cisco implemented option 1". There was also some plain bad editing - at least a few places where the example did not marry up with the text around it, and some where they talk about some numbered items and refer to one that doesn't exist in their list (ie they'd have a list of 4 items and refer to item 5).
Even after all of that I'd have to say I don't regret getting the book. It did cover most of the topics that are in the CCIP MPLS outline to a reasonable depth and covered a few extras that are useful. There were a few chapters that I could have skipped - but I read them anyway because the CCIP MPLS outline and the associated course differ so you can't be too sure what really is going to be on the exam. My recommendation would be to read the MPLS Fundamentals book cover to cover before you start writing notes. Then start again from page 1.
There is still a bit of a gap betweeen the book and the exam outline, so I am going to do a little more reading (not sure if I will grab another book or hit the DocCD and Cisco site). Either way I think I have about two weeks before I'll hit the exam - I'd like a week of solid GNS3 work at night as well as a while to go through my notes and flesh out the bits that the Fundamentals book didn't cover.
Even after all of that I'd have to say I don't regret getting the book. It did cover most of the topics that are in the CCIP MPLS outline to a reasonable depth and covered a few extras that are useful. There were a few chapters that I could have skipped - but I read them anyway because the CCIP MPLS outline and the associated course differ so you can't be too sure what really is going to be on the exam. My recommendation would be to read the MPLS Fundamentals book cover to cover before you start writing notes. Then start again from page 1.
There is still a bit of a gap betweeen the book and the exam outline, so I am going to do a little more reading (not sure if I will grab another book or hit the DocCD and Cisco site). Either way I think I have about two weeks before I'll hit the exam - I'd like a week of solid GNS3 work at night as well as a while to go through my notes and flesh out the bits that the Fundamentals book didn't cover.
Friday, July 25, 2008
MPLS QoS
I'm about 80% of the way through the book. My last week has been a study disaster. I've been busy at work and coming home feeling very flat and unmotivated. Luckily next week I should be doing some MPLS proof of concept and design work. This should mean I get to tinker with some MPLS VPN and QoS at the very least. Hopefully I can justify a little AToM and VPLS as well (we will eventually need to integrate one or both into our network).
Saturday, July 19, 2008
MPLS TE
I'm 2/3 of the way through the MPLS Fundamentals book now. Working through MPLS TE was a bit wierd. A lot of lead up and then a very short bit on how to actually get the traffic into the tunnels - I would have thought it was more logical to lay the chapter out the other way. I'm getting a bit impatient with the book. I'm planning on skimming through the rest of it and cherry picking what I think is relevant. It's looking like I might not do the exam this month unless I really get stuck into it now. Usually I would have finished writing my notes and done a reasonable amount of work in GNS3 by now. With the Cisco Secondchance promotion running at the moment I might just book the exam for the 31st and power through and see how I go.
Friday, July 18, 2008
Using screen to view another ssh session
Say you ssh into a host and another person is using ssh to connect to that same host. You can connect to the other session using screen
To attach to a screen session that is already running use screen -x
To attach to a screen session that is already running use screen -x
SSH port forwarding
Today I had a Unix box inside my network that I needed to allow a remote party to connect to. I didn't want to tinker with the firewall rules, so here is what I did.
ssh -R server:2222:localhost:22 username@server
What it is saying is redirect port 2222 on the server named server to port 22 on the localhost. The username@server is used to initiate the remote connection to the server that you want to do the redirection for. So to connect to your host the other party needs to ssh to the server and then ssh to localhost on that server using port 2222.
If you want to set up the port redirection from the server end you can use a -P instead of a -R.
ssh -R server:2222:localhost:22 username@server
What it is saying is redirect port 2222 on the server named server to port 22 on the localhost. The username@server is used to initiate the remote connection to the server that you want to do the redirection for. So to connect to your host the other party needs to ssh to the server and then ssh to localhost on that server using port 2222.
If you want to set up the port redirection from the server end you can use a -P instead of a -R.
Filter based on AS-path length
Say you want to only view those bgp prefixes that pass through two or fewer autonomous systems. You can use the following regular expression:
show ip bgp regexp ^[0-9]*_?[0-9]*$
I am sure some guru can write it much more consicely than that. Logically reading left to right it says start at the beginning of the AS path, then accept any set of numerals as an AS, then accept zero or one commas or spaces, then accept any set of numerals as an AS then match with the end of the AS path.
show ip bgp regexp ^[0-9]*_?[0-9]*$
I am sure some guru can write it much more consicely than that. Logically reading left to right it says start at the beginning of the AS path, then accept any set of numerals as an AS, then accept zero or one commas or spaces, then accept any set of numerals as an AS then match with the end of the AS path.
BGP neighbors and the remove-private-as command
Imagine you have a BGP router with a public AS number. It peers to a BGP router with a private AS number which in turn peers to a BGP router with a public AS number.
ie.
R1(AS 123) -> R2 (AS65000) -> R3 (AS 456)
On the final router (R3) you want to peer with another router with a public AS number and you want to remove the private AS from all routes.
I've tinkered around and can't find a way to do it. If you configure BGP on R3 similar to this:
router bgp 456
neighbor R4 remote-as 789
neighbor R4 remove-private-as
The prefixes from router R2 are advertised to R4 with an AS path of 456. The prefixes from router R1 are still advertised with an AS path of 456 65000 123. The reason for this is that the remove-private-as command sees the AS path as already having both public and private AS numbers and considers it a configuration error. Therefore it does not remove the private AS number.
ie.
R1(AS 123) -> R2 (AS65000) -> R3 (AS 456)
On the final router (R3) you want to peer with another router with a public AS number and you want to remove the private AS from all routes.
I've tinkered around and can't find a way to do it. If you configure BGP on R3 similar to this:
router bgp 456
neighbor R4 remote-as 789
neighbor R4 remove-private-as
The prefixes from router R2 are advertised to R4 with an AS path of 456. The prefixes from router R1 are still advertised with an AS path of 456 65000 123. The reason for this is that the remove-private-as command sees the AS path as already having both public and private AS numbers and considers it a configuration error. Therefore it does not remove the private AS number.
Tuesday, July 15, 2008
MPLS VPN
I'm about half way through the MPLS Fundamentals book. My opinion of it varies depending on the day. Sometimes it is clear and well thought out. Others the example configs don't match with the text and sentances make MPLS more confusing than it needs to be. I quite enjoyed the MPLS VPN section (in a wierd sort of way). It is good to see the more curious ways that BGP and OSPF can be configured. The use of communities to exchange EIGRP route properties via the provider's MP-BGP is kind of nifty too.
I'm planning on ramping up my study for the next two weeks so that I can polish off the exam late this month or very early next month. I'm already starting to look for a good BGP text. At the moment I think I am going to stick with Routing TCP/IP volume 2 plus a generous helping of the DocCD. Word from Cisco is that they are going to make more of the configuration guides into full book pdfs. I hope it happens before the end of the month (nothing annoys me more than having to download 8 or 9 PDFs to work offline with for one protocol).
I'm planning on ramping up my study for the next two weeks so that I can polish off the exam late this month or very early next month. I'm already starting to look for a good BGP text. At the moment I think I am going to stick with Routing TCP/IP volume 2 plus a generous helping of the DocCD. Word from Cisco is that they are going to make more of the configuration guides into full book pdfs. I hope it happens before the end of the month (nothing annoys me more than having to download 8 or 9 PDFs to work offline with for one protocol).
ACL Object Groups
Finally Cisco has done it. A feature that Pix has had for ages has finally made it into IOS (although it is only in 12.4(20)T so it will be a while before many people will be using it in the wild). Check out the post over at CCIE in 3 months.
Friday, July 11, 2008
CEF and recursive routes
I'd always thought recursive routing should be avoided at all costs. The big reason for this was that it was always hammered into me that it forced the router to do multiple routing table lookups before forwarding the packet. So it makes sense that you would be wasting significant CPU on a busy router.
In another part of my brain (that wasn't talking to the don't ever use recursive routing part) I knew that CEF cached forwarding tables and layer 2 details so that packets could be forwarded quickly.
It was only today that I realised that the tables CEF uses actually uses the REAL next hop (the one that you get when you recurse through all the routes). This means that the router theoretically only has to recurse through all the routes ONCE - at the time it builds the initial CEF tables.
So - recursive routing is not so bad after all
In another part of my brain (that wasn't talking to the don't ever use recursive routing part) I knew that CEF cached forwarding tables and layer 2 details so that packets could be forwarded quickly.
It was only today that I realised that the tables CEF uses actually uses the REAL next hop (the one that you get when you recurse through all the routes). This means that the router theoretically only has to recurse through all the routes ONCE - at the time it builds the initial CEF tables.
So - recursive routing is not so bad after all
Wednesday, July 9, 2008
CDP, VTP and Spanning-tree
Just a few things I have found over the last couple of days:
If you are getting duplex mismatches reported by CDP when there really isn't one you can use no cdp advertise-v2 on the link to turn that detection off. You may get that reported if you have the following layout:
cisco device (full duplex) -> non-cisco switch -> cisco device (half duplex)
Most commonly either the half-duplex device will be an ATA that only supports half-duplex OR you may have a non-cisco wireless device at one end that only supports half-duplex on the ethernet on one side and another non-cisco wireless device at the other end that does support full-duplex.
All that you lose with that CDP command is duplex mismatch detection, VTP domain advertisement and native vlan detection.
The other thing is a bit about spanning-tree and VTP. I'd always noticed that in companies with large numbers of VLANs most devices have been in VTP transparent mode. I assumed it was so that adding a switch with a higher VTP revision number would not nuke the VLAN database. There may be another good reason. Each vlan in the vlan database will have an STP instance. Not an issue for MST, but for PVST it is a big issue. You have higher memory requirements and you may exhaust the number of STP instances your switch can run.
VTP pruning does not help - it only reduces the number of VLANs that run over a trunk (verified by using show int trunk to see which vlans are allowed on the trunks and not pruned and then using show spanning-tree summary to verify which vlans have a spanning-tree instance).
Manually reducing the vlans running on a link using switchport trunk vlan allow does reduce the spanning-tree instances (you need to limit it on all trunk links on the switch you want to reduce spanning-tree instances on). The command must be used on the switch that you want to reduce spanning-tree instances for, using it on the switch at the other end of the link does not help (it only stops the VLAN traffic at that switches port, it doesn't stop the other one from sending traffic before it gets discarded).
The only other ways to reduce the STP instances reliably is to either turn spanning-tree off for some of the VLANs (not advisable), run MST or use VTP transparent and manually add the VLANs required on each of your switches as needed.
Updated: verified in Dynamips using a 3745 with a 16 port switch module and running 12.3-8.T5
If you are getting duplex mismatches reported by CDP when there really isn't one you can use no cdp advertise-v2 on the link to turn that detection off. You may get that reported if you have the following layout:
cisco device (full duplex) -> non-cisco switch -> cisco device (half duplex)
Most commonly either the half-duplex device will be an ATA that only supports half-duplex OR you may have a non-cisco wireless device at one end that only supports half-duplex on the ethernet on one side and another non-cisco wireless device at the other end that does support full-duplex.
All that you lose with that CDP command is duplex mismatch detection, VTP domain advertisement and native vlan detection.
The other thing is a bit about spanning-tree and VTP. I'd always noticed that in companies with large numbers of VLANs most devices have been in VTP transparent mode. I assumed it was so that adding a switch with a higher VTP revision number would not nuke the VLAN database. There may be another good reason. Each vlan in the vlan database will have an STP instance. Not an issue for MST, but for PVST it is a big issue. You have higher memory requirements and you may exhaust the number of STP instances your switch can run.
VTP pruning does not help - it only reduces the number of VLANs that run over a trunk (verified by using show int trunk to see which vlans are allowed on the trunks and not pruned and then using show spanning-tree summary to verify which vlans have a spanning-tree instance).
Manually reducing the vlans running on a link using switchport trunk vlan allow does reduce the spanning-tree instances (you need to limit it on all trunk links on the switch you want to reduce spanning-tree instances on). The command must be used on the switch that you want to reduce spanning-tree instances for, using it on the switch at the other end of the link does not help (it only stops the VLAN traffic at that switches port, it doesn't stop the other one from sending traffic before it gets discarded).
The only other ways to reduce the STP instances reliably is to either turn spanning-tree off for some of the VLANs (not advisable), run MST or use VTP transparent and manually add the VLANs required on each of your switches as needed.
Updated: verified in Dynamips using a 3745 with a 16 port switch module and running 12.3-8.T5
Friday, July 4, 2008
More MPLS
I'm about 20% of the way through the Cisco Press MPLS Fundamentals book. I've found it a bit of a slog this week. The book is an easy read for the first chapter or so, then it gets fairly dry for a while. I prefer to go through a bit of practical (show me the commands to keep my interest). Unfortunately the book is focussed more on the theory before showing you much of the CLI. The last chapter has been very repetitive, but at least it has had some commands and their output.
This week at work (first week in a new job) has been interesting. My brief for the week was to just "poke around" and see if I can find any issues in the network. I've cleaned up the world's worst Visio diagram (who in the world creates a text label for a router out of about 10 or 15 different text fields (one for each octet of the IP address, one for each of the dots, and one for each part of the router name). I've also spotted a wole heap of other issues. Spanning tree and VTP are a big issue - too many VLANs (more than the number of spanning-tree instances supported on most of the switches) and more than the number of VLANs that some of the switches support. It also appears that VTP pruning doesn't work as promised (most places I have worked haven't had that many VLANs, or have used transparent mode, so I haven't seen that before).
We've also been looking at using 31-bit masks on some of the links rather than the /30 masks we are currently using. Since we have a whole heap of those links it will make a considerable saving in the address space.
Well - it's off to do some GNS3 work on MPLS.
This week at work (first week in a new job) has been interesting. My brief for the week was to just "poke around" and see if I can find any issues in the network. I've cleaned up the world's worst Visio diagram (who in the world creates a text label for a router out of about 10 or 15 different text fields (one for each octet of the IP address, one for each of the dots, and one for each part of the router name). I've also spotted a wole heap of other issues. Spanning tree and VTP are a big issue - too many VLANs (more than the number of spanning-tree instances supported on most of the switches) and more than the number of VLANs that some of the switches support. It also appears that VTP pruning doesn't work as promised (most places I have worked haven't had that many VLANs, or have used transparent mode, so I haven't seen that before).
We've also been looking at using 31-bit masks on some of the links rather than the /30 masks we are currently using. Since we have a whole heap of those links it will make a considerable saving in the address space.
Well - it's off to do some GNS3 work on MPLS.
Subscribe to:
Posts (Atom)