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.
-
@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.
-
wow - that looks like a nightmare! Subnets all over the place.
-
@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.
-
@dashrender said in Hyper-V Failover Cluster FAILURE(S):
wow - that looks like a nightmare! Subnets all over the place.
Right... "unflattened" it looks like.
-
@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.
The issue is the MSP and whoever brought them in. Looks like someone is running a scam that needs to be reported. I'd consider this a security breach at that point.
-
@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?
-
@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.
-
@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):
@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.
-
@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 -
@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?
-
@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?
