Usernames, Passwords and AAA - The IOS Dilema

When creating a local username in Cisco IOS context sensitive help leaves one with a sense of confusion, as seen in v12.4:

Tribbles(config)#username fuzzy privilege 15 ?
  [snip]
  password             Specify the password for the user
  privilege            Set user privilege level
  secret               Specify the secret for the user
  [snip]

What the heck is a secret?  Perhaps an alternate rendering of this context sensitive help would be useful:

Tribbles(config)#username fuzzy privilege 15 ?

  [snip]

  password             Specify the password for the user which will not be encrypted, but just obfuscated by an easily reversible algorithm. Don't forget to run 'service password-encryption' or it will be in clear text.  Srsly!

  privilege            Set user privilege level.  Use 0 in combination with 'password'

  secret               Specify the super secret pasword that will be securely hashed with MD5 for the user.  Different than the enable secret, FWIW.

  [snip]

Oh yeah, and don't do this (although it will be securely stored):

Tribbles(config)#username fuzzy privilege 15 secret password INF3$T3D

Or this (trailing space)

Tribbles(config)#username fuzzy privilege 15 password Tr@ling_space 

Tribbles(config)#service password-encryption

These show up in the config after as:

username fuzzy privilege 15 secret 5 $1$wG8o$dbS1qR62s1JRvyQ9yTRr90

username fuzzy privilege 15 password 7 06321D014047071E3A04020A0F016A

Without the trailing space, the second entry will show up as:

username fuzzy privilege 15 password 7 1331053207050A2D143738323627

Cisco 7 hashing is easily reversible, and discouraged by Cisco.

Note: If you have a spare moment, decipher the Cisco 7 string on their KB page above to see what they really think of us :)


Now you are thinking "This is all well and good, and surprisingly well-written and entertaining, but I use a RADIUS/TACACS server.  I don't need to worry about this...right?"


Cisco does recommend the use of Radius/TACACS+.  Just make sure that you read the docs when creating the AAA policy (put the network authentication source before 'local').


Tribbles(config)#aaa authentication login test tacacs+ local

It is crucial to understand how IOS processes authentication attempts:

1. With a network service listed before local, IOS attempts to locate the authentication server
2. If successful, credentials are processed.  If the user is found (regardless of correct credentials) the process will not continue to lower priority methods.
3. If the user is not found, or if the network resource is unavailable IOS will continue down the list of aaa authentication.

Based on my (brief) testing it appears IOS 12.4 does add MD5 salt to the secrets, this may create some problems when auditing configurations:


Tribbles(config)#username salt secret pepper

Tribbles(config)#username seasalt secret pepper
Tribbles(config)#do sh run | i username
username salt secret 5 $1$L8kO$d0ZWXWnTOzcJ5Q43OqR2x1
username seasalt secret 5 $1$LZEf$RSfqWT3OZtb1xW.oXsNiA.


In closing:

• be sure to regularly rotate your passwords.  Especially your local 'rescue' passwords
• check that your AAA authentication order is correct
• replace all Cisco 7 hashes with secrets (and change the passwords)

More on this from the Junos point of view later.

BGP Confederations, or “The private AS”

One of the ways to decrease the number of full-mesh iBGP peers in an AS is the use of BGP confederations.  Route Reflectors can also be used (I cover them in IOS and Junos)

Defined in RFC 3065:

A BGP confederation is a group of iBGP speakers that acts as a disparate sub-AS within an organization.  

A good way to envision BGP confederation groups is to  liken their behavior, roughly, to that of private VLANs.  When a group of BGP speakers is segmented into a confederation, the peers act as iBGP speakers of said private AS, and connections to other confederations are done over eBGP.  

This significantly decreases the number of iBGP connections required within the organization.  Additionally the confederations may be viewed as separate administrative entities, reducing the configuration complexity in medium to large organizations.  

Note: IANA defines private AS #s as being the range of 64512 to 65535.

