|
They need to make a networking cert path that's not Cisco specific and spends much more time around network design patterns, architecture, and right at the high end - programming ability. The difference between a professional and an expert is no longer how fast you can type BGP statements, it's about how you can design extremely large (larger than ever before) networks and applications, then how you can implement them in an efficient manner.
|
#
?
Feb 7, 2019 02:16
|
|
|
|
| # ? Apr 25, 2024 16:22 |
|
|
Docjowles posted:It would also give us comedy when the cert holders’ companies decide to move back on-prem, and they build the whole data center as a flat /8 in the default VLAN with no STP configured
|
|
#
?
Feb 7, 2019 06:05
|
|
|
doomisland posted:All the fancy SDN poo poo too uses the same networking concepts as well. There are several blogs and posts I've reading where people are amazed by things such as IPTables and dynamic routing. NVGRE is the work of satan.
|
|
#
?
Feb 7, 2019 08:02
|
|
|
Maybe I'm not old enough, I got into networking professionally around 2008, but I've never in my career needed to care about LSA-types for OSPF, beyond knowing "they exist." What's the value in them? I'm starting to interview again for a new Architecture/Senior Engineering job and the phone-screens all seem to go hard into the weeds about particulars of OSPF, LSA-types etc, etc. Which sure I can look those up in about 5 seconds of googling, but why ask that? Someone with 5, 3, 1, or zero years of networking experience can look up literally the same information in about the same amount of time. I did have a decent question when we were talking about BGP, in addition to the normal Local Preference/AS Prepending questions, he asked how to setup an eBGP session through a firewall, to another BGP speaker which involves as much detail as the question asker wants to know. From what security policies would be required on the firewall, (allowing port 179 and all those fun stateful details), to how the BGP speakers would know how to reach each other, and discussing eBGP multihop.
|
|
#
?
Feb 13, 2019 22:53
|
|
|
All the cloud stuff uses BGP so unless you had some weird limitations on the devices you were using or had to maintain something you inherited I'm not sure where OSPF would pop up. Especially since you need a different version of it to do IPv6, you'd assume people would just move to BGP at that point but maybe there are use cases I'm not considering - like whether some SDWAN vendors do everything using the protocol and you'd need to be able to troubleshoot it.
|
|
#
?
Feb 13, 2019 23:04
|
|
|
I think I've needed to know an OSPF LSA type once, in the 11 years I've been working, and I googled it. OSPF used to require a lot more expertise when NBMA networks were commonplace and RIB space was at more of a premium.
|
|
#
?
Feb 13, 2019 23:18
|
|
|
abigserve posted:I think I've needed to know an OSPF LSA type once, in the 11 years I've been working, and I googled it. Yea that's kind of the feeling I get. If you are doing a phone screen for a Network Engineer (senior or not), he should know that OSPF has area's, it uses LSA's to build the Shortest Path Tree, and that it is a common IGP, but by no means the only IGP. If you want to really tech an engineer out, BGP is where you should be focusing. But there is only so much you can do over the phone in the first place. Ask about VLSM (this weeds out help-desk people) Ask about what STP does, where it's used. (this weeds out system admins) Ask about routing protocols, what they do, examples of them, maybe a few factoids, i.e. LSA's exist, link-state vs distance vector maybe? (make sure this guy has at least a CCNA) Ask about specific routing hardware, Arista/Cisco/Juniper models they've worked with and a few features of each (if you are looking for someone who claims they have experience) Finally if you want a senior guy, have a discussion about BGP deployment and make sure they understand iBGP vs eBGP, Local-preference vs AS-Path, and maybe for funsies, ask about communites/MED. Anything else should be done in person, imo.
|
|
#
?
Feb 13, 2019 23:31
|
|
|
It's a pretty common question among any operator with a large-ish scale (100s to 1000s) device datacenter deployments. When I ask the question I'm looking for fundamental understanding of how the topology graph gets built, and what your scaling limitations are. (Hint: At what point does a LSU fragment?)
tortilla_chip fucked around with this message at 23:35 on Feb 13, 2019 |
|
#
?
Feb 13, 2019 23:31
|
|
|
tortilla_chip posted:It's a pretty common question among any operator with a large-ish scale (100s to 1000s) device datacenter deployments. When I ask the question I'm looking for fundamental understanding of how the topology graph gets built, and what your scaling limitations are. (Hint: At what point does a LSA fragment?) I mean, an LSA is just a packet, so wouldn't it fragment at the same point a normal packet fragments, when the payload + overhead exceeds the MTU? Or I guess specifically when the packet length field exceeds that configured MTU? Now as far as what to do about that, I assume you need to intelligently define your IP MTU and interface MTU.
|
|
#
?
Feb 13, 2019 23:42
|
|
|
I’ll guess answer that one just for the feedback , I’d say , “ I don’t know exactly , but it would be either when the message size exceeds the maximum payload permitted ( with respect to MTU or windowed/prescribed transport like TCP) , or when the message is transmitted over a link that has a smaller MTU “?
|
|
#
?
Feb 14, 2019 01:15
|
|
|
tortilla_chip posted:(Hint: At what point does a LSU fragment?) I'm guessing this is what you were asking about scaling? How many routes does it take to fill up the ~1480 bytes? Because I've never had to worry about it. Especially when a company hires a contracted Cisco architect to design their network and then the FTEs run it for 5+ years without making any major architecture changes.
|
|
#
?
Feb 14, 2019 01:56
|
|
|
Just change your whole infrastructure to static routing like that one guy on reddit In my experience a lot of people fumble to tell you what parts of the IP Header change when crossing a layer 3 boundary which is basic knowledge. If someone could answer some hardball OSPF questions you may as well crown them king of the router. Sepist fucked around with this message at 02:30 on Feb 14, 2019 |
|
#
?
Feb 14, 2019 02:25
|
|
|
wtf
|
|
#
?
Feb 14, 2019 03:07
|
|
|
Sepist posted:king of the router. What if I want to be King of the Hub
|
|
#
?
Feb 14, 2019 04:34
|
|
|
Master of his collision domain
|
|
#
?
Feb 14, 2019 04:51
|
|
|
PancakeTransmission posted:How many routes does it take to fill up the ~1480 bytes? The number of interfaces is going to be the limiting factor. A type 1 LSA has a 160 byte header, and each point to point link consumes 128 bytes. 10 interfaces will fit (1440 bytes including header). Increasing the MTU to 9000 you can now fit 68 links, which would suffice for most small 3 stage Clos fabrics, but would be fairly constraining in a 5 stage. tortilla_chip fucked around with this message at 05:08 on Feb 14, 2019 |
|
#
?
Feb 14, 2019 05:00
|
|
|
lol yea, I just use it for shorthand on the internet meaning "do you know how to subnet." tortilla_chip posted:The number of interfaces is going to be the limiting factor. A type 1 LSA has a 160 byte header, and each point to point link consumes 128 bytes. 10 interfaces will fit (1440 bytes including header). Increasing the MTU to 9000 you can now fit 68 links, which would suffice for most small 3 stage Clos fabrics, but would be fairly constraining in a 5 stage. Ah cool. Something that makes sense when it's explained, but I've never encountered it as a problem in my career.
|
|
#
?
Feb 14, 2019 06:33
|
|
|
hey i have a short cisco question: i'm transitioning to a role supporting a client's CUCM environment - moving from an environment that was supporting mostly CME with a little CUCM sprinkled in. I'm moving from a Tier 1 to a Tier 1.5 role - so a little more responsibility and things to troubleshoot. Definitely a lot I need to learn but I was wondering how some of you who support CUCM day in and day out feel about working with it. There seems to be a lot of recruiters looking for CUCM experience so I figured it's good to get some under my belt. Any red flags I should be aware of?
|
|
#
?
Feb 14, 2019 14:17
|
|
|
Do not make any changes or press any buttons without knowing the impact of what you are doing. So many things will reset phones or worse, and often there will be no indication you will be causing an outage. That’s my number one simple tip.
|
|
#
?
Feb 14, 2019 14:22
|
|
|
It works just fine but for scale it benefits greatly from planning ahead and using templates and provisioning tools. Customizing bespoke poo poo for each person and situation will make it agonizing.
|
|
#
?
Feb 14, 2019 19:53
|
|
|
Sepist posted:Just change your whole infrastructure to static routing like that one guy on reddit quote:When in doubt, static route. Actual thing said by a major airline network architect, at an SDN conference.
|
|
#
?
Feb 14, 2019 22:18
|
|
|
The enterprise wireless thread died years ago ( ) so this is going here.Are there any genuine wireless mesh providers left? My scenario is that we have four offices located on the same street, laid out as follows: 1 can see 2 2 can see 1 and 3 3 can see 2 and 4 4 can see 3 If we went back in time to the original MIT-derived version of Meraki, I could put an outdoor AP on each office and they would mesh together and determine the best path for traffic through the network. It seems now that most systems that advertise themselves as 'mesh' are just saying that you can add additional APs to a system without a wired backhaul, they determine a single path back through the network, and it's for providing public Wi-Fi. What I am trying to do is make it possible for a building to have a fibre outage and fail over to the connections in the other three buildings. Or probably in this scenario, provide access to one of the locations before the fibre work is completed. The Ubiquiti/Mimosa kit is all PtP or PtMP so I think the closest I could get with that would be to have six radios and see the problem as three individual PtP links, which is doable especially considering the fairly simple nature of this. It looks like an area Aruba were in at the start of the decade but aren't doing any more.
|
|
#
?
Feb 16, 2019 13:41
|
|
|
Set up PTP links between the buildings that have have line of sight to each other, plug the APs into a router at each site and handle failover at layer 3 with OSPF or some other IGP rather than "mesh" at layer 2. Make the wireless part as simple as possible and basically set it up as you would with physical cabling.
|
|
#
?
Feb 16, 2019 14:29
|
|
|
That’s what I’m leaning towards doing, as the more I read about actual wireless mesh networks the more it seems to have been abandoned as an idea, and instead used as a marketing term for wireless backhaul or things like Google WiFi
|
|
#
?
Feb 16, 2019 17:46
|
|
|
I'd agree with that assessment. At this point mesh WiFi seems to be focused on three groups: 1. Home users who want to extend coverage but can't/don't want to wire additional APs, and to a much lesser extent public WiFi services in large open areas where wiring is cost prohibitive. 2. Amateur radio tinkerers 3. Insane true believers who think a 2.4GHz based meshnet can replace traditional ISPs in any meaningful way. I've had good luck with Ubiquiti PtP gear in the past. Depending on your distances and performance requirements a few cheap Litebeam-ACs could do the job quite nicely.
|
|
#
?
Feb 16, 2019 18:47
|
|
|
In addition to home use like Plume or Google APs, I've seen it used in *very* specific industrial settings like a large ship port with a bunch of moving, big equipment where wiring them up is not very feasible. It's a combination of pole mounted APs and APs in crane loaders and those huge rear end lifts used to move shipping containers.
|
|
#
?
Feb 16, 2019 21:39
|
|
|
Yeah from what I've read to create that sort of mesh where there's no concept of APs and clients requires everything to run on the same channel, which is probably fine for the sort of data rates that SCADA-type systems use, but if your ambition is to stick things up on every house to spread the internet across a city then you're going to hit physical limitations really quickly.
|
|
#
?
Feb 16, 2019 21:48
|
|
|
Are optical transceiver modules plug n play?
|
|
#
?
Feb 17, 2019 00:26
|
|
|
Woof Blitzer posted:Are optical transceiver modules plug n play? Yes, so long as you bought the right one for your fibre and that they're Cisco branded. You can use non-Cisco ones uses a hidden command but TAC won't help you if you have problems (even if they're unrelated, from what I've heard) If possible, look at Direct Attach Cables as well. They're less flexible because the 100gig ones, for example, have fixed length limits, but they're much cheaper than SFPs.
|
|
#
?
Feb 17, 2019 01:49
|
|
|
Ymmv, the command above is 'service unsupported transciever'. If dom is important to you you should get optics that are programmed for that vendor type. Also some devices have dual purpose interfaces which may require you to specify the interface type for it to work.
|
|
#
?
Feb 17, 2019 01:58
|
|
|
There's enough caveats that I would say no, they aren't plug and play. Even if you buy official branded optics compatible with your device, you also have to know if you want single mode/multimode for example. On top of that, it varies by vendor. For Arista if you want to use off-brand optics, you have to contact support or your SE and they will give you a custom key to enter into your config that's unique to your account. code:uhhhhahhhhohahhh posted:If possible, look at Direct Attach Cables as well. They're less flexible because the 100gig ones, for example, have fixed length limits, but they're much cheaper than SFPs. Also this, Twinax is pretty nice if you are just dealing with short runs, imo. Unless you're working with my old boss who kept somehow ripping off the pull tabs and leaving the cables stuck in switches for us to find and pry out later 
Docjowles fucked around with this message at 03:10 on Feb 17, 2019 |
|
#
?
Feb 17, 2019 03:05
|
|
|
This is what I think of when I hear twinax. We used to have this stuff everywhere at work. https://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/Twinax_Stecker.jpg/278px-Twinax_Stecker.jpg
|
|
#
?
Feb 17, 2019 05:20
|
|
|
uhhhhahhhhohahhh posted:You can use non-Cisco ones uses a hidden command but TAC won't help you if you have problems (even if they're unrelated, from what I've heard) I don't know about other teams or if things have changed in the several years since, but when I was in TAC on the IOS-XR team this was not the policy. We would troubleshoot as normal if someone had a third party transceiver, and definitely with anything Layer 2+ we wouldn't blame the transceiver unless we had a particular reason to do so. If the actual optical controller was complaining and there wasn't another apparent cause then yeah, we'd probably blame the transceiver. That seems pretty logical to me though - if I see an issue with the controller and light levels are good, probably the first thing I'm going to try is swapping the transceiver even with an OEM one. Eletriarnation fucked around with this message at 06:26 on Feb 17, 2019 |
|
#
?
Feb 17, 2019 06:23
|
|
|
I buy optics from FS or Flexoptix and they flash the product codes of the Cisco/Aruba/whatever modules in to avoid having to have arguments with support.
|
|
#
?
Feb 17, 2019 11:31
|
|
|
We also use flexoptix, flash ourselves. It makes inventory control and sparing much more pleasant when you have multiple vendor stuff. Always keep a "real" optic around to appease JTAC / Cisco tac(whatever their name is) folks, they've gotta check that box on the flowchart.
|
|
#
?
Feb 17, 2019 14:36
|
|
|
So fiber modules plug into an EHWIC slot correct? And then you simply change the media type on the interface. This is on a 2901. Also if anyone knows a good read about layer 7 load balancing I'd appreciate it. Woof Blitzer fucked around with this message at 05:54 on Feb 18, 2019 |
|
#
?
Feb 18, 2019 05:31
|
|
|
Woof Blitzer posted:So fiber modules plug into an EHWIC slot correct? And then you simply change the media type on the interface. This is on a 2901. Not quite - you stick something like EHWIC-1GE-SFP-CU into the EHWIC port. This has an SFP interface which you insert a SFP fibre module into (which might be single mode, multimode, LC, SC etc depending on the fibre you plan to use for the run). The discussion above is more about whether you can use a Cisco or non-Cisco brand SFP module (yes, mostly).
|
|
#
?
Feb 18, 2019 09:13
|
|
|
Is there any real difference between optics? I was told they're all pretty much made in the same factory and just get slightly different software put on them? I've always worked in places that cheap out on the optics and use the service unsupported transciever command.
|
|
#
?
Feb 21, 2019 21:37
|
|
|
Consistancy and adherence to half assed implementations of the SFP MSA. There have been cases where optics have caused issues, but it is almost universally bad code in the router/switch.
|
|
#
?
Feb 22, 2019 01:50
|
|
|
|
| # ? Apr 25, 2024 16:22 |
|
|
In the old days there was no differentiation between vendor and non-vendor optics. Then AT&T ended up with a bad batch that violated the thermal envelope of the box they were installed in. This led to a bunch of back and forth fingerpointing with Cisco and now we have service unsupported transceiver.
|
|
#
?
Feb 22, 2019 14:15
|
|