|
Sepist posted:On the 3750 reset the interface with "default interface X/XX" and try again Did that before I did anything else. workape posted:Also, what are the outputs from "show run interface gi 3/0/5" and "show run interface fa 0/12" on their respective switches? Are you configured for no negotiate on your interfaces as well? code:
code:
And I am using a crossover cable CDP sees each other as neighbors, but the problem seems to be on the 3750 with the Administrative Mode/Encapsulation not carrying over to the Operational Mode/Encapsulation.
|
# ? Aug 30, 2013 16:47 |
|
|
# ? May 28, 2024 02:54 |
|
QPZIL posted:
No, turning off DTP negotiation. Sorry about that. Issue the switchport nonegotiate on ports on both ends do that you are statically setting the trunk and then shut/no shut the interfaces to ensure that they come back up in an operational state.
|
# ? Aug 30, 2013 16:56 |
|
workape posted:No, turning off DTP negotiation. Sorry about that. Issue the switchport nonegotiate on ports on both ends do that you are statically setting the trunk and then shut/no shut the interfaces to ensure that they come back up in an operational state. Still didn't work. Here is the log from the 3750: code:
code:
code:
Count Thrashula fucked around with this message at 17:51 on Aug 30, 2013 |
# ? Aug 30, 2013 17:48 |
|
Using PRTG for bandwidth monitoring. SNMP2 setup on device. Layer 3 ports work fine. I need to create several SVIs and use them as the routable interface on an aggregate switch/router. PRTG has a limitation where the SNMP Bandwidth Monitor will not report bandwidth that routes across an SVI. I have not been able to find any information online as to a solution. Any ideas?
|
# ? Aug 30, 2013 18:44 |
|
Maybe it is related to your native vlan mismatch, either issue switchport trunk native vlan 1 or switchport trunk native vlan 5 on each and see where it takes you. My hunch is that it is blocking due to both vlans being untagged/tagged depending on which direction they are going.
|
# ? Aug 30, 2013 18:46 |
|
Sepist posted:Maybe it is related to your native vlan mismatch, either issue switchport trunk native vlan 1 or switchport trunk native vlan 5 on each and see where it takes you. My hunch is that it is blocking due to both vlans being untagged/tagged depending on which direction they are going. That was actually the next thing I did after my last post. The CDP errors went away, and VTP isn't doing anything now, but I still have the "Administrative mode: trunk" / "Operational mode: static access" mismatch on the 3750 switch. So weird.
|
# ? Aug 30, 2013 18:50 |
|
What IOS on the 2950 and 3750? Outputs from "sh spanning-tree summary" on each. No other connections between the 2950 and 3750?
|
# ? Aug 30, 2013 18:59 |
|
routenull0 posted:What IOS on the 2950 and 3750? System image file is "flash:/c2950-i6q4l2-mz.121-14.EA1a.bin" System image file is "flash:/c3750-ipbasek9-mz.122-46.SE.bin" routenull0 posted:Outputs from "sh spanning-tree summary" on each. 2950: code:
code:
routenull0 posted:No other connections between the 2950 and 3750? None, just a single crossover cable going between fa0/12 on the 2950 and gi3/0/3 on the 3750. (which is one switch of a 7-switch stack)
|
# ? Aug 30, 2013 19:10 |
|
After setting the appropriate native vlan on both switches, are you still getting?code:
Have you attempted to debug spanning-tree and capture the output?
|
# ? Aug 30, 2013 19:27 |
Zuhzuhzombie!! posted:Using PRTG for bandwidth monitoring. SNMP2 setup on device. Layer 3 ports work fine. I like PRTG. I wish there was a linux rpm variant.
|
|
# ? Aug 30, 2013 19:44 |
|
routenull0 posted:After setting the appropriate native vlan on both switches, are you still getting? As I mentioned earlier (I may have been unclear), setting the native VLAN on both sides stopped all STP/CDP/any kind of messages. Both sides are sending out STP packets, and nothing looks fishy there that I can tell.
|
# ? Aug 30, 2013 19:54 |
|
Flash z0rdon posted:I like PRTG. I wish there was a linux rpm variant. It works great in every other capacity. We can even do what I'm trying to do here with ASA's since they do not have a CEF table. It just can't, as far as I can see, monitor bandwidth across an SVI. I got a trouble ticket in and a post on their forum to see if there's a MIB or something I can install that will do it.
|
# ? Aug 30, 2013 20:11 |
|
QPZIL posted:As I mentioned earlier (I may have been unclear), setting the native VLAN on both sides stopped all STP/CDP/any kind of messages. Both sides are sending out STP packets, and nothing looks fishy there that I can tell. So at this point the only problem is code:
|
# ? Aug 30, 2013 20:29 |
|
Sepist posted:So at this point the only problem is It is an issue though, since the 2950 switch is not pulling down VTP info and can't ping the 3750 switch or the router it's connected to... i.e. it's not trunking.
|
# ? Aug 30, 2013 20:36 |
|
QPZIL posted:It is an issue though, since the 2950 switch is not pulling down VTP info and can't ping the 3750 switch or the router it's connected to... i.e. it's not trunking. Maybe a dumb question but have you checked VTP domain/pass?
|
# ? Aug 30, 2013 20:42 |
|
Zuhzuhzombie!! posted:Maybe a dumb question but have you checked VTP domain/pass? Yep. And actually I just set up a spare 3550 with the same configuration as the 2950, and the same issue occurs. I think it's an issue with the 3750 not wanting to change from "static access" to "trunk". Actually... I just have an idea...
|
# ? Aug 30, 2013 20:51 |
Zuhzuhzombie!! posted:It works great in every other capacity. We can even do what I'm trying to do here with ASA's since they do not have a CEF table. It just can't, as far as I can see, monitor bandwidth across an SVI. I got a trouble ticket in and a post on their forum to see if there's a MIB or something I can install that will do it. i monitor bandwidth on SVI's all the time. version 9 and 13 edit: this is on 6500's though. Flash z0rdon fucked around with this message at 23:23 on Aug 30, 2013 |
|
# ? Aug 30, 2013 23:15 |
|
Zuhzuhzombie!! posted:Using PRTG for bandwidth monitoring. SNMP2 setup on device. Layer 3 ports work fine. Edit: it's that it won't show hardware switch packets, which is the ones you care about. http://puck.nether.net/pipermail/cisco-nsp/2005-March/018406.html
|
# ? Aug 30, 2013 23:40 |
|
Both sides have to be native or both have to switchport trunk native vlan x You get the same issue when you do router on a stick and forget native or put it on.
|
# ? Aug 31, 2013 00:10 |
|
Flash z0rdon posted:i monitor bandwidth on SVI's all the time. version 9 and 13 Yeah, we have some HSRP groups that we're monitoring on 6500s that do it. But not on a 3750.
|
# ? Aug 31, 2013 00:40 |
|
falz posted:Some fixed Cisco switches such as 3560 simply don't report unicast traffic on SVIs, just broadcast traffic. You should be able to get traffic stats with netflow on 3750/3560-X for switched ports.
|
# ? Aug 31, 2013 03:19 |
|
QPZIL posted:Yep. And actually I just set up a spare 3550 with the same configuration as the 2950, and the same issue occurs. I think it's an issue with the 3750 not wanting to change from "static access" to "trunk". Sorry if I missed it, but did you set the ports back to access mode, set them for vlan 1, then turn them back to trunks? No clue why one is white knuckling vlan 5, but thats what usually fixed native vlan mismatches for me. Lotta work for the untagged frames there.
|
# ? Aug 31, 2013 05:45 |
|
jwh posted:Cisco has product, but IPS is best imagined a owning a horse. You have to feed it, brush it's hair, take it for walks. Otherwise it gets cranky. Here's the deal: My company doubled in size about 18 months ago. Veteran staff hired underlings to help shoulder their workload without consideration of the big picture (at some point you should hire an Windows admin with a solid grasp of Group Policy). Stuff barely tolerable in a 50 employee company (leaving it up to users to install AV software, wide open shared folders) is an administrative nightmare with several hundred users. I'm a network guy; I can't fix our domain admins, but if I get first line support some breathing room, they will eventually grow into the desktop admin role my server admins won't fill. Spam filter was updated for the first time in years. Centralized AV broke at some point but will soon make a return. We're turning things around. The company's shortcomings are outside my area of responsibility, but I'm evaluating what I can do on the network side. I have the time to babysit another device. Given the risk of false positives, I would be content with IDS mode, but my question has to do with Cisco IPS effectiveness. Does it do a good job of identifying compromised machines that AV doesn't catch (flagging botnet participants via traffic analysis)? Does it catch exploit code being downloaded from a site? How well does it handle obfuscated Javascript? I can read bullet point features on a white paper, but that's not the same as knowing whether it does something well.
|
# ? Aug 31, 2013 06:09 |
|
The short answer is yes, but the longer, and better answer is no You should spring for a palo alto box, in my opinion.
|
# ? Aug 31, 2013 06:26 |
|
JWH, how long have you had PA's in your prod environment?
|
# ? Aug 31, 2013 09:04 |
|
Contingency, you just produced the best name/avatar/post combo I have ever seen Have I said this before about one of your posts? Feels familiar. Anyway.jwh posted:The short answer is yes, but the longer, and better answer is no Seconding this. I was in the middle of evaluating Palo Alto when I left my last job, and their poo poo is awesome. It was on the higher end of the price spectrum, but put it up against Cisco and it will look pretty great especially considering what you get for the money. And for the love of god, please try to get management support for taking away local admin. Surely (right? ) if you're talking several hundred users most of them are not special VP or C-level snowflakes that "need" local admin and unrestricted access to Pirate Bay to do their jobs.
|
# ? Aug 31, 2013 09:40 |
|
Herv posted:Sorry if I missed it, but did you set the ports back to access mode, set them for vlan 1, then turn them back to trunks? I'll try that when I get back to work on Tuesday. It's just so weird.
|
# ? Aug 31, 2013 19:07 |
|
Contingency posted:Here's the deal: From a safe to deploy standpoint the Cisco IPS is not bad, if you use the default sig set and have it drop traffic with a threat rating over 90 (you could start with 95-99 to be safe on first deploy) you will have a very low to zero false positives from outside to inside. The coverage is not as good as Sourcefire (they are the best IPS out there) and Sourcefire does a better job mapping and learning your network to help you deploy. If you are already a Cisco shop and you need to deploy IPS I would go with one of these, probably Sourcefire if it were me. If you don't really need IPS, meaning you lack and audit or compliance requirement like HIPAA, PCI, or something similar then I would look at an application firewall. The Palo Alto box is nice but functionally you can do most of the same thing with an ASA with integrated IPS, that is what PA is but just does a better job of integrating the two. The Sourcefire app firewall is nice as well. Like before if you are a Cisco shop with an ASA I would used integrated IPS, if it is greenfield I would add Sourcefire. If you aren't a Cisco shop then I would eval the Sourcefire and PA app firewall stuff.
|
# ? Aug 31, 2013 19:15 |
|
abigserve posted:JWH, how long have you had PA's in your prod environment? At my last job I brought Palo Altos in in 2008, I think. We were a fairly early adopter; at the time, Palo Alto had less than 500 enterprise customers. We were looking for an IPS initially, but then we evaluated the boxes and decided to use them as a direct successor to our IPS (Proventia), firewall (Checkpoint on IPSO), and URL filtering (Surfcontrol) boxes. We initially brought in four 4020s in two HA pairs and an additional PA2050 as a lab box. Back then, the boxes were shipping with 2.x PAN-OS, and 3.0 was just beginning to come out to customers. I worked with the boxes through 4.1 PAN-OS before I left the company in 2012. I like working with them very much. I had some issues, particularly in the 3.x days, mostly to do with failed heartbeats to the dataplane, and a disastrous upgrade / downgrade scenario that corrupted our configurations (3.1 to 4.0, back to 3.1). But aside from those issues (which were bad, don't get me wrong), they were great boxes. In fact, after I left the company, they upgraded to 5.x and replaced the 4020s with 5020s. I hear they've been problem free ever since. Today, I'm working on bringing in four 3050s and two PA500s to my current workplace as replacements for a handful of linux boxes and ASAs. I think they're great boxes, particularly when compared to other UTM platforms. They're the closest thing to what I had really wanted back when I was working with Checkpoint running on Solaris machines, back in 2001. If you have any specific questions about the platform, just ask away.
|
# ? Sep 1, 2013 00:48 |
|
I should also mention, one of the nicest things about the Palo Altos is that you get a whole mess of ports, and can use them in any combination of vwire, layer-2, layer-3, or tap configurations, simultaneously. That was a real benefit during our implementation, because it meant we could build policies and test them without having to position the box as a layer-3 component. Later on, we actually ended up keeping the vwires and tap interfaces to provide more visibility to specific areas of the network where we couldn't, or didn't want, to have the boxes assume routing for those networks. They're very flexible boxes. By comparison, the ASA has a very vestigial approach to things, no doubt the result of that products history and lineage. I spend most of my time with the ASA saying, "why can't I do this?". The answer is usually, "well, because that's how things were back in 1999." For example, no client VPN when running multiple context mode (unless they've finally figured that one out), no concept of tap interfaces, no application criteria in the rulebase (unless CX does this), no tunnels as logical interfaces, no secondary addressing on interfaces, the logging makes my mind melt, etc. I actually like Checkpoint more than I like the ASAs, and that's really saying something.
|
# ? Sep 1, 2013 00:57 |
|
falz posted:Some fixed Cisco switches such as 3560 simply don't report unicast traffic on SVIs, just broadcast traffic. Thanks! That was what I had come up with. Can any one confirm whether or not this Will be the case on a 4500x? dotster posted:You should be able to get traffic stats with netflow on 3750/3560-X for switched ports. Never used NetFlow but we have various NetFlow options in PRTG. Version 5 and 9, and custom of each. Dunno differences or the importance of the Custom designation. Last I looked at NetFlow it gave some options I wasn't familiar with. I'll take a look this weekend and make post what I find here. Zuhzuhzombie!! fucked around with this message at 03:35 on Sep 1, 2013 |
# ? Sep 1, 2013 03:28 |
|
ed double
|
# ? Sep 1, 2013 03:34 |
|
Zuhzuhzombie!! posted:Thanks! That was what I had come up with. I can't confirm right now but Netflow should still show out inbound packets? It's just the locally generated traffic it has problem with for the most part.
|
# ? Sep 1, 2013 04:16 |
|
I have also been running PAs in production for years; they're amazing. If only they would do DDNS, they would be perfect. I actually use a PA VM-100 as my home firewall, it's a ton of fun.
|
# ? Sep 1, 2013 08:02 |
|
I'm looking for some help, or even just another set of eyes, on what's turned into a fairly difficult problem. I've caught some weird issues before, but this one is especially resilient. Here's the setup: I have two circuits in my Boston Internap facility, both Internet transit feeds from Internap. I advertise a single /24, and we take only a default. One circuit goes to Internap's "border7" router, the other to Internap's "border8" router. I weight our border7 session and prepend (x3) our /24 to border8, in an attempt to get an active/passive scenario. There's an IPS in line which wants to see bidir flows, so this is an attempt to facilitate that. Now, everything was working just fine for months, but late last week we noticed that we lost reachability to our /24 over border7 from a handful of destinations. At first it looked like mostly international prefixes, but now we can't be sure. We do know that, at present, when we advertise our /24 via our circuit to border7, we have some very odd traceroutes. Here's me, testing from South America, in Uruguay, tracerouting toward our /24 when we only advertise to Internap's border8: code:
Anyway, here's a traceroute when we advertise our /24 to border7, no prepending: code:
I've checked the /24 as it appears to cogent's looking glass, and aside from the prepends on the advertisement we make to border8, they're identical. I'm stumped.
|
# ? Sep 4, 2013 20:11 |
|
Why not use communities to adjust the local pref on the Internap side?
|
# ? Sep 4, 2013 20:14 |
|
We could try, but I don't think it's an issue of localpref on Internap's side, it's the fact that anything toward our /24 that hits border7 seems to scatter off into space, apparently. I just find it really, really weird. We thought about advertising the /24 to border7 with a community to prevent readvertisement to Cogent, but haven't had a window to do it.
|
# ? Sep 4, 2013 20:17 |
|
http://onesc.net/communities/as6993/Internap-Customer-Guide-1.3.pdf Prepending to achieve traffic sharing can resort in all sorts of weirdness. I'd take a look at the bottom of page 4
|
# ? Sep 4, 2013 20:20 |
|
It's sort of odd though that the only advertisement that seems to work for us is the x3 prepended advertisement to border8, as opposed to the non-prepended advertisement to border7. Thanks for the doc, though, I'll check it out.
|
# ? Sep 4, 2013 20:21 |
|
|
# ? May 28, 2024 02:54 |
|
Internap has a list of communities you can use that equate to local prefs used by their upstream peers. edit: Ah yes, that's what that pdf was.
|
# ? Sep 4, 2013 22:12 |