Passed MPLS and BGP

I passed the MPLS and BGP exam on Thursday. This time around the questions seemed harder, but with the extra couple of weeks of study I passed fairly easily. Looking back on it I should have done the separate exams. The MPLS Fundamentals book is good, but not enough for the exam. There were a few things I had to rely on the "MPLS and VPN Architectures CCIP Edition" book for. I had underestimated the BGP section. While I have worked for an ISP before I didn't really understand some of what was happening under the covers (even though I new enough to make BGP do what I wanted). The "Internet Routing Architectures" book is still one of the better books for this exam, but it is not enough. I would say you need to do a little general design research as well.

On to BSCI. I am not really in a hurry to do the exam - I am planning on doing enough routing, IPv6 and Multicast study for the BSCI so that I am at CCIE written level. Once I have done that I'll do the exam then move on to studying the rest of the CCIE written.

Post exam

I missed out on passing. I was close - but no cigar. I would say the exam tested my BGP more than I expected. The MPLS portion focussed on a couple of areas I did not expect. There was a reasonable amount on the ATM side of things which was a surprise to me. I am not sure if Cisco uses "adaptive" exam technology, but it sure feels like it (I am sure I stuffed up an early question and then got hammered on that technology).

The scores at the end of the exam were really useless as far as re-focussing my study. The sections on it were:

• Technology
• Basic Implementation and Configuration
• Advanced configuration

It might as well have said theory, easy questions and hard questions.

Would have been nice if they split it up into maybe a few of the MPLS technologies, a few of the BGP topology types and then a catch all for the rest of BGP and MPLS.

BGP and MPLS exam

I've bitten the bullet and scheduled the MPLS and BGP exam for tomorrow. I've really spent way more time tinkering with BGP in the last week than I have with MPLS. That's probably more of a reflection of where my current interest is than what I need to know for the exam. I am happy with what I know about BGP now (I'd call it almost CCIE level knowledge). The MPLS study that I have done over the last week has been mainly focussed on the MPLS VPN and basic MPLS subjects. I did a final read through of the ATM subjects in the Fundamentals book earlier in the week (I know that is a bit of a weak spot in my knowledge). I haven't really studied AToM and VPLS that much in the last week, I don't really know them in depth but I am happy that it will be enough for the exam.

The things I KNOW I need to remember for the exam are:

• You need to be able to route to the IP address used for the router-id by LDP in order for an LDP session to establish (I keep reminding myself and forgetting when I lab something up)
• The different VPN types and overlay, peer-to-peer, extranet etc.
• BGP route selection process (really happy I know my stuff for this)
• Configuring VRFs and using multiple route-targets to allow overlapping and other types of VPNs.
• Using OSPF between the CE and PE routers (sham links are something I spent a while playing with on dynamips)
• Confederations, Route reflectors and how they impact BGP advertisements.
• BGP attributes and how to change them and what they REALLY do
• Multi-protocol BGP - address-family vpnv4 and address-family ipv4 vrf and what to put under each

I am sure there will be some general MPLS and LDP type questions (ie what tag would router x use to forward a packet, how does the icmp packet too big get delivered, how does LDP find neighbors etc). I am pretty happy I have that sorted.

I'd have to say once I had done an initial read of a few books I got the biggest value from using dynagen / GNS3 labbing things up and using wireshark to look at packets. I really understood HOW LDP worked once I saw the packets. The book didn't really say why LDP used a UDP stream and a TCP stream. After seeing it the UDP stream is just for hello packets and finding a neighbor via multicast. The TCP stream is for advertising labels (using the LDP router-ids for the source and destination). Why couldn't the Fundamentals book just say that?

The other thing I am always slipping up on is BGP neighbor establishment. I have a habit of mistyping IP addresses, mistyping AS numbers or forgetting eBGP multihop. I tend to struggle for a while and turn on debug ip bgp and then just recheck my configurations. I keep forgetting how powerful the show ip bgp neighbors command is.

Visio Icons

I'm sick of trying to find the Cisco Visio icons. The generic ones are at:
http://www.cisco.com/web/about/ac50/ac47/2.html

Re-focussing study

I was recently made redundant (very unexpected given that I only started the job 6 weeks ago), so I've spent a little time contemplating study and work. I've decided the current choices focus more on IP routing and switching rather than MPLS. So I'm refocussing on my CCIE written. Even though it is not a stand alone certification it does show you are serious.

So it's back to the books looking at snippets of information like - unicast flooding being caused by asymmetric routing or flapping links and STP TCNs.

Baby Giants and Jumbo Frames

Someone asked me about Jumbo frames so I thought I would take a bit of a look (partly because I have to look at Baby Giants anyway). Here is what I have found so far:

