Campus Challenges

[NetworkGroover]

What would you folks say are the biggest challenges, pain points, etc. for the Campus?

[deanwebb]

I'm going to guess "stretching VLANs" is going to be high on the list...

[icecream-guy]

the campus   

multiple buildings, multiple data centers, labs,  wireless connectivity, POPS,  consolidation,   network architecture,
different groups of users in same building that need to reach same group in other buildings, so yeah stretch vlans

[NetworkGroover]

Really?  That's numero uno?

Where does stuff like NAC, segmentation, etc. etc. fall into the list?  If you had to pick 3, what would they be?

[Otanx]

So I wrote the below, but thinking about it while I wrote I don't have a normal campus. So take what I say with a grain of salt. I have 0 wireless so I would guess that some wireless would make the list.

I don't have a big campus. 3 buildings with a total of 7 floors, 9 total closets. NAC is basically solved. 802.1x with a MAB fall back. I don't really need micro segmentation in the campus I can do that with 802.1x and downloadable ACLs. 90% of the time clients shouldn't be talking to other clients so a simple ACL entry will work. So the three biggest issues I see?

1. Cost. When I need a lot of switches then I don't want to pay premium for them. Also don't make me pay for licenses for stupid stuff. OSPF for Access anyone? Instead of just supplying code that is solid and old and just works lets rewrite it to put in artificial limitations so we can charge people money. Nope not bitter about this at all.
2. Port density. 52 ports is about all you can do in 1U without using breakouts. Chassis can maybe get better if you need really high port counts. Supporting 2.5/5G would be great to for the wifi access points, and power users. This links back to cost. I drop 2.5/5G first followed by port density to get cost in line.
3. PoE. More and more devices want more and more power. I think we are up to 90W per port? I am lucky, and have no PoE requirements, but I can see how that is getting to be a problem.

Stretching VLANs is a major issue as well, but not one that is going to be solved by switches, or network engineers. The only reason to extend vlans is to support old poorly written network stacks. Until those are gone we will need to keep stretching those VLANs, or using an overlay like VXLAN. In the data center VXLAN is good especially when talking redundant data centers. In a campus I don't think it is worth the added complexity.

-Otanx

[deanwebb]

OK, you mentioned NAC... that's my $VENDOR area...

Number one is flat out not knowing what in the Sam Hill is connected to your network. You know there's stuff plugged in, and you *hope* it's all yours, but you don't know, so that's why you got the Forescout folks in, running NMAP and logging into all the Windows boxes - you need to know what's there.

Number two is getting all that info into your CMDB. We'll block stuff later, inventory comes first.

Blocking is actually pretty easy to do. Compliance is not so hard, either.

[NetworkGroover]

So I wrote the below, but thinking about it while I wrote I don't have a normal campus. So take what I say with a grain of salt. I have 0 wireless so I would guess that some wireless would make the list.

I don't have a big campus. 3 buildings with a total of 7 floors, 9 total closets. NAC is basically solved. 802.1x with a MAB fall back. I don't really need micro segmentation in the campus I can do that with 802.1x and downloadable ACLs. 90% of the time clients shouldn't be talking to other clients so a simple ACL entry will work. So the three biggest issues I see?

1. Cost. When I need a lot of switches then I don't want to pay premium for them. Also don't make me pay for licenses for stupid stuff. OSPF for Access anyone? Instead of just supplying code that is solid and old and just works lets rewrite it to put in artificial limitations so we can charge people money. Nope not bitter about this at all.
2. Port density. 52 ports is about all you can do in 1U without using breakouts. Chassis can maybe get better if you need really high port counts. Supporting 2.5/5G would be great to for the wifi access points, and power users. This links back to cost. I drop 2.5/5G first followed by port density to get cost in line.
3. PoE. More and more devices want more and more power. I think we are up to 90W per port? I am lucky, and have no PoE requirements, but I can see how that is getting to be a problem.

Stretching VLANs is a major issue as well, but not one that is going to be solved by switches, or network engineers. The only reason to extend vlans is to support old poorly written network stacks. Until those are gone we will need to keep stretching those VLANs, or using an overlay like VXLAN. In the data center VXLAN is good especially when talking redundant data centers. In a campus I don't think it is worth the added complexity.

-Otanx

Ah what the hell.. I had a response written up and guess forgot to click the post button.

Anywho, yep cost seems to be at the top of the list for campus even above security surprisingly or not according to a few articles/podcasts I've seen floating around.

Curious about your PoE statement - I know folks are pushing for 90W for displays, etc. - moving to a model where I guess anything with an IP shouldn't require a separate power connection.  It's interesting.  Like, do switches become more power supplies than switches at some point? Haha.  Do you personally see a big need for 90W?

Regarding VXLAN, yeah there are several use cases in a controller-less architecture to provide tunneling capabilities for APs.

[Otanx]

Ah what the hell.. I had a response written up and guess forgot to click the post button.

Anywho, yep cost seems to be at the top of the list for campus even above security surprisingly or not according to a few articles/podcasts I've seen floating around.

