Posts made by Kyle

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

A /16 is worlds beyond flattening. Flattening is /22 maybe a /21. But what you are showing isn't in the scope of that flattening, these networks are all over the place and can't be covered by a /16.

I am aware of that. This was all decided long before I came on board. Yet I am tasked with identifying the issues and as you can see there are plenty.

Right, but the SAN hasn't been flattened. The flattened network is somewhere else.

This is what the "MSP" has identified as flattening. All the 172 addressing is new.

so the 172.20.200.x and 172.20.201.x are now flattened.. but why where they separate in the first place?

How are they flattened? They are tiny.

they are flattened because they no longer require a router to talk to any address, the fact that there is a HUGE collision domain doesn't really matter from a flatness POV. But yeah, that was crazy, a /21 would have solved it, without a calculator, I don't know if a /22 would have.

They DO require a router, they are small at just /24 and unflattened. So to talk to each other, they have to route.

I thought he said they flatted the SAN network into a /16?

This is what the "MSP" considered flattening compared to the old /24 with VLANs.

They didn't consider it that, they just lied.

The lying thing is very common for this vendor.

time to fire them and find another support channel.

That's a whole can of worms that I have very little I can do.

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

A /16 is worlds beyond flattening. Flattening is /22 maybe a /21. But what you are showing isn't in the scope of that flattening, these networks are all over the place and can't be covered by a /16.

I am aware of that. This was all decided long before I came on board. Yet I am tasked with identifying the issues and as you can see there are plenty.

Right, but the SAN hasn't been flattened. The flattened network is somewhere else.

This is what the "MSP" has identified as flattening. All the 172 addressing is new.

so the 172.20.200.x and 172.20.201.x are now flattened.. but why where they separate in the first place?

How are they flattened? They are tiny.

they are flattened because they no longer require a router to talk to any address, the fact that there is a HUGE collision domain doesn't really matter from a flatness POV. But yeah, that was crazy, a /21 would have solved it, without a calculator, I don't know if a /22 would have.

They DO require a router, they are small at just /24 and unflattened. So to talk to each other, they have to route.

I thought he said they flatted the SAN network into a /16?

This is what the "MSP" considered flattening compared to the old /24 with VLANs.

They didn't consider it that, they just lied.

The lying thing is very common for this vendor.

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

A /16 is worlds beyond flattening. Flattening is /22 maybe a /21. But what you are showing isn't in the scope of that flattening, these networks are all over the place and can't be covered by a /16.

I am aware of that. This was all decided long before I came on board. Yet I am tasked with identifying the issues and as you can see there are plenty.

Right, but the SAN hasn't been flattened. The flattened network is somewhere else.

This is what the "MSP" has identified as flattening. All the 172 addressing is new.

so the 172.20.200.x and 172.20.201.x are now flattened.. but why where they separate in the first place?

How are they flattened? They are tiny.

they are flattened because they no longer require a router to talk to any address, the fact that there is a HUGE collision domain doesn't really matter from a flatness POV. But yeah, that was crazy, a /21 would have solved it, without a calculator, I don't know if a /22 would have.

They DO require a router, they are small at just /24 and unflattened. So to talk to each other, they have to route.

I thought he said they flatted the SAN network into a /16?

This is what the "MSP" considered flattening compared to the old /24 with VLANs.

Now that we've determined that there is a huge networking issues. Do you guys thing the Event ID 5120 issue is a connection issue to the SAN loosing connectivity and the cluster going into an auto pause scenario?

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

wow - that looks like a nightmare! Subnets all over the place.

You have no idea. There are roughly 12 subnets just in our location. We have 14 locations total on a MPLS and those sites still run on /16 192 addresses but are slotted to be converted.

You have 14 /16 networks?

As the ASA's for the other locations are still sitting in out office I am not sure how they are configured yet or what their scope is going to be.

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

A /16 is worlds beyond flattening. Flattening is /22 maybe a /21. But what you are showing isn't in the scope of that flattening, these networks are all over the place and can't be covered by a /16.