Note 2: Many readers may only be familiar with the 16bit AS space (1-65535) but this was extended in RFC 4893 to a "4 octet number".  Sound familiar?  It should.

Confederations do add complexity to policies dependent upon the AS_PATH attribute, as this field is subject to the standard rules of AS prepending--perhaps mutating the path-vector nature of the BGP routing protocol in a way that may lead to:

• sub-optimal routing decisions, or 
• overly complicated route manipulation.

Within the BGP packet between different confederation AS units, the path segment type of the confederation AS is set to AS_CONFED_SEQ, whereas a standard BGP update via a public AS will be advertised as a AS_SEQUENCE path type.  

The confederation as appears in the BGP table enclosed by parentheses, e.g.: (65421).  Between a confederation AS and a public AS the eBGP connection strips the AS_CONFED_SEQUENCE leaving only the AS path of the:

 NCC1701D(config-router)#bgp confederation identifier [AS]

As with normal iBGP peering, routes shared between the iBGP speakers within a confederation advertise prefixes with a null AS_PATH.  Neighbor confederation prefix advertisement follows the iBGP rule of un-modified next hop addresses.

IOS includes a neighbor statement of remove-private-AS to strip off the private AS #s for outgoing eBGP updates.  Based on lab testing, it appears that this is not necessary for IOS 12.4 peering.

Loop prevention is provided via the standard BGP AS_PATH rules.

Configuration is somewhat counterintuitive.  Assuming a pristine AS, confederations should be created as groups of fully meshed iBGP speakers.  The confederations should be fully connected, however it is not required for confederation border routers to be fully meshed.  They treat inter-confederation peering as eBGP, remember?

Confederation AS numbers should be private, and peering confederation neighbors must have their sub-AS statically defined.  In this IOS example the confederation AS is 65421, the peer confederation is 65422 and the organization's AS is 34.

NCC1701D(config)#router bgp 65421

NCC1701D(config-router)#bgp confederation peer 65422

NCC1701D(config-router)#bgp confederation identifier 34

NCC1701D(config-router)#neighbor 192.168.34.43 remote-as 65421

NCC1701D(config-router)#neighbor 10.0.0.3 remote-as 65422 

NCC1701D(config-router)#network 10.0.0.0 mask 255.0.0.0

NCC1701D(config-router)#network 192.168.34.0 mask 255.255.254.0

5 Easy Ways to Stay Healthy and Productive

1.  Enjoy what you are doing

This is the first and foremost most important way to stay productive and happy.  If you find yourself exploring thoughts or challenges that developed at work (in a healthy manner, not akin to always bringing home work) then you are doing well.

Over the years I have been able to easily single out people who:

• lack enthusiasm for what they are trying to accomplish, or
• consistently underperform their expectations and stagnate their careers.

This has become strikingly apparent among former coworkers of mine, who were working only for their paycheck.  Perhaps you have seen this yourself at your local coffee shop or big box retail store; associates who clearly do not enjoy what they are doing.  Sometimes you have to find enjoyment in the menial, yet necessary tasks of daily work.


2.  Find a way to challenge yourself

Analogous to enjoyment, challenges are what define a career path instead of ‘just a job’.  This can be better said as:

‘If you aren’t learning, why even bother coming to work?’

By challenging yourself at work you are helping yourself in many ways:

• helping with your enjoyment.  Studies have correlated 'challenging' work environments with promoting better performance, and often better paid positions
• demonstrating to management that you are a candidate for advancement, as well as strengthening an argument for a pay raise
• finding enjoyment in what you do

3. Exercise

30 minutes a day, 4 days a week.  When you think about this you have 168 hours in a week, and spending 2 of them exercising is around 1.2% of your time.  This is probably less time than you spend commuting to work

Personally I prefer to ride a stationary cycle with my headphones and ebook reader.

There are some non-conventional in-home exercise techniques that have generated a lot of internet buzz:

• Shovelgloving
• one hundred pushups
• p90x