Curious about your PoE statement - I know folks are pushing for 90W for displays, etc. - moving to a model where I guess anything with an IP shouldn't require a separate power connection.  It's interesting.  Like, do switches become more power supplies than switches at some point? Haha.  Do you personally see a big need for 90W?

Regarding VXLAN, yeah there are several use cases in a controller-less architecture to provide tunneling capabilities for APs.

I think that basic 802.1x auth is cheap and good enough for most people. Any extra security really needs to show a big benefit to get considered. Otherwise the security budget is going to agents on the endpoints, or some new buzz word like APT, or AI, or 0day or my new security tool that will use AI to detect 0day APT threats.

I don't do any PoE in our environment. I even got rid of VoIP so no phones. VaaS for me. I do think that just like a baseball field in Nebraska if you build it they will come. Supply 90W of POE and devices will use it. Give em 120W more uses. Start daisy chaining them. My display plugs in, and powers from PoE. Then I plug my laptop into the monitor with a USB-C. It gets power, display and network all over the one cable. Include a small USB hub in the monitor I could have a keyboard and mouse. All powered from a single cable. Even at 90W I don't know how possible that is, but it will come. Phillips makes PoE lighting for your office today as part of their smart lighting stuff. So switches as power supplies are a thing today. Who planned a network drop for all the lights in the ceiling? I didn't, but maybe I should have.

-Otanx

[NetworkGroover]

Ah what the hell.. I had a response written up and guess forgot to click the post button.

Anywho, yep cost seems to be at the top of the list for campus even above security surprisingly or not according to a few articles/podcasts I've seen floating around.

Curious about your PoE statement - I know folks are pushing for 90W for displays, etc. - moving to a model where I guess anything with an IP shouldn't require a separate power connection.  It's interesting.  Like, do switches become more power supplies than switches at some point? Haha.  Do you personally see a big need for 90W?

Regarding VXLAN, yeah there are several use cases in a controller-less architecture to provide tunneling capabilities for APs.

I think that basic 802.1x auth is cheap and good enough for most people. Any extra security really needs to show a big benefit to get considered. Otherwise the security budget is going to agents on the endpoints, or some new buzz word like APT, or AI, or 0day or my new security tool that will use AI to detect 0day APT threats.

I don't do any PoE in our environment. I even got rid of VoIP so no phones. VaaS for me. I do think that just like a baseball field in Nebraska if you build it they will come. Supply 90W of POE and devices will use it. Give em 120W more uses. Start daisy chaining them. My display plugs in, and powers from PoE. Then I plug my laptop into the monitor with a USB-C. It gets power, display and network all over the one cable. Include a small USB hub in the monitor I could have a keyboard and mouse. All powered from a single cable. Even at 90W I don't know how possible that is, but it will come. Phillips makes PoE lighting for your office today as part of their smart lighting stuff. So switches as power supplies are a thing today. Who planned a network drop for all the lights in the ceiling? I didn't, but maybe I should have.

-Otanx

Haha yep!  It's either going to become the way of the future, or folks will maybe think it's a better idea to keep at least some things separate so that when a switch fails you don't lose power to part of the building.

And yes, I've never really had to deal with NAC, so I'm just learning about this stuff and I was surprised talking to a large enterprise that yeah - they just do 802.1x and MAB - that's it.  They are about keeping it simple though in all things related to their network as long as it meets business requirements, except their automation, and it's worked out very well for them.

[deanwebb]

Switches as power supplies - sounds like people deciding reinvented wheels are the way to go. I'm with Otanx in doing VaaS, no need for hard phones anymore. In fact, I now do more voice work with my PC than with my smartphone.

For NAC - dot1x and MAB will fulfill the access control part of the puzzle, but then the question of posturing arises. I've got customers that do ISE for NAC and then Forescout to do posturing to feed back to ISE info on whether or not to keep an device online.

[wintermute000]

Regarding VXLAN, yeah there are several use cases in a controller-less architecture to provide tunneling capabilities for APs.

Aruba Instant does its own tunnelling and is the gold controller-less standard IMO, never heard of Meraki needing one.
I wouldn't bother with a controller-less product that demands I also provide an overlay.

The problem with security beyond 802.1x/MAB is that its hard to do physically at scale at a reasonable price on switching silicon. Look at the 1000 pound gorilla's attempt which gave us glorified ACLs lol. This is a classic case where complex edge (endpoints) simple core (network) fits IMO - you need CPU cycles and cheap RAM to do layer-7 processing, TLS decryption, signatures yada yada and any attempt to shoehorn that into switching is just not going to end well. The best attempt to fix this I've seen is the Aruba Mobile First stack which is quite elegant IMO in treating wired users exactly like wireless and tunnelling everyone back to the controlller where they can throw CPU and RAM and software at the NGFW problem. Forescout again is putting the smarts somewhere other than the switch and just using the switch as dumb enforcement.

