Hyper-V Failover Cluster FAILURE(S)
-
@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 /sighWe also have a 172.30 as well.......
-
This is really a management issue. I'd escalate. Explain that they are trying to apply a technical fix to a management oversight and that you can't actually fix the issue if management isn't actually trying to fix it.
-
@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.
-
@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.
-
@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):
@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 /sighWe also have a 172.30 as well.......
That won't be part of the 'new' flat network...
-
@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.
-
@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):
@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 /sighWe also have a 172.30 as well.......
That won't be part of the 'new' flat network...
It's the only one from what I can tell. In the images provided, that's the only /16 that I noticed.
-
@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?
-
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?
-
@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?
No, that's what I keep saying, they UNflattened it into loads of networks, one is a /16, all the others are /24.
-
@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.
-
@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):
@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?
No, that's what I keep saying, they UNflattened it into loads of networks, one is a /16, all the others are /24.
I stand corrected, I just looked again and saw the /16 only on the 172.30.x.x network, as you said... yeah the 172.20 networks do require a router.
-
@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.
Removing networks is flattening, whether they are physical LANs or VLANs, all the same thing. The term is generally used to mean merging multiple networks into one. But there are so many networks here, what was merged?
-
@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.
-
@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.
But this hasn't been done according to your pictures.. it was only done on the 172.30.x.x network.
-
@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.
-
@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.
-
@kyle said in Hyper-V Failover Cluster FAILURE(S):
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?
No reason to think so. I can't imagine how the weird networking would be related to an IO issue like that.
-
This post is deleted! -
@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.