• Baby Giants have an MTU of up to 1600 bytes. Jumbo frames can be over 9000 bytes (the exact size depends on the switch platform and possibly IOS).
• Some Cisco switches and routers don't support baby giants or jumbo frames, usually because of ASIC limitations.
• If you just want baby giants so that you can put a single MPLS tag on a frame you can try changing the interface to use 802.1q trunking and then place your MPLS traffic in the native VLAN. This changes the MTU to 1504 (so it fits one tag) and is supported on most switches.
• The interface counters will count the baby giant or jumbo frame as being over-sized even if the interface can support it - this is cosmetic.
• Some devices allow you to set a separate MTU for 10/100 and Gigabit interfaces. One of these is the 3750. For the 10/100 interfaces you use the system mtu number command. For the Gig interfaces you use the system mtu jumbo number command. If you set the system mtu but not the system mtu jumbo then the Gig interfaces use the system mtu. The reason for the two commands is that the 10/100 interfaces only support a lower MTU than the Gig interfaces. Other than trying the commands or looking up on the Web there does not seem to be a way to find out what the maximum acceptable sizes are.

CCIP MPLS and BGP combo exam

I've decided I am going to do the CCIP combo MPLS and BGP exam. There are a couple of reasons - the biggest one is time. I really want to get the CCIP out of the way before the end of September and the CCIE written done by the end of October. Realistically the CCIE written exam will probably take more than a month to study for (even though September will be routing month). Even though I am going to do the BSCI in September (my BSCI exam expired about two or three years back) I still think I'll need a good four weeks for the CCIE written - between switching, multicast, frame-realy and QoS. It should all just be revision as I did the written a few years back and have done some hard core study for it a few months back.

I'm half thinking i should book the combo exam for two weeks time to put a little pressure on myself (I'm easily distracted at the moment). Looking at the BGP exam outline I keep thinking how hard could it really be... and then I remember how hard it really can be.

Back to the books.

BGP Prefix-based outbound route filtering

Every now and then you find a command that makes you think now someone is really thinking about this stuff.

BGP prefix-based outbound route filtering is one of those. If you only want to keep some of the routes from your neighbor this capability allows you to advertise the prefix list you are using to that neighbor. The neighbor then uses the prefix-list to filter the routes BEFORE it advertises them to you. This can significantly reduce the bandwidth and time taken to synchronise routes between two neighbors. The critical command is:
neighbor address capability prefixlist-orf [send | receive | both]

Once you have enterred that command (in the receive or both directions) if you enable a prefix-list to filter incoming routes your router will send the prefix list to your neighbor so that it can filter the routes for you.

The command has been around for a while (I stumbled on it when I was looking for something else and it was available in 12.2T). Some documentation is available in BGP Prefix-Based Outbound Route Filtering 12.2T

VTP (again)

It may seem obvious but VTP only works between devices that are using VTP. What this means is that if you have a trunk port pointing to a router which isn't doing VTP then VTP pruning is not going to work on that link. What's more if a switch has one interface that isn't doing VTP pruning then it means that switch will want ALL VLANs to come over its trunks towards the rest of the network.

The moral of the story - either manually configure which VLANs to forward on the trunk towards your routers OR enable VTP on the router, use VLAN interfaces and put the physical interface in switching mode.

FTP URLs including username and password

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.

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.

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.

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).

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.

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

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.

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.

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.

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).

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.

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

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

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.

Starting on MPLS

I decided to cut the cord on the Juniper study. It isn't really relevant to my new job, and I really wanted to get onto my CCIP study (so that I can get it over and done with before I get back to CCIE study). I finished writing my notes and did the exam on Tuesday without much real revision. I missed out on passing by 4 points. I would have preferred to fail by a heap (at least then I wouldn't regret taking the exam so quickly).

I've started my study for the CCIP MPLS exam. There's a lot of conflicting reports on which books to use if you are self studying. I've read a few that say to avoid the Sybex MPLS book. It's a bit disappointing - I've found them to be good in the past. Instead I have decided to go through the Cisco Press MPLS Fundamentals. After that I'll take a look through the MPLS and VPN Architectures books to clear up anything that the Fundamentals book misses. If there's still some holes I guess it is off to the documentation CD. I guess I will probably skim through some MPLS sections on the DocCD - I got caught last time I did my CCIE Written and now I'm a little gun shy on doing an exam based on just one or two books.

So far I'm about 10% of the way through noting the Fundamentals book.

Still sidetracked

OK - I've noted 75% of the pdf for the jncia-ex. I'm a bit torn about whether I should book the exam for Monday (there is a spot open), or study a bit longer and take the risk of having to do the exam some time next month. I really want to get it out of the way but I'm tired and unmotivated (too many hours of work this week). I think I'll see how the weekend pans out and book at the last possible minute.

I'm a little surprised at the content of the jncia-ex study guide. I would have thought there would be a whole lot on VLANs and other layer 2. Instead it seems to do broad brushstrokes over everything (switching, routing and firewalling). My 2 cents says that Juniper will launch a certification similar to the Cisco CCNP. It just makes sense that Juniper should have certifications that directly compete with Cisco's.

Distractions

At the moment I am sufferig from a few distractions - the Juniper switching exam (from Juniper's fast track) and a change of job happening in early July.

I'm hoping to polish off the Juniper exam very soon (I've half finished noting the study materials and I'm waiting on the Exam Voucher), but can't find a testing spot until early July. Once that's sorted I am planning on studying hard and fast for the MPLS exam from the CCIP. I may follow that up with the BGP exam from the CCIP. Both are going to be very important in my new job.

Unfortunately both will set my study for the CCIE written back some way - at least the MPLS is partially relevant to the written.