re: POE I think it will keep trucking on, ultimately its the convenience, but I don't know at what point it stops making sense. NObody wants to go back to Cat4000s exploding PSU days, but that's where we're heading with 60W and 90W. At least it makes huge chassis switches make less and less sense - do you want thousands and thousands of watts ready to explode, or a series of pizzaboxes each doing 1k or 2k (I know which is more Arista-y lol).

[NetworkGroover]

Regarding VXLAN, yeah there are several use cases in a controller-less architecture to provide tunneling capabilities for APs.

Aruba Instant does its own tunnelling and is the gold controller-less standard IMO, never heard of Meraki needing one.
I wouldn't bother with a controller-less product that demands I also provide an overlay.

The problem with security beyond 802.1x/MAB is that its hard to do physically at scale at a reasonable price on switching silicon. Look at the 1000 pound gorilla's attempt which gave us glorified ACLs lol. This is a classic case where complex edge (endpoints) simple core (network) fits IMO - you need CPU cycles and cheap RAM to do layer-7 processing, TLS decryption, signatures yada yada and any attempt to shoehorn that into switching is just not going to end well. The best attempt to fix this I've seen is the Aruba Mobile First stack which is quite elegant IMO in treating wired users exactly like wireless and tunnelling everyone back to the controlller where they can throw CPU and RAM and software at the NGFW problem. Forescout again is putting the smarts somewhere other than the switch and just using the switch as dumb enforcement.

re: POE I think it will keep trucking on, ultimately its the convenience, but I don't know at what point it stops making sense. NObody wants to go back to Cat4000s exploding PSU days, but that's where we're heading with 60W and 90W. At least it makes huge chassis switches make less and less sense - do you want thousands and thousands of watts ready to explode, or a series of pizzaboxes each doing 1k or 2k (I know which is more Arista-y lol).

When you say "does it's own tunneling", it's still an overlay right?  I think the difference is not being forced to do it, and not being locked to a single place to decap those tunnels, among other things.  If you just need to do a local VLAN drop-off, you can do that (at least with Arista and Aruba if it's controllerless) - it doesn't have to go back to the controller first.  If you're referring to the method of tunneling driving changes in the underlying network, there are options besides VXLAN if that's something you don't want to do/have devices that doesn't support it.  Regarding Meraki, if anyone has it deployed I'd love to know because I think I have old info - as far as I know it's still using a controller, just that controller now lives in the cloud, so I'm curious to know what happens if you lose Internet connectivity what the effect are on Meraki APs if any.  Do you just lose mgmt?  Or do you lose the control plane as well?

Yeah - what you're saying about 802.1x reflects what I've heard from the field thus far.  That's probably why you'll continue to see vendors either create their own external product solutions in this space, or partner and integrate with others who already do those parts well (Like Forescout! ).

PoE - that's a really interesting viewpoint I hadn't thought of or heard before.  Will be interesting to see what vendors can provide in terms of PoE going down the road without explosions lol... (scary that has to be even mentioned) if high density 60W, and especially 90W, becomes a mainstream thing. And ehhhhh - PoE chassis I'm sure is going to be an option from every vendor in this space.  People just love having that one device to manage, and not everyone in the campus has the DC mindset of managing their environment as a single holistic entity.

[deanwebb]

Haven't yet seen a customer environment where Meraki lost connectivity to the controller without also having general Internet loss. Solving the ISP/router issue then solves the Meraki issue.

The NAC/endpoint control/visibility area is a complicated space, to be sure. There are three types of vendors I deal with:

1. No product or function in that space, easy to partner with, always happy to help out.
2. Product of function in one or more parts of that space in a limited way, they can be kinda shifty when it comes to their baby in that space. Otherwise, always happy to help out.
3. Direct competition in one or more parts of that space. They only play ball when a customer forces them to sit down at the table with us and to play nice. They play nice, but they always give me looks like they're Klingons and I'm Captain Kirk with a tribble in my back pocket...

[NetworkGroover]

Haven't yet seen a customer environment where Meraki lost connectivity to the controller without also having general Internet loss. Solving the ISP/router issue then solves the Meraki issue.

The NAC/endpoint control/visibility area is a complicated space, to be sure. There are three types of vendors I deal with:

1. No product or function in that space, easy to partner with, always happy to help out.
2. Product of function in one or more parts of that space in a limited way, they can be kinda shifty when it comes to their baby in that space. Otherwise, always happy to help out.
3. Direct competition in one or more parts of that space. They only play ball when a customer forces them to sit down at the table with us and to play nice. They play nice, but they always give me looks like they're Klingons and I'm Captain Kirk with a tribble in my back pocket...

Hahaha spot-on.  And sometimes it gets really ugly like when Nuage was happy to partner with a certain networking vendor, and then proceeded to tell their customers to not buy switches from said partner and instead buy their Nokia switches because only those switches supported their controller. 

What you described above applies just about everywhere.

[deanwebb]

Don't it, though? And while I've seen advocates for wall-to-wall Cisco, that message gets muddled when talking about Cisco acquisitions that compete directly with other Cisco lines. Aironet and Meraki are the number one example of "wall-to-wall Cisco" still resulting in a bake-off and a knife fight.