Exercise can also be as simple as a walk around the block, it does not have to be striving to meet Tony Horton's level of fitness.

Please talk to your doctor before spontaneously beginning a rigorous exercise program.


4. Wake up early

The internet is awash with suggestions on how to wake up early:

• get a pet
• do yoga
• become more spiritual
• consume less caffeine

I do not have such lofty expectations.

For me, the easiest way to wake up early is to put an alarm clock in another room which forces me to turn on the light when it goes off.  This also helps to keep me from jumping right back in bed.

I highly recommend "Clocky" as an effective alarm clock.  (Note: It is really loud and sounds as described by one owner "R2D2 on crack")

Rising early won't work 100% of the time, some lapses are to be expected.  Stick with it and you will have an extra hour or two in the morning to exercise or get into work early :)


5. Smaller, healthier meals

Aim for a balanced meal most of the time.  Personally, I enjoy a good In-N-Out burger every once in a while and am a sucker for good pizza.  The US government provides dietary guidelines in more than one place but it is easy to get lost in the mountainous texts.

I try to adhere to a few guidelines:

• more vegetables, less sauce
• whole grain whenever possible
• less red meat
• only a little cheese
• fruits, fruits, fruits
• cut back on sodas

• From US Dietary Guidelines: "Beverages also contribute substantially to overall dietary and energy intake. Although they provide needed fluid, beverages often add calories to the diet without providing nutrient"

Do what you can, and remember you may even live longer :)

Juniper: BGP Route Reflectors

As with IOS I am presenting the Route Reflector setup between 3 Juniper routers (Olive).

The setup is almost the same, but I am going to cover the configuration in slightly more detail, as familiarity with IOS appears to be more common. This assumes that the Juniper boxes have already been configured with hostnames and root passwords.

Here is the topology I am using:

1. Configure IP addressing (RR as example)

I always configure the loopback address first. Many routing protocols rely on this.

# set interfaces lo0 unit 0 family inet address 1.3.3.7/32

# set interfaces em0 unit 0 family inet address 10.12.0.1/24

# set interfaces em1 unit 0 family inet address 10.13.0.1/24

(Aside: an easy way to pull these commands after they have been configured is

# run show configuration interfaces lo0.0 | display set

)

2. Set up routing autonomous system

In this case we are working with iBGP so all three routers will be within the same AS

# set routing-options autonomous-system 503

3. Configure the BGP group

Groups allow Junos to logically bunch settings together. Much like the peer-group in IOS. I chose the name IBGP to reflect the work we will be doing. I also like to use all-caps when defining names in Junos as it is easier for me to recognize.

# edit protocols bgp group IBGP

(Another bonus with Junos is all variable names are tab completable:

# edit protocols bgp group ?

Possible completions:

Group name

IBGP Group name

Cool huh?)

4. Edit BGP group settings

Here we set the AS of the peers, their IP addresses and other things like policies :)

Note: usually we would peer using loopback addresses for redundancy. In most production designs redundant connections would allow multiple IGP paths to lo0.0. That is not the case in this example.

RR:

[edit protocols bgp group IBGP]

# set peer-as 503

# set type internal

# set neighbor 10.12.0.2

# set neighbor 10.13.0.3

# commit

R2:

[edit protocols bgp group IBGP]

# set peer-as 503

# set type internal

# set neighbor 10.12.0.1

# commit

R3:

[edit protocols bgp group IBGP]

# set peer-as 503

# set type internal

# set neighbor 10.13.0.1

# commit

5. Stand by and allow BGP to come up (30s or so). Verify:

# run show bgp summary

Groups: 1 Peers: 2 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State Pending

inet.0 0 0 0 0 0 0

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

10.12.0.2 503 3 3 0 2 0 0/0/0/0 0/0/0/0

10.13.0.3 503 3 2 0 2 0 0/0/0/0 0/0/0/0

See if you can notice something odd with this output

5. Check routing table on the RR:

