Bug 1600668
| Summary: | ipxe fails to function in presence of high amounts of flooded unicast and broadcast traffic | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Joe Antkowiak <joea> | ||||||
| Component: | ipxe | Assignee: | Neil Horman <nhorman> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 7.5 | CC: | bfournie, bhu, cjanisze, jen, jmelvin, joea, mburns, nhorman, srevivo | ||||||
| Target Milestone: | pre-dev-freeze | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2019-01-02 13:22:38 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Joe Antkowiak
2018-07-12 17:56:52 UTC
Created attachment 1458484 [details]
node console screenshot of ipxe failing to load the next image file
Created attachment 1458485 [details]
node console screenshot of ipxe failing to load the next image file (second failure type)
Hi! What could we do to improve the situation, considering that it's way out of control of ironic itself. Maybe you could publish a KB article explaining the issue? I'm really not sure what we can do in the code to fix it. I agree, this is not an ironic issue, this is an issue with the ipxe image. The ipxe network stack should operate like a standard network stack and ignore all unicast traffic received on the nic that is not destined for its mac address. Receiving flooded unicast traffic (just like being on a hub vs a switch) should not break functionality of ipxe. This isn't a broadcast storm instance, this is just normal ethernet unknown unicast flooding that occurs on hubs or when a switch hasn't identified where a mac address is. Are we able to fix an issue in ipxe? We get the iPXE image from RHEL, redirecting to RHEL folks for their input. can you mirror a port on the peer switch to a failing ipxe node and capture the traffic during a failure please? To be perfectly honest, the problem description doesn't make any sense to me. If the incorrectly flooded traffic is unicast, then it should be squashed by the NIC itself via the mac filter table which should only let in traffic from its own mac, or the broadcast mac (unless you have a very very old NIC that has no filtering capabilities). Getting a network trace (in pcap format), would help me root cause this issue and develop an appropriate fix I'll do my best to get that capture, but it can be done by doing a pxe>ipxe boot via a switch port that is configured as a span port with a lot of extra unicast traffic You are exactly correct, the nic -should- be filtering that out, but for some reason it doesn't seem to be when it's running the ipxe image. PXE works fine to chainload ipxe, but once ipxe is up that's when it fails Perhaps ipxe is doing something to the NIC to make it process and forward all traffic to the ipxe network stack? (promiscuous mode?) Its certainly possible, but I don't see anything in any drivers that explicitly force promisc mode. theres some higher layer cases where that appears to happen, but nothing that you would hit in normal operation. Any luck on the capture? also, what is the pci id tuple of the nic in question here? This has gone unanswered for over two months now. Closing for lack of response The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |