Still with me? Good stuff! We’re almost done. Last up is the OSPF Type 7 NSSA External LSA.
Monday, November 5, 2012
Thursday, November 1, 2012
OSPF External LSA: Type 5
Welcome to the OSPF Type 5 LSA!
The Type 5 LSA is used to advertise routes that are external to the OSPF domain within the OSPF domain (hence the External moniker). There are two types of Type 5 LSA’s: Type 1 and Type 2 (seriously?). We’ll be looking at both here.
The Type 5 LSA is used to advertise routes that are external to the OSPF domain within the OSPF domain (hence the External moniker). There are two types of Type 5 LSA’s: Type 1 and Type 2 (seriously?). We’ll be looking at both here.
Tuesday, October 30, 2012
OSPF Summary LSA's: Type 3 & 4
And now for everyone’s favourite LSA, the Type 3 LSA!
Combined with everyone’s least favourite LSA, the Type 4 LSA!
Combined with everyone’s least favourite LSA, the Type 4 LSA!
Sunday, October 28, 2012
OSPF Network LSA: Type 2
Welcome back to my LSA re-review. No need for a long winded intro here. Let’s get at it.
Thursday, October 25, 2012
OSPF Router LSA: Type 1
Ahh yes, this is the part of the CCIE studying where I revisit topics that I’ve previously studied before but have since started to forget some of the finer details of. This is where my inability to pass the stupid lab combined with the finite amount of memory capacity I have becomes a pain in the ass and forces me to redo things. This is where I my blogging takes on a morose tone and I start to sound like a whiny little bitch.
OK, not really.
But this is where I am going to look at the six OSPFv2 LSA’s that we care about for the CCIE R&S lab. In detail. Hence the title.
First up; Type 1.
OK, not really.
But this is where I am going to look at the six OSPFv2 LSA’s that we care about for the CCIE R&S lab. In detail. Hence the title.
First up; Type 1.
Wednesday, October 24, 2012
Misleading Virtual Link Status
Fun times in discussing OSPF VIrtual Links tonight. Here's a quickie for posterity's sake.
R2#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 23, via interface Serial0/0/0, Cost of using 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Message digest authentication enabled
Youngest key id is 1
But is it up? The answer is yes, but nothing is working right now :)
R2#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 23, via interface Serial0/0/0, Cost of using 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Message digest authentication enabled
Youngest key id is 1
But is it up? The answer is yes, but nothing is working right now :)
Tuesday, October 16, 2012
Exploring the Cat3560 System MTU Command
A friend on Facebook asked the the following question in response to my first post on QinQ tagging:
For the first question though my first inclination was to reply saying that the system mtu command is used to specify the layer 3 payload, not the layer 2 payload (since the default is 1500 bytes). This line of thought was due to the logic of the L2 MTU being 1518 (1500 plus an 18 byte Ethernet header/trailer) and thinking that switches allow an extra 4 bytes (1522 total) when a Dot 1Q tag is added.
But then I thought about this and the L3 MTU line of thought doesn't add up... If it's the L3 MTU why are we adjusting it for the extra Dot 1Q tag at layer 2? And if the system mtu command is for layer 2 then why is it only 1500 (1504 for QinQ) and not 1518, 1522, or even 1526 for a double tagged frame?
Quick! To the DocCD!! There isn't a moment to lose!
Hey Jay, just curious if you can explain a bit further, but if there are two 802.1q tags, taking up 4 bytes each, should the system MTU be set to 1508? Also, say you have two customers each using VLAN 12 and they both want to be trunked across the service provider network, you would have to use different "access" VLAN's for the QinQ on the the customer facing interfaces, right? Say VLAN 99 for customer 1 and VLAN 100 for customer 2?If I can answer the second question first, yes, that is absolutely correct.
For the first question though my first inclination was to reply saying that the system mtu command is used to specify the layer 3 payload, not the layer 2 payload (since the default is 1500 bytes). This line of thought was due to the logic of the L2 MTU being 1518 (1500 plus an 18 byte Ethernet header/trailer) and thinking that switches allow an extra 4 bytes (1522 total) when a Dot 1Q tag is added.
But then I thought about this and the L3 MTU line of thought doesn't add up... If it's the L3 MTU why are we adjusting it for the extra Dot 1Q tag at layer 2? And if the system mtu command is for layer 2 then why is it only 1500 (1504 for QinQ) and not 1518, 1522, or even 1526 for a double tagged frame?
Quick! To the DocCD!! There isn't a moment to lose!
Friday, October 5, 2012
QinQ (inQ) Part 2
In the last post I set up a simple 802.1Q tunnel. Now I'm going to expand on that and illustrate some of the more advanced Layer 2 Protocol Tunneling that you can do on top of that.
The following is not for the faint of heart. You will be amazed, you will be confused. You may cry, and you may jump for joy. If you choose to go on, you have been warned.
Or something.
The following is not for the faint of heart. You will be amazed, you will be confused. You may cry, and you may jump for joy. If you choose to go on, you have been warned.
Or something.
Thursday, October 4, 2012
QinQ (inQ) Part 1
This week I added 3 x 3560's to my home lab. I don't feel that overall I'm especially weak on the layer 2 topics, in fact I think quite the opposite is true. However, access to 3560's for labbing purposes has always been a bit harder for me so I decided to buy three of them out of my own pocket to help with the preparation. And besides, these are full layer 3 switches so I can also use them to help out with the routing topics as well.
So for anyone counting, that brings my lab to 3 x 1841, 3 x 3560, 1 x 2621xm and 1 x 2621. I do also have a 2950 and a 3500xl, but those are at my office and I'm not currently using them for labbing. This should be enough for me to lab up any tech that I need to.
Seeing as how the 2560's are new to me I of course wanted to play with something on them that I haven't been able to do on my routers. By a purely random selection that ended up being QinQ tunneling.
So without further ado here's an actual blog post!
So for anyone counting, that brings my lab to 3 x 1841, 3 x 3560, 1 x 2621xm and 1 x 2621. I do also have a 2950 and a 3500xl, but those are at my office and I'm not currently using them for labbing. This should be enough for me to lab up any tech that I need to.
Seeing as how the 2560's are new to me I of course wanted to play with something on them that I haven't been able to do on my routers. By a purely random selection that ended up being QinQ tunneling.
So without further ado here's an actual blog post!
A quick note on capturing 802.1q tags
I've been putting together a forthcoming post on QinQ tunneling and as part of that I wanted to capture some 802.1Q tagged frames with SPAN and Wireshark to display. I suppose my first mistake was trying to use Windows to do this... But I was capturing packets with an 802.1Q tag in them, just not the multiple tags I expected of the QinQ frames. I spent too many hours trying to figure out why it wasn't working the way I wanted it to, ripping apart the SPAN documentation, reading blog posts by bloggers I follow, and naturally, the Wireshark documentation itself.
Because I was seeing one tag I figured my Realtek PCIe GBE Family Controller network adapter must be able to handle tags, but why was it only striping off one tag and not both?
Turns out there is a fix here. If you go into the device properties from the Device Manager, click on the advanced tab, there's a 'Priority and VLAN" setting. In there the default was "Priority and VLAN Enabled". To me I took this to me VLAN tags were enabled, so the NIC would understand tags and I would be able to see them. This was incorrect. What you want to do it set it to the disabled setting, and then the NIC will just blindly pass the frame on as is, and not process the tags! With the setting enabled the NIC was processing the first tag, stripping it, and passing along the rest of the frame with my inner QinQ tag in tact! Once I disabled this everything worked great and I was now capturing frames with multiple tags.
Stay tuned for the upcoming QinQ post!
Because I was seeing one tag I figured my Realtek PCIe GBE Family Controller network adapter must be able to handle tags, but why was it only striping off one tag and not both?
Turns out there is a fix here. If you go into the device properties from the Device Manager, click on the advanced tab, there's a 'Priority and VLAN" setting. In there the default was "Priority and VLAN Enabled". To me I took this to me VLAN tags were enabled, so the NIC would understand tags and I would be able to see them. This was incorrect. What you want to do it set it to the disabled setting, and then the NIC will just blindly pass the frame on as is, and not process the tags! With the setting enabled the NIC was processing the first tag, stripping it, and passing along the rest of the frame with my inner QinQ tag in tact! Once I disabled this everything worked great and I was now capturing frames with multiple tags.
Stay tuned for the upcoming QinQ post!
Monday, September 10, 2012
So here's my token "back in the saddle" blog post.
I've been doing anything other than studying lately. Since my last attempt in May I've been rather demoralized, mostly exhausted, and utterly disinterested in looking at anything that remotely resembles the CCIE R&S lab exam.
I suppose failing the thing four times will have that effect on a person.
But enough screwing around. I need to get this finished and move on with my life.
I have done a fair amount of thinking about this whole ordeal to date and I think I can see a few things that I should have done differently. First, I should not have taken the lab four times already. The first time I really wasn't ready, but it was the first time and you have to get it over with and see where you are at some point. I don't regret the first time, but the second I went back far too soon. I got it in my head that I didn't really miss the first time by much and that I could have passed, but that really was not the case. The third time I did pass config, but still no love. It was close, the closest I've come to passing, so I don't feel too bad about that one, but number four was the same knee-jerk "I can do it!" reaction that two was, and again I went back far too soon.
That's four attempts total, in a little over 5 months. Way too close together, and far too much me deluding myself about my abilities.
That's enough with the self loathing though. Shit happens, and I am truly thankful for both a very understanding employer (who is footing the bill), and a supportive wife who hasn't yet reached the point where she wants her husband back (don't say it...).
The plan going forward is to take the next couple months to start over, and look at everything from the ground up. No rushing into a new date, and no delusions about my skill level. Time to take a good look at where my skills are, and ensure that the next time is the last.
So here's my token "back in the saddle" blog post. I hope you've enjoyed it. You can also count on more content rich, awe inspiring, witty technical writing that you've come to know and love from me. Lots more. Because you, the fan, deserve only the best :)
I suppose failing the thing four times will have that effect on a person.
But enough screwing around. I need to get this finished and move on with my life.
I have done a fair amount of thinking about this whole ordeal to date and I think I can see a few things that I should have done differently. First, I should not have taken the lab four times already. The first time I really wasn't ready, but it was the first time and you have to get it over with and see where you are at some point. I don't regret the first time, but the second I went back far too soon. I got it in my head that I didn't really miss the first time by much and that I could have passed, but that really was not the case. The third time I did pass config, but still no love. It was close, the closest I've come to passing, so I don't feel too bad about that one, but number four was the same knee-jerk "I can do it!" reaction that two was, and again I went back far too soon.
That's four attempts total, in a little over 5 months. Way too close together, and far too much me deluding myself about my abilities.
That's enough with the self loathing though. Shit happens, and I am truly thankful for both a very understanding employer (who is footing the bill), and a supportive wife who hasn't yet reached the point where she wants her husband back (don't say it...).
The plan going forward is to take the next couple months to start over, and look at everything from the ground up. No rushing into a new date, and no delusions about my skill level. Time to take a good look at where my skills are, and ensure that the next time is the last.
So here's my token "back in the saddle" blog post. I hope you've enjoyed it. You can also count on more content rich, awe inspiring, witty technical writing that you've come to know and love from me. Lots more. Because you, the fan, deserve only the best :)
Thursday, July 5, 2012
Crashing The Nexus
I had an interesting day yesterday. I hit my first bug in Nexus, and it crashed the whole box. As this happened first thing in the morning I got to spend the rest of the day cleaning up the mess.
This happened on a 5596UP running 5.1(3)N1(1a)
If you have a config like this:
Whatever you do, DO NOT DO THIS:
Upon trying to apply the new port profile before either removing the old one, or removing the phsycial interface from the port-channel the management session locked up, and after about 5 minutes a message came up saying the port profile manager process had crashed, and then the "System is going down for REBOOT now!" message.
TAC came back and said I'd hit this bug, but with a trigger not mentioned.
Good times...
This happened on a 5596UP running 5.1(3)N1(1a)
If you have a config like this:
port-profile type ethernet iSCSI
switchport mode access
spanning-tree port type edge trunk
spanning-tree bpduguard enable
switchport access vlan 9
state enabled
port-profile type port-channel Converged
switchport mode trunk
switchport trunk allowed vlan 4-5, 11
switchport trunk native vlan 1000
spanning-tree port type edge trunk
spanning-tree bpduguard enable
state enabled
interface port-channel17
inherit port-profile Converged
speed 10000
vpc 17
interface Ethernet1/17
switchport mode trunk
switchport trunk native vlan 1000
switchport trunk allowed vlan 4-5,11
channel-group 17 mode active
Whatever you do, DO NOT DO THIS:
Nexus5K# en
Nexus5K# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Nexus5K(config)# int e1/17
Nexus5K(config-if)# inherit port-profile iSCSI
Upon trying to apply the new port profile before either removing the old one, or removing the phsycial interface from the port-channel the management session locked up, and after about 5 minutes a message came up saying the port profile manager process had crashed, and then the "System is going down for REBOOT now!" message.
TAC came back and said I'd hit this bug, but with a trigger not mentioned.
Good times...
Tuesday, June 5, 2012
Frame Relay Pseudo Broadcasts -- The IRC Explanation
You can all blame Jeremy Gaddis for this being a Blog post. Taken from #cciestudy on irc.freenode.net.
19:04 < system5> jdsilva: you talking about my question as to whether psudo-broadcasting is
done as part of the routing protocol code or as part of the frame relay
implementation code?
19:05 < jdsilva> I don't know... I didn't read any of the wall of text from you in my window
19:05 < jdsilva> was Pandom asking somethign related to a question you asked?
19:05 < system5> jdsilva: nope, two unrelated questions
19:05 < jdsilva> ok
19:06 < jdsilva> I was responding to Pandom
19:06 < system5> jdsilva: mine is a frame relay question I'm researching, his was about P2p
links
19:06 < jdsilva> I just sat down, and it was the latest thing I saw
19:07 < system5> jdsilva: the whole frame relay "pseudo broadcast" thing for routing updates
isn't something I really understand at the low level yet as in I don't
understand all the low level pieces of how it works
19:07 < jdsilva> there isn't a lot to it
19:07 < system5> I know that it does work and how to configure it, but I don't understand the
how or why it works
19:07 < jdsilva> the same frame is sent out every DLCI
19:07 < jdsilva> esy
19:07 < jdsilva> easy
19:08 < system5> jdsilva: it would need to look at the subnets and inverse arp though right? to
decide which DLCI's to forward out to?
19:08 < jdsilva> frame is at layer 2, it doesn't care about subnets
19:09 < jdsilva> it's operating on that multipoint interface, be it the physical, or a
subinterface
19:09 < system5> jdsilva: and which part of the router manages the pseudo broadcasting? does
the routing protocol pseudo broadcast to make up for an inadequacy in frame
relay? or does frame relay pseudobroadcast to trick the routing protocol?
19:09 < jdsilva> again, a routing protocol is up in layer 3
19:09 < jdsilva> totally irrelevant
19:10 < system5> ok so frame relay does the pseudo broadcasting to trick the routing protocol,
got it, because FR is in L2 and the IGP is in L3
19:10 < jdsilva> not just the routing protocol
19:10 < jdsilva> ok, go back to a blank slate for a second
19:10 < jdsilva> just you, floating in nothingness
19:10 < jdsilva> no frame, no routing protocols
19:10 < jdsilva> :P
19:10 < system5> jdsilva: k
19:11 < jdsilva> ok, add back in frame relay, but ONLY frame relay
19:11 < system5> k
19:11 < jdsilva> no layer 3 nonsense
19:11 < jdsilva> you have a multipoint frame relay interface
19:11 < system5> now all that matters is the DLCI because it's the L2 address, like mac address
is for ethernet :-)
19:11 < jdsilva> it's frame relay becuase it's set to encapsulate exiting frame with headers as
defined by the frame relay forum
19:12 < jdsilva> yes, for the most part that's correct
19:12 < jdsilva> they do work very differently, but that's not really important here
19:12 < jdsilva> also for right now there's no inverse arp
19:12 < jdsilva> so only static frame mappings
19:13 < jdsilva> so we have a multipoint interface that knows to get to 1.1.1.1 send out dlci
1, and to get to 2.2.2.2 send out dlci 2
19:13 < jdsilva> (to keep it simple)
19:13 < system5> k
19:14 < jdsilva> so, now a packet is dispatched to the interface from the routing processor in
the router
19:14 < jdsilva> so all "routing" is now down
19:14 < Pandom> I get up to make a coffee and bam. One sec.
19:14 < jdsilva> or whatever process occurred to get the packet to the interface
19:14 < system5> Pandom: dude you are interrupting his awesome frame relay explanation
19:14 < jdsilva> it's irrelevant
19:15 < jdsilva> the interface receives the packet, and sees that the destination is a broadcat
address
19:15 < jdsilva> or a multicasst, or whatever
19:15 < jdsilva> it needs to go to more than one place
19:15 < jdsilva> that's really all it sees, it needs to go to more than one place
19:15 < jdsilva> so it makes copies of the packet
19:16 < jdsilva> it makes one copy for each dlci configured with pseudo broadcast enabled, as
defined in the frame maps
19:16 < jdsilva> so in our case, it makes two copies: for dlci 1 and dlci 2
19:16 < jdsilva> it then encapsulates both packets, one with a dst dlci of 1, and one with a
dst dlci or 2
19:17 < jdsilva> (that's not reaaly right, but it's good enough for now)
19:17 < jdsilva> and then it sends the two frames, one at a time
19:17 < jdsilva> two layer 2 unicasts
19:17 < jdsilva> to each dlci
19:18 < jdsilva> the layer 3 headers will still have the layer 3 multicast dst in the hedes
19:18 < jdsilva> but since there's no such thing as a broadcast or multicast in Frame it can't
send one
19:18 < jdsilva> so it sends one unicast for each dlci, to simulate a broadcast
19:18 < jdsilva> done
19:18 < jdsilva> life goes on
19:04 < system5> jdsilva: you talking about my question as to whether psudo-broadcasting is
done as part of the routing protocol code or as part of the frame relay
implementation code?
19:05 < jdsilva> I don't know... I didn't read any of the wall of text from you in my window
19:05 < jdsilva> was Pandom asking somethign related to a question you asked?
19:05 < system5> jdsilva: nope, two unrelated questions
19:05 < jdsilva> ok
19:06 < jdsilva> I was responding to Pandom
19:06 < system5> jdsilva: mine is a frame relay question I'm researching, his was about P2p
links
19:06 < jdsilva> I just sat down, and it was the latest thing I saw
19:07 < system5> jdsilva: the whole frame relay "pseudo broadcast" thing for routing updates
isn't something I really understand at the low level yet as in I don't
understand all the low level pieces of how it works
19:07 < jdsilva> there isn't a lot to it
19:07 < system5> I know that it does work and how to configure it, but I don't understand the
how or why it works
19:07 < jdsilva> the same frame is sent out every DLCI
19:07 < jdsilva> esy
19:07 < jdsilva> easy
19:08 < system5> jdsilva: it would need to look at the subnets and inverse arp though right? to
decide which DLCI's to forward out to?
19:08 < jdsilva> frame is at layer 2, it doesn't care about subnets
19:09 < jdsilva> it's operating on that multipoint interface, be it the physical, or a
subinterface
19:09 < system5> jdsilva: and which part of the router manages the pseudo broadcasting? does
the routing protocol pseudo broadcast to make up for an inadequacy in frame
relay? or does frame relay pseudobroadcast to trick the routing protocol?
19:09 < jdsilva> again, a routing protocol is up in layer 3
19:09 < jdsilva> totally irrelevant
19:10 < system5> ok so frame relay does the pseudo broadcasting to trick the routing protocol,
got it, because FR is in L2 and the IGP is in L3
19:10 < jdsilva> not just the routing protocol
19:10 < jdsilva> ok, go back to a blank slate for a second
19:10 < jdsilva> just you, floating in nothingness
19:10 < jdsilva> no frame, no routing protocols
19:10 < jdsilva> :P
19:10 < system5> jdsilva: k
19:11 < jdsilva> ok, add back in frame relay, but ONLY frame relay
19:11 < system5> k
19:11 < jdsilva> no layer 3 nonsense
19:11 < jdsilva> you have a multipoint frame relay interface
19:11 < system5> now all that matters is the DLCI because it's the L2 address, like mac address
is for ethernet :-)
19:11 < jdsilva> it's frame relay becuase it's set to encapsulate exiting frame with headers as
defined by the frame relay forum
19:12 < jdsilva> yes, for the most part that's correct
19:12 < jdsilva> they do work very differently, but that's not really important here
19:12 < jdsilva> also for right now there's no inverse arp
19:12 < jdsilva> so only static frame mappings
19:13 < jdsilva> so we have a multipoint interface that knows to get to 1.1.1.1 send out dlci
1, and to get to 2.2.2.2 send out dlci 2
19:13 < jdsilva> (to keep it simple)
19:13 < system5> k
19:14 < jdsilva> so, now a packet is dispatched to the interface from the routing processor in
the router
19:14 < jdsilva> so all "routing" is now down
19:14 < Pandom> I get up to make a coffee and bam. One sec.
19:14 < jdsilva> or whatever process occurred to get the packet to the interface
19:14 < system5> Pandom: dude you are interrupting his awesome frame relay explanation
19:14 < jdsilva> it's irrelevant
19:15 < jdsilva> the interface receives the packet, and sees that the destination is a broadcat
address
19:15 < jdsilva> or a multicasst, or whatever
19:15 < jdsilva> it needs to go to more than one place
19:15 < jdsilva> that's really all it sees, it needs to go to more than one place
19:15 < jdsilva> so it makes copies of the packet
19:16 < jdsilva> it makes one copy for each dlci configured with pseudo broadcast enabled, as
defined in the frame maps
19:16 < jdsilva> so in our case, it makes two copies: for dlci 1 and dlci 2
19:16 < jdsilva> it then encapsulates both packets, one with a dst dlci of 1, and one with a
dst dlci or 2
19:17 < jdsilva> (that's not reaaly right, but it's good enough for now)
19:17 < jdsilva> and then it sends the two frames, one at a time
19:17 < jdsilva> two layer 2 unicasts
19:17 < jdsilva> to each dlci
19:18 < jdsilva> the layer 3 headers will still have the layer 3 multicast dst in the hedes
19:18 < jdsilva> but since there's no such thing as a broadcast or multicast in Frame it can't
send one
19:18 < jdsilva> so it sends one unicast for each dlci, to simulate a broadcast
19:18 < jdsilva> done
19:18 < jdsilva> life goes on
Sunday, April 1, 2012
The New (Old?) CCIE R&S Lab Blueprint
So I'm hanging out in #cciestudy on irc.freenode.net (yes, you should come on by and get nerdy with us!) and the discussion turned to whether dot1q tunneling was on the blueprint. I whipped out the printed copy I have on my desk and sure as heck, there is was: item 1.2.36. However, it would appear that there is an "updated" version of the blueprint on Cisco's website that not only doesn't explicitly have dot1q tunneling on it, but it's 4 pages shorter than the copy I have!
Here's what is on Cisco's site right now:
http://www.box.com/shared/8a58de4ad249a23c2acd
The weird thing is this "new" version is dated 2009.
And here is the copy I have been working from for some time now:
http://www.box.com/shared/5a85f149952b99a67d01
This "old" version is dated 2010 and is a full 4 pages longer.
Now I realize it's just a blueprint, but WTF Cisco? You don't have to be so brief about the exam topics. It's hard enough, at least let people know what they should be studying.
Here's what is on Cisco's site right now:
http://www.box.com/shared/8a58de4ad249a23c2acd
The weird thing is this "new" version is dated 2009.
And here is the copy I have been working from for some time now:
http://www.box.com/shared/5a85f149952b99a67d01
This "old" version is dated 2010 and is a full 4 pages longer.
Now I realize it's just a blueprint, but WTF Cisco? You don't have to be so brief about the exam topics. It's hard enough, at least let people know what they should be studying.
Sunday, February 26, 2012
The Ridiculously Long and Complicated BGP Command 'neighbor local-as'
Few commands in IOS are as seemingly long and as confusing to me as what the BGP command 'neighbor local-as' command can be. This command can extend a further 3 more keywords that each change the behavior quite a bit. I've studied this before, and I always think I have it down, then after some time I come back to it and sit there staring at my screen with a stupid look on my face and a little bit of drool coming out the corner of my mouth while I re-learn it again. Here's to hoping that a little blog action finally once and for all gets this one into my head.
Subscribe to:
Posts (Atom)