# run show route protocol bgp

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

No routes?

The default behavior of Junos is to accept all NLRIs advertised from peers, but not to advertise any prefixes unless they are specified in an export policy.

6. Define an export policy to send all connected routes:

Policies can be very complex, so I am going to create a very simple one named IBGP:

# edit policy-options policy-statement IBGP

[edit policy-options policy-statement IBGP]

# set policy-options policy-statement IBGP from protocol direct

# set policy-options policy-statement IBGP then accept

This takes all prefixes that are directly connected and places them in the BGP Adjacency-RIB-out for advertisement.

7. Apply the policy to the BGP group

# top edit protocols bgp group IBGP

[edit protocols bgp group IBGP]

# set protocols bgp group IBGP export IBGP

# top commit

8. Verify that prefixes are being seen by the routers

# run show bgp summary

Groups: 1 Peers: 2 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State Pending

inet.0 4 2 0 0 0 0

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

10.12.0.2 503 22 22 0 2 8:23 1/2/2/0 0/0/0/0

10.13.0.3 503 22 21 0 2 8:23 1/2/2/0 0/0/0/0

And check the routing table on the RR:

# run show route protocol bgp

inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2.3.3.7/32 *[BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.13.0.3 via em1.0

3.3.3.7/32 *[BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.12.0.2 via em0.0

10.12.0.0/24 [BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.12.0.2 via em0.0

10.13.0.0/24 [BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.13.0.3 via em1.0

Looks good....right?

Remember that pesky split horizon rule of iBGP? Let's check the routing table on one of the spoke routers for the loopback address of the other spoke (3.3.3.7/32):

# run show route 2.3.3.7

[edit]

Apparently reflection is not running. This can also be seen from the full BGP neighbor output:

# run show bgp neighbor | match cluster

[edit]

Nothing. All we have to do to fix this is turn on router-reflection on the hub router. In IOS we would define each peer or peer-group as being a route-reflector-client. In juniper the idea is similar, but we set a cluster ID on the desires route reflector(s):

# edit protocols bgp group IBGP

[edit protocols bgp group IBGP]

# set cluster 7.3.3.1

[edit protocols bgp group IBGP]

# commit

commit complete

And let's check the full BGP neighbor output:

# run show bgp neighbor | match cluster

Options:

Options:

This should allow the spokes to see each other's loopback prefix:

# run show route 2.3.3.7

inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2.3.3.7/32 *[BGP/170] 00:01:04, localpref 100

AS path: I

> to 10.12.0.1 via em0.0

And the other spoke:

# run show route 3.3.3.7

inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

3.3.3.7/32 *[BGP/170] 00:01:38, localpref 100

AS path: I

> to 10.13.0.1 via em0.0

To recap, here are the configs:

RR# show | display set | except "version|system"

set interfaces em0 unit 0 family inet address 10.12.0.1/24

set interfaces em1 unit 0 family inet address 10.13.0.1/24

set interfaces lo0 unit 0 family inet address 1.3.3.7/32

set protocols bgp group IBGP type internal

set protocols bgp group IBGP export IBGP

set protocols bgp group IBGP cluster 7.3.3.1

set protocols bgp group IBGP peer-as 503

set protocols bgp group IBGP neighbor 10.12.0.2

set protocols bgp group IBGP neighbor 10.13.0.3

set policy-options policy-statement IBGP from protocol direct

set policy-options policy-statement IBGP then accept

R3# show | display set | except "version|system"

set interfaces em0 unit 0 family inet address 10.12.0.2/24

set interfaces lo0 unit 0 family inet address 3.3.3.7/32

set protocols bgp group IBGP type internal

set protocols bgp group IBGP export IBGP

set protocols bgp group IBGP peer-as 503

set protocols bgp group IBGP neighbor 10.12.0.1

set policy-options policy-statement IBGP from protocol direct

set policy-options policy-statement IBGP then accept

R3# show | display set | except "version|system"

set interfaces em0 unit 0 family inet address 10.13.0.3/24

set interfaces lo0 unit 0 family inet address 2.3.3.7/32

set protocols bgp group IBGP type internal

set protocols bgp group IBGP export IBGP

set protocols bgp group IBGP peer-as 503

set protocols bgp group IBGP neighbor 10.13.0.1

set policy-options policy-statement IBGP from protocol direct

set policy-options policy-statement IBGP then accept

That's all for now. Please ask any questions you may have.

/m

BGP Route Reflectors, or “Disabling BGP split horizon”

Aside: In keeping with the goals of 3Facets, I am starting off with an article on BGP Route Reflection (professional). This may show up elsewhere on the internet however I am the original author.

One of the most dreaded stipulations of the Border Gateway Patrol, as taken directly from RFC4271:

“When a BGP speaker receives an UPDATE message from an internal peer,

the receiving BGP speaker SHALL NOT re-distribute the routing

information contained in that UPDATE message to other internal peers”

This presents quite a problem in organizations where the iBGP speakers are not all fully meshed, as seen below:

Imagine if this organization had 30 routers, or 230 routers--this would be impossible to setup and maintain.

There are two possible remedies. One is BGP confederations, the other is Route Reflectors (Henceforth referred to as RRs). A RR effectively disables the split-horizon mechanisms of BGP by allowing an iBGP speaker to advertise iBGP learner routes to other internal speakers. Documented in RFC2796, Route Reflectors are formally defined as “[a method of] alleviate the the need for "full mesh" IBGP” through “a BGP speaker advertising an IBGP learned route to another IBGP peer”

The effective use of RRs reduce the topology above to this:

This is an effective reduction in connections from (n2 - n) / 2 to n - 1, where n equals the number of iBGP speakers. For example, in the networks mentioned above with 30 and 230 speakers, they would be reduced from 435 to 29 connection and from 26335 to 229. The comparative graph of meshed connections to RRs is:

Now that the need for RRs is understood, the theory is quite simple:

1. A RR is peered with other iBGP speakers normally

2. The RR has a configuration option set to designate the downstream iBGP peers as RR clients

3. Non-client iBGP speakers peering with an RR is still subject to the non-transitive nature of iBGP to iBGP route advertisements

The term is self explanatory--The RR bounces routes down to the client speakers. The format of the advertisement is very similar to a standard BGP update:

As seen above the standard BGP update (with default attribute settings) contains the three well known mandatory attributes and two optionals: LOCAL_PREF and MED.

With the RR update, the inclusion of CLUSTER_LIST and ORIGINATOR. Not only do these signal the downstream router to add the route to its table, ignoring the iBGP rules. These attributes provide RR clusters with loop prevention.

Loop prevention in an RR topology is provided via:

1. The CLUSTER_ID BGP attribute. Each RR adds its cluster ID, which is by default the router ID (RID) of the RR, to route updates that are reflected to its downstream peers. This way routes do no become re-reflected into the cluster by way of redundant connections or multiple cluster RRs

2. ORIGINATOR_ID is labeled as the first iBGP speaker to advertise a prefix in a given AS. I a BGP speaker receives an advertisement with its own RID in said field, it discards the prefix.

3. Just as through normal operation of BGP, only the best routes are advertised to neighbors.

Configuration:

Easy as pie! All that needs to change is the addition of one statement per downstream peer in relation to the RR ‘server’. Here is the topology:

One of the spoke routers is advertising the network 33.3.3.3/29 into AS 503 via iBGP. Here is the BGP table on the RR server:

LolaBoat#sh ip bgp

BGP table version is 7, local router ID is 1.3.3.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.3.3.7/32 0.0.0.0 0 32768 i

*> 10.1.12.0/24 0.0.0.0 0 32768 i

*> 10.1.13.0/24 0.0.0.0 0 32768 i

*>i33.3.3.0/29 10.1.13.3 0 100 0 i

And the BGP table on the far spoke:

R2#sh ip bgp

BGP table version is 18, local router ID is 10.1.12.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.3.3.7/32 10.1.12.1 0 100 0 i

r>i10.1.12.0/24 10.1.12.1 0 100 0 i

*>i10.1.13.0/24 10.1.12.1 0 100 0 i

Note that the 33.3.3.0/29 prefix is missing. This is due to the hub router not advertising an iBGP learned route to another iBGP peer. We can see the hub is not advertising this route

LolaBoat#show ip bgp neighbors 10.1.12.2 advertised-routes

BGP table version is 9, local router ID is 1.3.3.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.3.3.7/32 0.0.0.0 0 32768 i

*> 10.1.12.0/24 0.0.0.0 0 32768 i

*> 10.1.13.0/24 0.0.0.0 0 32768 i

To fix this, the hub router is made into an RR. Please note this will drop any active BGP sessions:

LolaBoat(config)#router bgp 503

LolaBoat(config-router)#neighbor 10.1.12.2 route-reflector-client

*Mar 1 00:07:01.295: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Down RR client config change

*Mar 1 00:07:03.327: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Up

LolaBoat(config-router)#neighbor 10.1.13.3 route-reflector-client

LolaBoat(config-router)#

*Mar 1 00:07:16.467: %BGP-5-ADJCHANGE: neighbor 10.1.13.3 Down RR client config change

LolaBoat(config-router)#

*Mar 1 00:07:18.611: %BGP-5-ADJCHANGE: neighbor 10.1.13.3 Up

Now the RR (formerly referred to as the hub) will advertise the 33.3.3.0/29 prefix to the far spoke router:

LolaBoat#show ip bgp neighbors 10.1.12.2 advertised-routes

BGP table version is 11, local router ID is 1.3.3.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.3.3.7/32 0.0.0.0 0 32768 i

*> 10.1.12.0/24 0.0.0.0 0 32768 i

*> 10.1.13.0/24 0.0.0.0 0 32768 i

*>i33.3.3.0/29 10.1.13.3 0 100 0 i

And on the far spoke, success!

R2#sh ip bgp

BGP table version is 26, local router ID is 10.1.12.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.3.3.7/32 10.1.12.1 0 100 0 i

r>i10.1.12.0/24 10.1.12.1 0 100 0 i

*>i10.1.13.0/24 10.1.12.1 0 100 0 i

*>i33.3.3.0/29 10.1.13.3 0 100 0 i

You can see that the 33.3.3.0/29 prefix was reflected by closer inspection. The cluster list is present and is equal to the Loopback0 of the RR:

R2#sh ip bgp 33.3.3.0

BGP routing table entry for 33.3.3.0/29, version 26

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x820

Not advertised to any peer

Local

10.1.13.3 from 10.1.12.1 (1.3.3.7)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 10.1.13.3, Cluster list: 1.3.3.7

This can be changed on the RR simply (remember the decimal value will be converted to binary):

LolaBoat(config)#router bgp 503

LolaBoat(config-router)#bgp cluster-id 8675309

R2#sh ip bgp 33.3.3.0 | i Cluster

Originator: 10.1.13.3, Cluster list: 0.132.95.237

That is all for now. Stay tuned for a post detailing this in Junos as opposed to Cisco IOS :)

/m

Introduction

3Facets? 3Facets is meant to detail the interactions, development and progressions of the three facets of everyday life: 1. professional, 2. personal and 3. financial. Who am I? I go by the nickname Moose. I am a IT professional in my late twenties seeking to better myself and expand my horizons. When focusing on the 3Facets I will use technology as a medium to frugally enhance my skills and quality of life. My professional skills lie in the realms of system administration and network engineering, with continuing growth in the networking realm. I have an interest in finance and social economics (Especially after reading Freakonomics and Super Freakonomics). These 3Facets will be manifested in further posts in an attempt to better not only myself, but also my readers /m