I am aware of that. This was all decided long before I came on board. Yet I am tasked with identifying the issues and as you can see there are plenty.

Right, but the SAN hasn't been flattened. The flattened network is somewhere else.

This is what the "MSP" has identified as flattening. All the 172 addressing is new.

so the 172.20.200.x and 172.20.201.x are now flattened.. but why where they separate in the first place?

They believe that is best practice for failover.

To quote @JaredBusch
FFS /sigh

We also have a 172.30 as well.......

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

A /16 is worlds beyond flattening. Flattening is /22 maybe a /21. But what you are showing isn't in the scope of that flattening, these networks are all over the place and can't be covered by a /16.

I am aware of that. This was all decided long before I came on board. Yet I am tasked with identifying the issues and as you can see there are plenty.

Right, but the SAN hasn't been flattened. The flattened network is somewhere else.

This is what the "MSP" has identified as flattening. All the 172 addressing is new.

so the 172.20.200.x and 172.20.201.x are now flattened.. but why where they separate in the first place?

They believe that is best practice for failover.

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

wow - that looks like a nightmare! Subnets all over the place.

You have no idea. There are roughly 12 subnets just in our location. We have 14 locations total on a MPLS and those sites still run on /16 192 addresses but are slotted to be converted.

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

A /16 is worlds beyond flattening. Flattening is /22 maybe a /21. But what you are showing isn't in the scope of that flattening, these networks are all over the place and can't be covered by a /16.

I am aware of that. This was all decided long before I came on board. Yet I am tasked with identifying the issues and as you can see there are plenty.

Right, but the SAN hasn't been flattened. The flattened network is somewhere else.

This is what the "MSP" has identified as flattening. All the 172 addressing is new.

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

A /16 is worlds beyond flattening. Flattening is /22 maybe a /21. But what you are showing isn't in the scope of that flattening, these networks are all over the place and can't be covered by a /16.

I am aware of that. This was all decided long before I came on board. Yet I am tasked with identifying the issues and as you can see there are plenty.

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle okay, that's crazy. Why is your iSCSI going to different networks? Why is there more than one SAN?

There is more than 1 SAN but those point to the same SAN, that Tegile HA2300.

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

Also, why has using /16 networking come up twice this weekend? I've gone years without hearing of someone trying something like this and suddenly, twice in a weekend?

Why is the SAN bigger than a /26? Why so many addresses for something that should have so few?

The move from a /24 to /16 was due to a "MSP" claiming flattening out the network would solve vlan issues that were occurring.

@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):

@kyle said in Hyper-V Failover Cluster FAILURE(S):

I have found some MSDN articles that point to subnetting being the issue here and the 4 reference links at the bottom of the page:

All of those are about issues with multi-subnetting. But you are not doing that here, right? So those would not be applicable.

All IP's on those NIC's are muti-sunetted.

@dashrender said in Hyper-V Failover Cluster FAILURE(S):

Is your SAN on your production network? i.e. not a separate switch away from the normal network?

Yes. The SAN is connected via ISCSI to a switch that coverts it to 10G CAT 6 and connected to the Hyper-V Cluster. The nodes have have separate NICs for different tasks, 2 for Failover to the SAN, 1 for Migration, and 2 for failover to the network.

Twice thin as many days we have had a complete failure where all nodes and VM's go critical and then hard down.

Setup is:

6 Nodes configured with Hyper-V Failover Cluster (Can't get a straight answer as to who set it up(
All nodes are connected to a Tegile HA 2300 with a single 7TB Lun for 42 VM's with 2 10G ISCSI subnetted NICs.

Twice in as many days the cluster has thrown a server Event ID 5120 (STATUS_DEVICE_BUSY) and lists the SAN Volume.

The day we swapped from a Class C to a Class B networking this occurred 2 hours later and again 36 hours later.

I have found some MSDN articles that point to subnetting being the issue here and the 4 reference links at the bottom of the page:

https://blogs.msdn.microsoft.com/clustering/2014/12/08/troubleshooting-cluster-shared-volume-auto-pauses-event-5120/

My question is what do you guys think?

@travisdh1 said in Helpdesk SLAs:

@kyle said in Helpdesk SLAs:

@scottalanmiller said in Helpdesk SLAs:

@ambarishrh said in Helpdesk SLAs:

@scottalanmiller said in Helpdesk SLAs:

@ambarishrh said in Helpdesk SLAs:

we are a very small team now, 250+ users 3 techs. Screen connect plays a bigger role here!

Idea is to set an SLA and review this on regular basis, find out the gap and either increase headcount or if no budget for additional headcount, then increase the SLA.

With the current tech headcount, the SLA that we are thinking are:

*Resolution includes temporary fix or work-around solution.

New hardware requests usually take 4-6 weeks to deliver from HP (we can keep stock of 5 but the user requests are quite a lot this year and next year as well, but no finance approval to keep more than 5 as of now), so agreed with HR on this timeline.

An SLA means that there is a punishment to you if you do not meet the requirements. What happens to the IT team if they cannot resolve these issues in the SLA time? How do you determine what is within the scope of what IT can have fixed and not?

The purpose for this is also to evaluate the existing issues, see if our small team can cater the requirements and based on the results we either get more people or increase the sla. As of now this will be visible only to IT team and based on our analysis we will release to users on a later stage with SLA that we can achieve

SLAs are not a good tool for that. Just use good reporting for that. SLAs are adversarial, not something you ever want to use internally.

Yet they are integrated in several helpdesk options.

Yes, because help desk software is a generic thing that can be used with the public, internally, or a combination of both. Just because a feature is already integrated doesn't mean it's a good option to use. I think of something like an SLA for leased lines like T1/T3.

I know. I just wish they were more granular in features as there are some hard coded features the are unnecessary and just clutter the classification of tickets. We currently use ManageEngine Service Desk and SLA's are built in and part of the reporting metrics despite the fact we don't use them.

@scottalanmiller said in Helpdesk SLAs:

@ambarishrh said in Helpdesk SLAs:

@scottalanmiller said in Helpdesk SLAs:

@ambarishrh said in Helpdesk SLAs:

we are a very small team now, 250+ users 3 techs. Screen connect plays a bigger role here!

Idea is to set an SLA and review this on regular basis, find out the gap and either increase headcount or if no budget for additional headcount, then increase the SLA.

With the current tech headcount, the SLA that we are thinking are:

*Resolution includes temporary fix or work-around solution.

New hardware requests usually take 4-6 weeks to deliver from HP (we can keep stock of 5 but the user requests are quite a lot this year and next year as well, but no finance approval to keep more than 5 as of now), so agreed with HR on this timeline.

An SLA means that there is a punishment to you if you do not meet the requirements. What happens to the IT team if they cannot resolve these issues in the SLA time? How do you determine what is within the scope of what IT can have fixed and not?

The purpose for this is also to evaluate the existing issues, see if our small team can cater the requirements and based on the results we either get more people or increase the sla. As of now this will be visible only to IT team and based on our analysis we will release to users on a later stage with SLA that we can achieve

SLAs are not a good tool for that. Just use good reporting for that. SLAs are adversarial, not something you ever want to use internally.

Yet they are integrated in several helpdesk options.

@scottalanmiller said in Any reason to avoid /16 in 2017?:

@kyle said in Any reason to avoid /16 in 2017?:

The employer I just went to work for was convinced to go from a /24 to a /16 because they were told this was necessary to fix the issues with the VLAN's. The turn up of this was on my 3rd day on the job so I had no idea when I signed on as to why they were making the change. The company has 14 locations on an MPLS but the IP addressing schema is all over the board.

LMAO.

I'm telling you. The "MSP" is like dealing with psychopathic monkey with alzheimer's.

The employer I just went to work for was convinced to go from a /24 to a /16 because they were told this was necessary to fix the issues with the VLAN's. The turn up of this was on my 3rd day on the job so I had no idea when I signed on as to why they were making the change. The company has 14 locations on an MPLS but the IP addressing schema is all over the board.