dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
17632
share rss forum feed


battleop

join:2005-09-28
00000

1 recommendation

reply to TomS_

Re: Configuring Trunking Between ESXi 5 server and CISCO Switch

I've always told my boss that if the "new" guy can't figure out my notes and documentation then he picked the wrong "new" guy. I won't waste my time writing up SOP manuals and step by step instructions on how I do my job.
--
I do not, have not, and will not work for AT&T/Comcast/Verizon/Charter or similar sized company.


TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
Haha yes. The test of a true engineer is if they can reverse engineer what already exists.

I happen to agree. Except in two cases:

•Where a specific procedure should be followed in order to achieve a certain consistent result
•Where the equipment may be so obscure that any regular engineer, no matter how good they are, may simply have not come across it

But otherwise time is too short and there are far more interesting things to be doing other than documentation (say all engineers I am sure.)

Although I will concede one thing, in my current job I handle circuit documentation quite religiously. We deal with an absolute mountain of circuits now that its impossible to expect anyone to remember.

Side note:

When I hired people to replace me at my former work place I used a lab scenario to work out just how clued in they were. I configured a couple of routers and a switch and introduced a couple of errors that meant certain devices could ping each other but others couldnt, and the candidates had to work out why and implement the fixes. One guy took about an hour before I just had to give up and give him the answers (yeah I actually gave him that long...), and another guy worked it out on his own in about 5 minutes.

And when I say a couple I really do mean a couple, 2 to be precise. One was a simple subnet mask mismatch, and the other was a statically configured ARP entry for an IP pointing to a MAC address with only a subtle variation from the original (two swapped characters next to each other.)

I was actually really pleased with the result of this test, it really showed who had experience and how they went about digging information out and checking through things. I would use it again.

accordg

join:2013-01-17
reply to DocLarge
sample config for my office:

Cisco side--
interface Port-channel20
description Storage
switchport trunk encapsulation dot1q
switchport mode trunk
flowcontrol receive on
spanning-tree portfast trunk
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
!

interface GigabitEthernet0/9
description ESX1 - iSCSI
switchport access vlan 100
switchport mode access
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust dscp
storm-control broadcast level pps 100
storm-control multicast level pps 100
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
service-policy input qos
ip dhcp snooping limit rate 100
!
interface GigabitEthernet0/10
description ESX2 - iSCSI
switchport access vlan 100
switchport mode access
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust dscp
storm-control broadcast level pps 100
storm-control multicast level pps 100
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
service-policy input qos
ip dhcp snooping limit rate 100
!
interface GigabitEthernet0/11
description ESX3 - iSCSI
switchport access vlan 100
switchport mode access
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust dscp
storm-control broadcast level pps 100
storm-control multicast level pps 100
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
service-policy input qos
ip dhcp snooping limit rate 100
!
interface GigabitEthernet0/12
description ESX4 - iSCSI
switchport access vlan 100
switchport mode access
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust dscp
storm-control broadcast level pps 100
storm-control multicast level pps 100
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
service-policy input qos
ip dhcp snooping limit rate 100
!

aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to TomS_
said by TomS_:

Haha yes. The test of a true engineer is if they can reverse engineer what already exists.

To top it off, try without any diagrams and without full visibility of the entire network. Even if you can do it, you may be blamed of doing things not by company standard regardless your work quality that may be higher or simpler than the standard itself

aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to TomS_
said by TomS_:

When I hired people to replace me at my former work place

Why would you want to hire people that will replace you in the first place?


TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
Because I was leaving.

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply to DocLarge
said by TomS_:

When I hired people to replace me at my former work place I used a lab scenario to work out just how clued in they were.

Wonder how well I would've fared in that test / situation. I wouldn't say I'm a complete network n00b, but I agree with your statement TomS_.

Regards

DocLarge
Premium
join:2004-09-08
kudos:1
reply to DocLarge
Well, it appears there still lies the issue "to document or not to document, that is the question..." in the civilian sector

Being I'm a retired AF communications troop, it was "mandatory" that documentation be accomplished to ensure continuity was in place. While I was active duty, we had numerous contractors try and pull that crap of not wanting to document processes because they "thought" it would give them job security; we typically dismissed anyone who failed to maintain continuity (we just couldn't afford for someone to bring that type of civilian mindset into a warfighting environment).

Personally, now that I'm contracting, I'm applying the same standard in my local environment as well. Whether an individual is better, best, or worst, "somebody" better have it written down (of course, documentation is also listed as a Cisco best practice, so it goes without saying...)

Anyone, thank guys for chiming in. Nosx helped bring some clarity to me after getting me to stop looking at things from an "overly grandular" perspective; all is it good so I've got my starting point...

Jay

aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to HELLFIRE
said by HELLFIRE:

said by TomS_:

When I hired people to replace me at my former work place I used a lab scenario to work out just how clued in they were.

Wonder how well I would've fared in that test / situation. I wouldn't say I'm a complete network n00b, but I agree with your statement TomS_.

