Nexus 9K, VDC or not?

[jericho]

Hi,

I've been collared to configure a couple of Nexus switches in a DC that my current employer is moving a bunch of kit to. The designs have already been done by someone further up the food chain and call for them to be split into 2 VDCs each, one for the routing out to the WAN and one for the local switching with a handful of VPCs each.

The design is using a number of ports to connect the  VDC's together (4 per switch for the VPC peer link,  2 for the keepalive, 2 for the L3) and they are running out of ports already. Other than separating the routing from the switching, is there any real benefit to the VDC? Everything is going to be managed by the same group of people, so it's not like there is a security reason for doing it.

If there is a good reason,  fair enough, but this fellow has a record of generating the most complicated configurations possible and using our live environment as his lab & learning area.

Cheers

J

[packetherder]

Would like to hear other people's thoughts. I've never been a fan, the cost of burning front-panel ports for basically the same features as a VRF don't balance out for me.

[NetworkGroover]

My opinion - this is overkill.  I don't see how there is a huge benefit from "separating routing from switching" more so than it already is separated.

EDIT - I should say though, I'm not a Cisco guy, but I am somewhat knowledgeable in the DC.

[wintermute000]

Only justification is management demarcation or L2 IPS or there is dci overlay networks in the WAN VDC. Design and caveats get super hairy if first hop routing and DCI overlay is on the same device. However I haven't looked at whether vdc limits this

[jericho]

Thanks for the replies.

There's nothing clever going on in this design. It's basically 2 9Ks , 2 fex each, with a handful of VPCs and a lot of normal switchports. There are 2 OSPF areas, one for the DC and one for the backbone.

We've got other stuff where we are using VDCs as they are for colocation and the customers have ssh access to their virtual switch, but I can't see why we need it in this instance. I'm not really up to speed on DC designs, so wasn't sure if there was a good reason that I wasn't aware of that justified burning that many ports, sfps and interconnects (which cost us £120 a month rental as well).

Looking through his spec doc, the justification is (I'm paraphrasing slightly) "to allow changes to be made to one of the routing or switching process without impacting on the other", which seems a bit nonsensical.

Cheers

J

[wintermute000]

I really can't stand people who try to be clever for the sake of it. That justification is pointless.

[jericho]

I really can't stand people who try to be clever for the sake of it. That justification is pointless.

I won't tell you about his 3 site design that had a different routing protocol at each site, then redistributing it all then.

Or my personal favourite, every single  non host interface on every single switch being routed and advertising itself into ospf, the routing table was colossal.

He's well known for over complicating things, we then get to the point of him being the only person who can understand what has happened when something goes wrong. He then looks like the hero when he fixes the issue and gets to continue doing it over & over.

I've binned the VDCs from the design, we'll argue about it if he notices.

Cheers

J

[NetworkGroover]

I won't tell you about his 3 site design that had a different routing protocol at each site, then redistributing it all then.

Funny, I started typing this up before I read this entire post, and the thought that immediately popped into my mind just from the line I quoted was, "Man, he must love the job security."

[jericho]

Funny, I started typing this up before I read this entire post, and the thought that immediately popped into my mind just from the line I quoted was, "Man, he must love the job security."

I had my one and only adult temper tantrum over that and refused point blank to implement it. I'm sure IS-IS is a wonderful protocol but none of us in ops have a clue about it.
There was some reason for it that made no sense whatsoever. We stuck with OSPF as we knew it.

I think people are starting to realise that he maybe isn't as good as he claims, I've noticed his boss raising eyebrows at some of his technobabble recently.

Not my problem for much longer as I'm off to a new job.

Cheers

J

[NetworkGroover]

I had my one and only adult temper tantrum over that and refused point blank to implement it. I'm sure IS-IS is a wonderful protocol but none of us in ops have a clue about it.
There was some reason for it that made no sense whatsoever. We stuck with OSPF as we knew it.

I think people are starting to realise that he maybe isn't as good as he claims, I've noticed his boss raising eyebrows at some of his technobabble recently.

Not my problem for much longer as I'm off to a new job.

Cheers

J

Yeah I will say I'm far from an expert, but I can't imagine any scenario that I'd want to CREATE a situation where I have to redistribute between protocols... it's one thing to inherit something and have to deal with it... but...

[deanwebb]

Yeah, no way would I do it on purpose except as part of a lab... and then remember that I'm in security and stop all that nonsense...

[Dieselboy]

Is there any company that doesn't have this kind of situation at somepoint?

My question would always be - "Why are you making it unnecessarily complicated?"

A separate routing protocol per site as a design? 
Sounds like this guy just wants to stretch the boundaries and see what's possible but the reality is, this work is best placed in a lab and not designs for customer networks. Not unless, he's designed this, labbed it up and it's been through rigorous testing and meets all the initial requirements, future requirements and will be the best way forward.
Sounds like it's just making the way for a can of worms, and as a manager I'd be a bit scared.

[jericho]

It's well known that he treats the production network as his learning environment, which had led to some 'interesting' moments over the last few years.

The problem i have is that what he designs and implements works. It's always over complicated and takes longer than it should but it rarely causes any impact that management notice. He's also superb at getting his excuses in first and is extremely good at selling his version of events.

I'm past trying to explain the issues to his boss & I have 8 days left on site.

I dug out the design doc for  the 3 routing protocols. The justification was worse than I remembered. It went along the lines of " if you need one, take two."

Cheers

J

[Dieselboy]

 

Routing protocol resilience? Just in case one of them goes down haha

I suppose it's a possibility (process could hang unless there were recovery mechanisms built in to monitor that) - but would mean you would need 2 routing protocols to be implemented, network-wide

[wintermute000]

It's well known that he treats the production network as his learning environment, which had led to some 'interesting' moments over the last few years.

The problem i have is that what he designs and implements works. It's always over complicated and takes longer than it should but it rarely causes any impact that management notice. He's also superb at getting his excuses in first and is extremely good at selling his version of events.

I'm past trying to explain the issues to his boss & I have 8 days left on site.

I dug out the design doc for  the 3 routing protocols. The justification was worse than I remembered. It went along the lines of " if you need one, take two."

Cheers

J

with GNS3 and VIRL and IOU - heck, perfectly serviceable second hand 1800s and 3750s for less than 100 USD - there is ZERO excuse for using work to lab R&S. none.