Hello team, I have a wierd issue.
We run HP switches and I have been removing any ports not monitored or no longer need to be monitored right across the board of 80+ switches.
So, on my core switch (HP5412zl version1), I removed sflow fully and disabled it. I re-enabled it, thus clearing all of the sflow information inside the switch. I double checked the (sho run) to make sure that the data was gone.
I did a write memory to commit this change.
I re-added all of the interfaces that we need to monitor, re-setup sampling and polling accordingly.
For the last week, I have been troubleshooting the unmonitored netflow interfaces in my events on the solar wind side. I still have interfaces showing up here that are 100% not sending traffic, according to my switch, they were however monitored in the past.
My only thought would be to delete the node from solar winds fully and re build that side of things.
I also have no clue why solar winds would see this data, unless the switch was actually sending it. Its not regular like sflow is normally, and its not at a specific time.
Here is a screen shot.
Any advice would be great.
Sorry, must have included too much information and confused things a bit.
The point of my post is that flow packets contain both source and destination interface information in every packet, regardless of what interface was used to generate the packet. Lets say your monitoring flows on interface B1 and B12, but not B2 through B11. If you then get a bunch of data packets coming in on B1 and leaving the box on interfaces B2 through B12, the netflow packets that are generated as a result will have a source port being B1, but destination ports of B2 through B12. So, even though you don't have those ports configured to generate flow packets, doesn't mean that packets from other ports don't have those ports in them...
However, if traffic comes in on B2 and goes to B3, you shouldn't see those ports at all because neither port is configured for doing flow packets.
Does that make better sense?
I believe the error messages your seeing is because Solarwinds wants to have a bucket to put information into for all the packets, regardless of their source/dest port on the box. And if you aren't monitoring all ports that can be involved in traffic transiting ports you have configured for netflow, its going to complain I believe...
This makes more senses, thank you for explaining it differently. It sure does make more sense, because its random times, random (un-monitored) ports that show up in my log. Like a one off communication between devices.
So is there any way to not have this show up? or is this something that we just need to deal with?
Sure, add the ports in Solarwinds like it asks!
Actually its not a bad thing to do, all your doing is making a database bucket for the data to fall into I think. It doesn't mean you have to set up the port on the box for Netflow. However, you will most likely be missing part of the picture. But, that depends on how your netflow works, once again getting back to the ingress, egress or both topic.
If you're monitoring B1, but not B2, and you have a conversation start up that comes in B1 and goes out B2, there is probably data being returned by the remote system transiting your box in the reverse direction.
So, if you have "ingress" netflow on the box, which is what most boxes do and the little I read on HP's made it sound like it is. But, if you have ingress netflow, you would see the one side of the conversation that comes in on B1, but not the return traffic from B2.
If you have "egress" netflow, you would not see the source traffic, but would see the return traffic.
If you have "both" ingress and egress on a port, you would see both sides of the conversation.
Caveat on the "both". Let's say you have traffic coming in on B1 and going out on B12, both of which are monitored. With both, you will probably see double the traffic volume, because its reported on two different interfaces. Lets say the source was on system A connected to B1, and the destination was system X connected on B12. The first packet going from A to B would be reported as coming from interface B1, with a source IP of A and destination IP of X The same packet would be also reported as coming from interface B12, with a source IP of A and destination of X. When X responds, you'd see the first netflow packet from B12, with the source of X and the destination of A. Then you would see another packet from interface B1 with the source of X and the destination of A. But all of those would be from the same box. That's why "ingress only" or "egress only" tends to be more "standard" because you only get the packet on the incoming (or outgoing) interface, not both.
That's also why configuring ingress on every port is the recommended configuration for netflow, not to just configure it on the interfaces you're most interested in. Otherwise you usually lose half of the TCP/IP conversation and only see one direction, at least for traffic that goes across unmonitored ports... It's also why its important to know what your box is doing or capable of, so you know what you're getting from Netflow.
So, the question would be, why are you only monitoring some ports? If you're worried about Netflow volume or the load on the box, neither are usually an issue, Netflow volume is usually quite low from how the protocol is designed to work, at its usually processed in hardware so it doesn't have much of a load on the box... Just curious what other reasons there might be?
The message, that its receiving flow data from an unmanaged interface, isn't really accurate since the interface doesn't actually send the Netflow packets. Its receiving it from the box that has the interface on it. This is kind of important in that a Netflow packet has lots of information in it, including the source and destination interfaces that it is using to transit the box. Usually folks do ingress netflow, but you can do egress or both depending on the configuration. So, if you're doing ingress Netflow, the packet would be generated on the interface its entering the box, but not the interface its exiting the box through, but that packet should still contain both interfaces in it. If you do both ingress and egress, you should get a packet from both interfaces also.
Getting back to your issue. Let's say your monitoring Gi0/0 for ingress packets, but not monitoring any other interfaces including Gi0/1. If a packet comes in on Gi0/0 that is destined to go out Gi0/1, the netflow packet should still have both interfaces in it. I could see Orion complaining that the interface it has as an egress interface isn't being monitored? Not sure though. My practice is to monitor all interfaces for ingress traffic no matter what. That way I see all traffic transiting the box.
So, in other words, just because Netflow isn't configured on an interface, doesn't mean that it doesn't show up in Netflow packets from a box.
Hopefully I'm not too off base here! Just making a guess based on what I'm seeing...
Sorry Craig I'm having a little trouble following your post.
in most cases we never specify in or out, its both by default I thought.
We monitor an interface with the following HP commands:
sflow 1 polling 24 60
sflow 1 sampling 24 4096
In the example above I am polling port 24 every 60 seconds, and I am sampling on port 24 every 4096th packet. We never specify in\out\both
Here is my current list on my core.
SFlow Sampling Information
| Sampling Dropped | Polling
Port | Enabled Rate Header Samples | Enabled Interval
----- + ------- -------- ------ ---------- + ------- --------
B1 Yes(1) 4096 128 0 Yes(1) 60
B12 Yes(1) 4096 128 0 Yes(1) 60
B14 Yes(1) 4096 128 0 Yes(1) 60
B15 Yes(1) 4096 128 0 Yes(1) 60
B19 Yes(1) 4096 128 0 Yes(1) 60
C17 Yes(1) 4096 128 0 Yes(1) 60
G22 Yes(1) 4096 128 0 Yes(1) 60
K1 Yes(1) 4096 128 2522 Yes(1) 60
Trk1 Yes(1) 4096 128 0 Yes(1) 60
Trk2 Yes(1) 4096 128 0 Yes(1) 60
Trk5 Yes(1) 4096 128 2627 Yes(1) 60
Trk6 Yes(1) 4096 128 0 Yes(1) 60
As you can see F8, C20, F24, C7, H17, A5, H23, and A3 are not in my list at all what so ever.
I took a quick look a the commands themselves on the switch and there is not an option to only poll or sample inbound\outbound\both. I also don't see anything in solar winds to select inbound\outbound\both
So i don't understand where solar winds is getting said data from?
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.