Regards

In some companies, lab test is standard interview process. Just think of it as CCIE mock lab

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply to DocLarge
@DocLarge
...corollary of that is "documentation is from an obscure dialect that roughly translates as 'for some other poor schmuck do to.'"

@aryoba
Haven't done IE, and don't know if I want to... I think I know my stuff pretty well, it's just one of those "now your career
is on the line, prove it!" kind of things.

Regards

DocLarge
Premium
join:2004-09-08
kudos:1
reply to aryoba
@ Hellfire: Guess who that poor schmuck was most of the time until he became management??? (Jay points thumbs at himself) *This Guy!!!* *heh*

Concur, Aryoba... I've talked to my folks about making a "lab test" part of the interview process. I'm finally coming off the bench after having been "side-lined" for the last two years working back office (information assurance). I "know" I'm rusty, because there's only so much you can retain if you're not on IOS for 8hrs a day

Ultimately, a "lab" interview process (virtual or physical) is probably the way to go in the future (in my opinion).

Jay

aryoba
Premium,MVM
join:2002-08-22
kudos:4
said by DocLarge:

Concur, Aryoba... I've talked to my folks about making a "lab test" part of the interview process. I'm finally coming off the bench after having been "side-lined" for the last two years working back office (information assurance). I "know" I'm rusty, because there's only so much you can retain if you're not on IOS for 8hrs a day

Imagine where you are in mixed environment that you may type JUNOS command on IOS prompt

From my experience, an actual mock lab session during interview is not essential since you can always ask specific troubleshooting questions when you need to to find out how well candidates know practical networking stuff. I believe it is essential to know networking protocols such as Ethernet, ARP, OSPF, BGP, and (depending on the places) EIGRP in addition to TCP/IP since protocol knowledge will bring you further especially when you are in mixed environment (Juniper, Cisco, Riverbed, Arista, among other things) compared to simply only know Cisco way.

DocLarge
Premium
join:2004-09-08
kudos:1

I believe it is essential to know networking protocols such as Ethernet, ARP, OSPF, BGP, and (depending on the places) EIGRP in addition to TCP/IP since protocol knowledge will bring you further especially when you are in mixed environment (Juniper, Cisco, Riverbed, Arista, among other things) compared to simply only know Cisco way.

Yep, it's about time for me to bring another router IOS into the mix because I've been sipping the CISCO kool-aid since jump

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:9
Good lord, I don't want to count the number of different vendors around here -- and it's just a 9 employee development shop.


tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1
said by cramer:

Good lord, I don't want to count the number of different vendors around here -- and it's just a 9 employee development shop.

smaller shops tend to be a lot more critical on cost of infrastructure and kit -- since capex is much tighter than in most larger shops. couple this with standardization and requirements for support teams to grow -- larger enterprises generally stand on one or two vendors that are re-evaluated on a yearly basis.

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."


tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1
reply to HELLFIRE
said by HELLFIRE:

@aryoba
Haven't done IE, and don't know if I want to... I think I know my stuff pretty well, it's just one of those "now your career
is on the line, prove it!" kind of things.

if you're in an admin type role -- you can get away with this until you hit the higher levels of work inside the enterprise-type level -- however -- there are always exceptions. i know that there are several denizens of this forum that i will gladly admit to being much smarter than myself with no ccie.
however -- in the consulting services role that i am in -- the ccie is almost a mandatory requirement to be brought in for architecture on a large enterprise. it also means for a *significant* bump in pay. i say these -- as i am scheduled for the lab on the 27th. i don't *need* the ccie -- but more cash is always a good thing.

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."


tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1
reply to DocLarge
said by DocLarge:

Ultimately, a "lab" interview process (virtual or physical) is probably the way to go in the future (in my opinion).

i generally agree -- however -- from my experience -- i've been able to gauge a candidate's understanding strictly from a phone interview.
i have been working r/s (mostly cat6k, n7k, asr1k, asr9k) for the better part of 6 years and have done a lot of different "things" with those platforms. when i read a candidate's experience and what they "say they know"(tm) -- i let them confirm. then -- i ask a few easy questions on $topic, then get progressively harder until i get them to sound uneasy on their answers. i look for "simplified" answers -- not a textbook type definition. i get them to admit they don't know something -- then rub salt in their wounds. i then give them a question they should know (another "easy" one). if they can't answer -- i generally shy away -- as they can't recollect themselves enough to answer a gimme.

once they pass that test -- then we bring them in. i have an r/s lab in the first floor of the office. thats when the fun begins.

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:9
reply to tubbynet
Sorry... we are a nine man office, but we're part of a multinational corp. It's not entirely a factor of cost, but mostly one of who ordered whatever.

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply to tubbynet
Well, let us know how the IE test goes tubbynet. Best of luck to ya man.

Halfway tempted to submit myself to said interview test, just to see a) how I
am overall, esp. in the interview arena, and b) just for a learning experience.

Regards