Hyper-V Failover Cluster FAILURE(S)
-
@dashrender said in Hyper-V Failover Cluster FAILURE(S):
MS was still using Class networks in 1997 in their Networking Essentials MSCE courses.
Yes, that's the one I am aware of. It was only four years out of date at that point. And knowing that it existed historically is useful, so it is good that they taught it. But somehow it entered the popular consciousness as something that still existed.
-
-
@scottalanmiller said in Hyper-V Failover Cluster FAILURE(S):
@dashrender said in Hyper-V Failover Cluster FAILURE(S):
MS was still using Class networks in 1997 in their Networking Essentials MSCE courses.
Yes, that's the one I am aware of. It was only four years out of date at that point. And knowing that it existed historically is useful, so it is good that they taught it. But somehow it entered the popular consciousness as something that still existed.
Do you still think that the knowledge of Classes is confusing to people in the use of subnets like /24 /16, etc?
At least the other thread that mentioned it had a reason for wanting /16, since his in use subnets where so far apart, a /16 was (to him) the simplest way to get both subnets into a single one.
-
@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.
-
@kyle okay, that's crazy. Why is your iSCSI going to different networks? Why is there more than one SAN?
-
@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.
-
@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.
-
@kyle said in Hyper-V Failover Cluster FAILURE(S):
@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.
I know, but why is there more than one SAN? A single storage device, like the Tegile, should be on only a single SAN.
-
@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?
