|
Judge Schnoopy posted:Except the loving receiver hook button. Which breaks all the time on nearly every 7941 and 7961 I've come across. That must have changed on the 41/61s, I didn't deal much with those because they were a pain in the rear end to get working on non-Cisco PBXes, so we moved to primarily pushing Polycom at that point.
|
#
?
Nov 23, 2017 17:08
|
|
|
|
| # ? Apr 23, 2024 14:54 |
|
|
Magnetic hook switches are the future
|
|
#
?
Nov 23, 2017 17:10
|
|
|
Once you figured out how to get the SIP image on them and tcpdump enough to figure out which files they're looking for on your tftp server, they work great! Also the hook on those was a tiny reversible piece of plastic, surely you could just replace just that part. Re: used market Cisco- this is a much better idea than buying Cisco rebranded Linksys.
|
|
#
?
Nov 23, 2017 17:12
|
|
|
Most of our phones that break are in our manufacturing plants and people beat the poo poo out of them.
|
|
#
?
Nov 23, 2017 18:05
|
|
|
The hookswitch in the 7941/7961 sucks my rear end. They are also subject to easily cracked solder joints on the Ethernet daughter board. The 7941G-GE model had a higher failure rate in my environment. Then the wonderful new 79x2/79x5 models arrived with the ol' "flash memory fails and maybe it will turn off some day and never work again". Less frequent but still annoying. The 7940s and 7960s don't really break, but they will probably fall off again soon. I've had this debate with GreenKnight elsewise but, yes, you can buy 7900 series phones for dirt. They're worth dirt and should be thrown away and especially not put anywhere where they can become a new IoT compromise vector. The 7945/7965 will be end of support in January, there's no more software, and no more patching. Lotta little cheap Java computers that are good for tinkering, but, really no longer appropriate for a typical enterprise environment. I think I posted before but I ended up with a massive problem with the 79x1 models I support, and a lesser issue with the 79x2/79x5 models. It ends up being something regarding some type of traffic that the latter models just don't like and chug on, the 79x1s become unusable garbage until physically power cycled. The audio breaks up, the UI lags or fails to function. TAC support opened on this months before the failure kept wasting time with "Collect the logs" and "I don't see anything in the logs" to the point of us taking videos. Support ended and TAC eventually confirmed if you send more than 1 billion packets through/at the phone something in the hardware overflows or breaks (state machine?) and the whole thing goes to poo poo. In that case it didn't matter that the phone's management was on a separate VLAN, it was the nature of traffic flowing through it from other networks that broke it. Dumb, but, also not practical to fix in any way. I started to go down the road of setting up Energywise but that is a pain to overlay into an environment that doesn't have it. Instead we re-segmented other data traffic, did ping sweeps and manual reboots, and eventually started replacing hardware. For the cost of the time spent on the issue, it wasn't worth it to do anything but replace the phone.
|
|
#
?
Nov 23, 2017 19:46
|
|
|
My only hassle was upgrading the firmware but I got it to work. The hang up hook yeah is poo poo and I’ve had issues with the stand on phones forever.
|
|
#
?
Nov 23, 2017 19:55
|
|
|
So there are three tricks to that depending on how much fooling you want to do. All of them involve opening the phone, which are the two phillips screws under the two foam rubber feet on the rear. Then, you sort of pop the case at the bottom and pull down while prying a bit. It is way easy to shatter the tabs that hold the top of the case together. Next, you can swap the hookswitch from a working one, it's a cable, a phillips screw, and the stupid paperclip spring. You used to be able to buy the boards online. You can bend the stupid paperclip which will rejuvenate the phone. You can also buy a small washer that goes in there which will space out the "self cleaning" button that also works. I can get a part number for that if you need it and it does work. While you're in there note that you can swap the Ethernet boards between like models, same with displays, speakers, etc. This is not the case for the 79x2/79x5 models, where it is a single board and an optical hookswitch. Which does have a field notice out that if there's too bright a light nearby that leaks into the case it won't work right.
|
|
#
?
Nov 23, 2017 20:54
|
|
|
Partycat posted:The hookswitch in the 7941/7961 sucks my rear end. They are also subject to easily cracked solder joints on the Ethernet daughter board. The 7941G-GE model had a higher failure rate in my environment. Then the wonderful new 79x2/79x5 models arrived with the ol' "flash memory fails and maybe it will turn off some day and never work again". Less frequent but still annoying. The 7940s and 7960s don't really break, but they will probably fall off again soon. Please tell me there is an official bug for this because it sounds like a nightmare. What were you doing that 1 billion packets were going through the phone?
|
|
#
?
Nov 23, 2017 22:40
|
|
|
Maybe the phones were just on for a long time. I can see a thin client wired into the switch port on the phone pushing a billion packets in not too long.
|
|
#
?
Nov 23, 2017 23:09
|
|
|
Bigass Moth posted:Please tell me there is an official bug for this because it sounds like a nightmare. What were you doing that 1 billion packets were going through the phone? I have the information from TAC on how it's a hardware issue but they waited until after the support window ended on the devices to conclude the cases and did not issue a bug ID. The TAC case proved that if you jammed the phones full of traffic they'd break. On my end the issue was that I'd power cycle the device and it could break in an hour - and it wasn't sucking down a billion packets. I was convinced it actually had something to do with the rate of traffic over some interval that was breaking everything. I also suspected that it was something either oversized multicast or L2 - since we were able to prove that the voice VLAN on its own didn't cause any issues, but, having a data VLAN out to the phone with ambient traffic was enough to break it. So, no not really I just have my case ID. And yes it sucked major eggs to work on that issue. We could pull the DSP and Ethernet stats from the device, and traffic captures, to show that the traffic from the switch to the phone was fine, and the traffic from the phone to the PC port with SPAN enabled was fine, but the traffic from the internal Ethernet "port2" or whatever went to the CPU was not fine and things were getting lost between there and the jvm. That took ages to get TAC to stop asking me to collect packet captures from some remote firewall or the UCM since they would never actually look at the information on hand. Hence the video recordings, phone console port dumps, like 3 or 4 simultaneous capture sessions, all for more-or-less someone to go, yeah, that's broke oh well. I forgot the suggestion that we just separate the phones and computers, which, since that requires more wiring and switch ports replacing hardware was cheaper. That's a whole other story, but, the conclusion I can draw from that is that they have a large enough market share that if you're running 10 - 20k phones you don't have enough clout to count for much at this point, you have to be making a new purchase and wheedle discounts, or convince Cisco you will seriously consider ripping their stuff out for another vendor and then maybe they come around. Partycat fucked around with this message at 04:30 on Nov 24, 2017 |
|
#
?
Nov 24, 2017 04:26
|
|
|
That really sucks. Where I work whenever a 79xx has issues we just replace it with an 8841. Only about 4000 79xx left!
|
|
#
?
Nov 24, 2017 14:22
|
|
|
I need help with ACLs, wildcard masks and determining if an address should be permitted or denied based off of it. I'm currently reading the chapter in Routing & Switching course on netacad. I thought I had a handle on it but then in the activity part this happened:  What am I not understanding? I thought 0.0.255.255 meant meant that the first two addresses had to match up exactly while the last two could be anything. Am I having a genius moment and not seeing something here? Did Cisco screw up? Looking up these things online is tough because a lot of the content I've found are how to easily find your Wildcard Mask. Honestly, taking these classes made me realize that I wish IPv4 would burn to the ground and IPv6 takes over everything. Any help would be appreciated. Normally, this wouldn't be so bad but because no one wants to learn networking around these parts I had to take an accelerated class (because that's the only class that received the bare minimum of students to prevent it from being cancelled), I'm under enormous pressure to learn this stuff in a short amount of time before the semester is over.
|
|
#
?
Nov 29, 2017 19:14
|
|
|
It's a permit ACL and your second octet is different to the one in the rule.
|
|
#
?
Nov 29, 2017 19:31
|
|
|
Jimbot posted:I need help with ACLs, wildcard masks and determining if an address should be permitted or denied based off of it. 172.16.0.0 0.0.255.255 does not cover 172.17.0.0 0.254.255.255 or /15 is what you'll need to use. Do you understand the actual binary math behind wildcard masks and subnet masks, or have you just memorized that 0.0.255.255 = free for all with the last two digits. Methanar fucked around with this message at 19:56 on Nov 29, 2017 |
|
#
?
Nov 29, 2017 19:52
|
|
|
Methanar posted:172.16.0.0 0.0.255.255 does not cover 172.17.0.0 I think we may have gotten our signals crossed here or all this is just flying over my head. I probably should have posted the entire activity to give it some context:  It wants me to identify if the address provided would be permitted or denied based off of the ACL statement. That said, maybe my math is completely wrong on this. I will admit it has been a while since I did subnetting. I can write it all out in binary, but I'm not sure what you are asking. I'm not trying to be obtuse here either. This is the first section of this chapter and it gives me about four or so pages of explanation with not much binary math used. The most it does is show me the network range of the wildcard mask.
|
|
#
?
Nov 29, 2017 20:29
|
|
|
Jimbot posted:I think we may have gotten our signals crossed here or all this is just flying over my head. I probably should have posted the entire activity to give it some context: quote:What am I not understanding? I thought 0.0.255.255 meant meant that the first two addresses had to match up exactly while the last two could be anything. Am I having a genius moment and not seeing something here? I think the confusion is that you aren't seeing that the second octet is different between the two. In the first column its 172.16 and in the second its 172.17 quote:I thought 0.0.255.255 meant meant that the first two addresses had to match up exactly while the last two could be anything. Your comment here is correct. The situation is that the first two octets do not match up exactly
|
|
#
?
Nov 29, 2017 20:49
|
|
|
Methanar posted:I think the confusion is that you aren't seeing that the second octet is different between the two. In the first column its 172.16 and in the second its 172.17 To clarify for him. That means the ACL in question is a PERMIT ACL if you want to block it using that rule. You end up implicitly denying (assuming a DENY any any at the end of your list) any address that doesn't match a PERMIT rule.
|
|
#
?
Nov 29, 2017 20:53
|
|
|
Given that nothing is known about any implicit rule, I'd have to say that the outcome of the rule in question is to deny traffic, and the question was answered correctly.
|
|
#
?
Nov 29, 2017 21:26
|
|
|
Thanks Ants posted:Given that nothing is known... Cisco test questions are rife with unstated assumptions
|
|
#
?
Nov 29, 2017 22:33
|
|
|
It's the first chapter on ASLs. I'm just being introduced to them, so that's why I'm struggling. If it's a mistake on Cisco's part then that makes it even worse. If it's a mistake on my part I want to understand what I did wrong. Luckily, I can get some lab time in between other classes tomorrow so I can ask my professor directly. It's just frustrating.
|
|
#
?
Nov 29, 2017 22:59
|
|
|
You have traffic destined for 172.17.0.5. You have the ACL in place to permit code:In an ACL, any traffic that is not explicitly allowed, is dropped. The answer to the question is deny.
|
|
#
?
Nov 29, 2017 23:14
|
|
|
Jimbot answered with deny from the looks of the earlier screenshot though, and it was marked wrong. The UI of the test is shockingly poor but I think that's what's going on.
|
|
#
?
Nov 29, 2017 23:21
|
|
|
Yes, that's exactly what happened. It's why I made a stink of it on here. That's why I had self doubt because I understand this stuff at least enough to know that if it were configured that way it'd Deny that IP address. Another one that's throwing me through a loop is the 192.168.15.5 address (third one down). The math on that one does not add up either but that, too, says "Deny" is incorrect. It's been a while since I posted in here originally, so I've moved on. But I still have to learn this stuff and if Cisco can't even get this material correct in these Activities then it makes it all the harder. I mean, what else have they screwed up?
|
|
#
?
Nov 30, 2017 00:03
|
|
|
Jimbot posted:I mean, what else have they screwed up? https://www.cisco.com/c/en/us/support/docs/field-notices/636/fn63697.html
|
|
#
?
Nov 30, 2017 00:18
|
|
|
See my post a few pages ago where their top of the line edge router can't actually be racked properly in a 19" rack with the rails it ships with?
|
|
#
?
Nov 30, 2017 01:26
|
|
|
Is that an actual Cisco prep application or some other vendors? And yeah the exams tend to sometimes make some assumptions which you can blow by out thinking the question. They include a box though where you can shout into it about why the question is bad and maybe they wipe that one off the test for you - or maybe not. ACLs are cool as sometimes they are used to mark traffic and can work opposite of they way you would think depending on what you're trying to do.
|
|
#
?
Nov 30, 2017 13:34
|
|
|
It's an activity that's part of the netacad online course. I'm surprised it works in Chrome because their online tests still use Flash and Javascript (if there's a question that requires you to use packet tracer). It just took me by surprise since the track record for the activities has been perfect so far, this is the first major problem I've had with it. A number typo dealing with IP ranges makes a huge difference. I learned very early on is that you should at least read the question several times before answering. Their quizzes are more straight-forward and test you on knowledge (they're not weighed into your grade) on tests they like to throw you through a loop by wording them in a particular way. If I got something wrong it was often because I misread the question or misunderstand what it was asking. Nothing against ACLs. Doing them brings me back to subnetting, which was long and tedious garbage. Jimbot fucked around with this message at 02:32 on Dec 1, 2017 |
|
#
?
Nov 30, 2017 20:29
|
|
|
I know we have some Palo Alto folks here. I've got a question about dual BGP, Local-AS and NAT. So I have two providers, BT and Colt. BT provides a public /29 and their router sits on it and so does the Palo Alto Firewall. i.e. BT Space: 7.0.0.0/29 Their Router: 7.0.0.5 Our Router: 7.0.0.1/29 We have a PBX with a static NAT on 7.0.0.2 and it works fine. Colt is a bit different. We have a /30 transit link with them that we run BGP over. Transit: 7.1.1.0/30 Their router: 7.1.1.2 Our router: 7.1.1.1/30 They also have allocated a /29 for us: 7.1.2.0/29 We want to create another Static NAT for our PBX on the /29 block and obviously advertise that /29 out to Colt. On juniper that can be accomplished by creating a discard route and setting up a NAT pool. However an PanOS the discard route apparently occurs before the natting is applied. code:
|
|
#
?
Dec 1, 2017 21:21
|
|
|
https://live.paloaltonetworks.com/t5/Configuration-Articles/BGP-Redistribution-Rules-to-Explicitly-Advertise-Host-Routes-and/ta-p/63123
|
|
#
?
Dec 1, 2017 21:44
|
|
|
Sepist posted:https://live.paloaltonetworks.com/t5/Configuration-Articles/BGP-Redistribution-Rules-to-Explicitly-Advertise-Host-Routes-and/ta-p/63123 Cool. Now I wonder if there is a way to make Palo Alto do the long lost art of "local-as" for it's BGP configurations, or maybe BGP-SNMP MIBs.
|
|
#
?
Dec 1, 2017 22:13
|
|
|
The Palo Alto equivalent to local-as is you would need the interface in its own virtual router so it can have it's own AS number. The only issue with that is it complicates your routing table as you now have to forward packets out of the default vr when going through that interface.
Sepist fucked around with this message at 23:19 on Dec 1, 2017 |
|
#
?
Dec 1, 2017 23:13
|
|
|
Sepist posted:The Palo Alto equivalent to local-as is you would need the interface in its own virtual router so it can have it's own AS number. The only issue with that is it complicates your routing table as you now have to forward packets out of the default vr when going through that interface. Yea that was the work around we used, it just seems so inelegant and blah....
|
|
#
?
Dec 2, 2017 04:42
|
|
|
Terminate your BGP peers on a real router?  I love the Palo Alto's, one of my favorite pieces of hardware to work on, but I hate using them for routing. I always try to sell a customer a router if their network is using something other than static routing but that drat budget always seems to get in the way.
|
|
#
?
Dec 4, 2017 15:02
|
|
|
Sepist posted:Terminate your BGP peers on a real router? Yea we usually use 300 series SRXs for our office routers, unfortuantely the group that actually bought this equipment decided to ignore our standards and do their own thing, so now we have a non-standard office setup and have gotten to figure out all kinds of fun limitations :/
|
|
#
?
Dec 4, 2017 17:24
|
|
|
SRXs are pretty inexpensive so you must be close to saving no money once your time has been accounted for.
|
|
#
?
Dec 4, 2017 17:58
|
|
|
Hell, the "no budget" option of VyOS on an old server would probably save you time and aggravation compared to trying to make the firewall do routing.
|
|
#
?
Dec 4, 2017 18:03
|
|
|
I have what seems like a dumb question but no one I've asked in person seems to know the answer and nothing obvious came up Googling it. At what point does Cisco actually stop releasing updated firmware versions for a switch? I ask because my office has still has a number of older switches which according to Cisco are end of life and, by my reading of the EOL announcement, shouldn't of had any new compatible software released for over 2 years. That seems simple enough but when I actually browse through the available downloads for those models there've been a number of compatible iOS releases since then including one just 2 months ago. What gives? Is Cisco just ignoring their own announced plans? Is it just a CYA to let them drop support blame free at a later date and encourage early replacements? My office is fortunate enough that if we point to network infrastructure and say it's no longer eligible to receive security patches we can get funding to replace it but I'm not sure that's the case and frankly it's otherwise not worth the time to do so since our oldest switches are typically just servicing a few devices at minor outbuildings.
|
|
#
?
Dec 5, 2017 06:17
|
|
|
Does anyone have strong opinions on Calico vs Flannel for on-prem Kubernetes?
|
|
#
?
Dec 5, 2017 06:58
|
|
|
Elem7 posted:I have what seems like a dumb question but no one I've asked in person seems to know the answer and nothing obvious came up Googling it. At what point does Cisco actually stop releasing updated firmware versions for a switch? I don't have an answer to your question but we don't give a poo poo if our old switches no longer receive firmware updates. Edge switches/routers? Yes, absolutely. But the 48 port switch in our manufacturing facility that just has phones connected to it? Don't care.
|
|
#
?
Dec 5, 2017 14:15
|
|
|
|
| # ? Apr 23, 2024 14:54 |
|
|
If you want to extend multitenancy/network separation down to the container host I'd go with Flannel.
|
|
#
?
Dec 5, 2017 15:29
|
|
