Drag to reposition cover
Brocade ICX Series (cheap & powerful 10gbE/40gbE switching)
- Thread starter fohdeesha
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
1) Did you follow the setup config licensing guide v2 in the first post of this thread?Is anyone able to help me get to the bottom of the issues I'm having with [probably] the switch? I need to know if I should be asking for a refund for the switch, or other parts, or if there's really nothing wrong anywhere and I'm just an idiot.
2) Did you follow the steps to disable stacking - you'll need to do that in order to use the rear 40Gbe and 40Gbe breakout ports (they are different - are you aware of this?)
3) Have you learned how to pull the config from your switch? (you'll need to be able to ssh into the switch or use the console) I believe you've previously been asked to provide the config. The config is super duper helpful (really critical) for remote T/S.
If you haven't done item 1 above then at a minimum you're switch probably isn't where it needs to be for steps 2 and 3. if you purchased the switch from ebay and expected it to work out of the box its VERY UNLIKELY that it will.
One other bit of information, the intel (and oem intel) 10/40Gbe nics can be very picky about DACS and how they self identify. not saying that's an issue here but it is something to be aware of.
there's a world of difference between being ignorant and being an idiot and the first step is figuring out what you know and don't know before you decide to describe yourself as one or the other.
1. Yes
2. Yes
3. No. I was asked to do this, and I do not know how. I asked how to do this, and got no reply. I can SSH into the switch. What do I need to do to supply that information?
Regarding Intel being picky about DACs. I did the xl710_unlocker thing (which is supposed to be for optics, right?). Regardless, I think people keep glossing over the fact that only 1 of the 40 gig ports show any sign of life, and the one that does is riddled with nothing but errors. I don't mean to be rude about that last part, but please tell me what I specifically need to do on the switch to provide the required information.
2. Yes
3. No. I was asked to do this, and I do not know how. I asked how to do this, and got no reply. I can SSH into the switch. What do I need to do to supply that information?
Regarding Intel being picky about DACs. I did the xl710_unlocker thing (which is supposed to be for optics, right?). Regardless, I think people keep glossing over the fact that only 1 of the 40 gig ports show any sign of life, and the one that does is riddled with nothing but errors. I don't mean to be rude about that last part, but please tell me what I specifically need to do on the switch to provide the required information.
k.1. Yes
2. Yes
3. No. I was asked to do this, and I do not know how. I asked how to do this, and got no reply. I can SSH into the switch. What do I need to do to supply that information?
Regarding Intel being picky about DACs. I did the xl710_unlocker thing (which is supposed to be for optics, right?). Regardless, I think people keep glossing over the fact that only 1 of the 40 gig ports show any sign of life, and the one that does is riddled with nothing but errors. I don't mean to be rude about that last part, but please tell me what I specifically need to do on the switch to provide the required information.
In step 2 near the end is the following:
Code:
show runyou will need to cut and paste the output and post it here. my advice is to wrap it in "code" and in a "spoiler" so you don't post a huge reply and force people to scroll through it.
Yes I saw your comments and yeah you may have a bad switch - however I don't want to be rude and ASSUME something so I recommend starting at the beginning and provide the config. You have missed going through items 1 and 2 how to pull the config so I provided the linkage on how to do that.
Excellent, thank you. Here it is:
Code:
Current configuration:
!
ver 08.0.30uT7f3
!
stack unit 1
module 1 icx6610-24p-poe-port-management-module
module 2 icx6610-qsfp-10-port-160g-module
module 3 icx6610-8-port-10g-dual-mode-module
stack disable
!
!
!
!
vlan 1 name DEFAULT-VLAN by port
router-interface ve 1
!
!
!
!
!
aaa authentication web-server default local
aaa authentication login default local
hostname switcheroo
ip dhcp-client disable
!
no telnet server
username root password .....
!
!
!
!
!
!
!
!
!
interface ethernet 1/1/3
inline power
!
interface ethernet 1/1/6
inline power
!
interface ethernet 1/1/7
inline power
!
interface ethernet 1/3/1
speed-duplex 10G-full
!
interface ethernet 1/3/2
speed-duplex 10G-full
!
interface ethernet 1/3/3
speed-duplex 10G-full
!
interface ethernet 1/3/4
speed-duplex 10G-full
!
interface ethernet 1/3/5
speed-duplex 10G-full
!
interface ethernet 1/3/6
speed-duplex 10G-full
!
interface ethernet 1/3/7
speed-duplex 10G-full
!
interface ethernet 1/3/8
speed-duplex 10G-full
!
interface ve 1
ip address 192.168.1.5 255.255.255.0
!
!
!
!
!
!
!
!
!
endwith the QSFP DAC plugged into each of the left side connections please provide the switch's show interface output. It may also be helpful to show status output (from your OS) as well for each port but that is up to you.Excellent, thank you. Here it is:
recommend using the same cable for each interface test.
with the QSFP DAC plugged into each of the left side connections please provide the switch's show interface output. It may also be helpful to show status output (from your OS) as well for each port but that is up to you.
recommend using the same cable for each interface test.
Code:
SSH@switcheroo>show interface ethernet 1/2/1
40GigabitEthernet1/2/1 is up, line protocol is up
Port up for 1 hour(s) 17 minute(s) 51 second(s)
Hardware is 40GigabitEthernet, address is 748e.f8fe.93f6 (bia 748e.f8fe.940f)
Interface type is 40Gig Fiber
Configured speed 40Gbit, actual 40Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual none
Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
Openflow is Disabled, Openflow Hybrid mode is Disabled, Flow Control is enabled
Mirror disabled, Monitor disabled
Mac-notification is disabled
Not member of any active trunks
Not member of any configured trunks
No port name
MTU 1500 bytes, encapsulation ethernet
300 second input rate: 224 bits/sec, 0 packets/sec, 0.00% utilization
300 second output rate: 1976 bits/sec, 2 packets/sec, 0.00% utilization
7685 packets input, 826324 bytes, 0 no buffer
Received 272 broadcasts, 7404 multicasts, 9 unicasts
33 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 30 giants
502846 packets output, 56757049 bytes, 0 underruns
Transmitted 181923 broadcasts, 319738 multicasts, 1185 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Egress queues:
Queue counters Queued packets Dropped Packets
0 502861 0
1 0 0
2 0 0
3 0 0
4 0 0
5 2 0
6 0 0
7 0 0
Code:
tim@fileserver:~$ ethtool enp98s0
Settings for enp98s0:
Supported ports: [ FIBRE ]
Supported link modes: 40000baseCR4/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 40000baseCR4/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 40000Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Code:
SSH@switcheroo>show interface ethernet 1/2/6
40GigabitEthernet1/2/6 is up, line protocol is up
Port up for 32 second(s)
Hardware is 40GigabitEthernet, address is 748e.f8fe.93f6 (bia 748e.f8fe.9414)
Interface type is 40Gig Fiber
Configured speed 40Gbit, actual 40Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual none
Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
Link Error Dampening is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
Openflow is Disabled, Openflow Hybrid mode is Disabled, Flow Control is enabled
Mirror disabled, Monitor disabled
Mac-notification is disabled
Not member of any active trunks
Not member of any configured trunks
No port name
MTU 1500 bytes, encapsulation ethernet
300 second input rate: 216 bits/sec, 0 packets/sec, 0.00% utilization
300 second output rate: 1416 bits/sec, 1 packets/sec, 0.00% utilization
10 packets input, 964 bytes, 0 no buffer
Received 0 broadcasts, 10 multicasts, 0 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
64 packets output, 6290 bytes, 0 underruns
Transmitted 20 broadcasts, 44 multicasts, 0 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Egress queues:
Queue counters Queued packets Dropped Packets
0 68 0
1 0 0
2 0 0
3 0 0
4 0 0
5 0 0
6 0 0
7 0 0
Code:
tim@fileserver:~$ ethtool enp98s0
Settings for enp98s0:
Supported ports: [ FIBRE ]
Supported link modes: 40000baseCR4/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 40000baseCR4/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 40000Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000007 (7)
drv probe link
Link detected: yesI don't really know what's going on and I don't know how to articulate it.
What was in the machine before was a 10G SFP+ NIC. It was enp98s0. So I put this thing in (XL710) and it takes the same name. I've since put in a different 10G NIC and it took the name of enp129s0. All is fine and works there. Got its MAC address in my router for a static lease (192.168.1.2 is the IP of the machine I desire). When I mess around with this XL710 on enp98s0 and I go to kill it with ifdown, it says "DHCPRELEASE of 192.168.1.2 on enp98s0 to 192.168.1.1 port 67 (xid=0x7d5d72e3)" This is after assigning it a static IP in /etc/network/interfaces. I really don't get what's going on, and I am about to just wipe the OS install (which I've had maintained for like 14 years now, and would be a HUGE pain in the butt to start over).
...I don't really know what's going on and I don't know how to articulate it.
STOP! Take a deep breath.
I reviewed your previous posts. I'd like to get some clarity first. I'm going to give you some suggestions in a bit so bear with me.
Your interface output looks "fine" even the small number of giants (hoping they're just 1522 and not something else - which could be coming form something else on your network). I'm going with the test on the 1/2/6 was simply brief as the uptime on it is short. - please confirm
based on the show int I'd say both 40gbe ports are fine.
for each interface test did you have good link / status "blinky lights" on your NIC?
You previously reported you had no electrical activity on the bottom port - is that still the case?
STOP again! Please don't wipe your 14 year maintained system. If it has been maintained that long I'd either consider it "prod" or of significant sentimental value. Put it back on your network the way it was and leave it alone until you've finished testing the switch.What was in the machine before was a 10G SFP+ NIC. It was enp98s0. So I put this thing in (XL710) and it takes the same name. I've since put in a different 10G NIC and it took the name of enp129s0. All is fine and works there. Got its MAC address in my router for a static lease (192.168.1.2 is the IP of the machine I desire). When I mess around with this XL710 on enp98s0 and I go to kill it with ifdown, it says "DHCPRELEASE of 192.168.1.2 on enp98s0 to 192.168.1.1 port 67 (xid=0x7d5d72e3)" This is after assigning it a static IP in /etc/network/interfaces. I really don't get what's going
on, and I am about to just wipe the OS install (which I've had maintained for like 14 years now, and would be a HUGE pain in the butt to start over).
You are experimenting and troubleshooting - use something else for this process.
Beg, borrow, steal another system. Throw an OS on it (clean install) and let's troubleshoot the rest of the ports on your switch. yeah?
seriously. Don't EFF around with the system you've been using. Use something else to finish testing out the switch.
Next, I saw a comment that made me think you want to rely on DHCP for testing. Bad idea right now.
80% of most network issues are physical layer.
If you rely on DHCP you may question whether DHCP is behaving or you have something else going on. Remove DHCP from the equation. Use static IP's for the remainder of the testing and on a CLEAN system.
that way you can focus on do I have a bad port, do i have a bad cable.
simplify your troubleshooting by simplifying the number of variables in any given test.
Hi all,
Hoping you might be able to offer some guidance on moving from L2 to L3 code (I'm doing this really just as a learning exercise, actually do my routing in a VM).
I have a batch of VLANs, with a separate management VLAN (VLAN 10). That VLAN had the management IP on it for inband access, and I also have a separate physical switch for the mgmt network, cabled to the OOB management port on the back.
I've just moved to running the routing l3 image code and figured I'd learn about setting up Multi-VRF and also management-vrf.
I setup a vrf (MGMT), and a router-interface ve 10 on VLAN 10. The router-interface ve 10, is forwarding into vrf MGMT. All is well thus far.
I then applied
MY QUESTION
The OOB Management port, does not report itself as belonging to my newly defined management vrf (MGMT). I thought that was part of what the 'management-vrf MGMT' command was meant to do, i.e. forward the OOB physical management ethernet interface in to whatever VRF you had defined as the
Basically everything below points to my inband ve 10 interface being in the managment vrf correctly, but not the OOB interface. How do I get the OOB to forward into the defined managment-vrf?
show who[/B]
^^^ That particular SSH session is to the IP address that is configured on the OOB management port, and as you can see, it reports it's in the default-vrf.
sh ip int
show vrf MGMT
Hoping you might be able to offer some guidance on moving from L2 to L3 code (I'm doing this really just as a learning exercise, actually do my routing in a VM).
I have a batch of VLANs, with a separate management VLAN (VLAN 10). That VLAN had the management IP on it for inband access, and I also have a separate physical switch for the mgmt network, cabled to the OOB management port on the back.
I've just moved to running the routing l3 image code and figured I'd learn about setting up Multi-VRF and also management-vrf.
I setup a vrf (MGMT), and a router-interface ve 10 on VLAN 10. The router-interface ve 10, is forwarding into vrf MGMT. All is well thus far.
I then applied
management-vrf MGMT which was accepted fine, and when I check with 'show management-vrf' it does indeed appear to have worked.MY QUESTION
The OOB Management port, does not report itself as belonging to my newly defined management vrf (MGMT). I thought that was part of what the 'management-vrf MGMT' command was meant to do, i.e. forward the OOB physical management ethernet interface in to whatever VRF you had defined as the
management-[B]vrf?Basically everything below points to my inband ve 10 interface being in the managment vrf correctly, but not the OOB interface. How do I get the OOB to forward into the defined managment-vrf?
show who[/B]
Code:
SSH connections (inbound):
1 established, client ip address 192.168.1.50, server hostkey RSA, user is USER, privilege super-user, in config mode
using vrf default-vrf.
you are connecting to this session
10 second(s) in idlesh ip int
Code:
sh ip int
Interface IP-Address OK? Method Status Protocol VRF
Eth mgmt1 192.168.1.171 YES manual up up default-vrf
Ve 10 192.168.1.173 YES manual up up MGMT
Code:
VRF MGMT, default RD 4:10, Table ID 1
Configured as management-vrf
IP Router-Id: 10.10.10.10
Interfaces:
ve10
Address Family IPv4
Max Routes: 200
Number of Unicast Routes: 1A seperate question:
For a management VRF, is it better practice to put an IP address on a loopback and forward that to the VRF, rather than a VE?
I ask because I have seen posts elsewhere, with people implying it's somehow better, but I fail to see how in any practical sense. Different if you are using it for keeping a routing protocol up or something I guess?
For a management VRF, is it better practice to put an IP address on a loopback and forward that to the VRF, rather than a VE?
I ask because I have seen posts elsewhere, with people implying it's somehow better, but I fail to see how in any practical sense. Different if you are using it for keeping a routing protocol up or something I guess?
When I tell it to use a static IP is when I can actually form a connection with it, but it's then doing all of those RX errors. And using a static IP is also when it says that thing with the old IP address and DHCP when I go to ifdown the connection. I am going to force it to use the old "eth" names and do some more poking. Later I will stick the card in another server I just got and installed 22.04 onto. Honestly, the 14 year old install has been a pain when I've gone and upgraded it. It's pretty janky at this point, which is probably why I'm having so many issues. I will report back some stuff later. Thank you....
STOP! Take a deep breath.
I reviewed your previous posts. I'd like to get some clarity first. I'm going to give you some suggestions in a bit so bear with me.
Your interface output looks "fine" even the small number of giants (hoping they're just 1522 and not something else - which could be coming form something else on your network). I'm going with the test on the 1/2/6 was simply brief as the uptime on it is short. - please confirm
based on the show int I'd say both 40gbe ports are fine.
for each interface test did you have good link / status "blinky lights" on your NIC?
You previously reported you had no electrical activity on the bottom port - is that still the case?
STOP again! Please don't wipe your 14 year maintained system. If it has been maintained that long I'd either consider it "prod" or of significant sentimental value. Put it back on your network the way it was and leave it alone until you've finished testing the switch.
You are experimenting and troubleshooting - use something else for this process.
Beg, borrow, steal another system. Throw an OS on it (clean install) and let's troubleshoot the rest of the ports on your switch. yeah?
seriously. Don't EFF around with the system you've been using. Use something else to finish testing out the switch.
Next, I saw a comment that made me think you want to rely on DHCP for testing. Bad idea right now.
80% of most network issues are physical layer.
If you rely on DHCP you may question whether DHCP is behaving or you have something else going on. Remove DHCP from the equation. Use static IP's for the remainder of the testing and on a CLEAN system.
that way you can focus on do I have a bad port, do i have a bad cable.
simplify your troubleshooting by simplifying the number of variables in any given test.
this. Makes me think you may have a conflict on your network with your static or some other thing unrelated to the switch (L2).When I tell it to use a static IP is when I can actually form a connection with it, but it's then doing all of those RX errors. And using a static IP is also when it says that thing with the old IP address and DHCP when I go to ifdown the connection. I am going to force it to use the old "eth" names and do some more poking.
yep.Later I will stick the card in another server I just got and installed 22.04 onto. Honestly, the 14 year old install has been a pain when I've gone and upgraded it. It's pretty janky at this point, which is probably why I'm having so many issues. I will report back some stuff later. Thank you.
please do report back as to whether the blinkies were working correctly on your NIC when connected to BOTH 40Gbe interfaces on the switch.
Changed the naming to eth*. No change. I don't understand why, when I use a static IP address (under /etc/network/interfaces) and I go to ifdown it, it mentions releasing the old IP address of 192.168.1.2. The static IP I'm assigning it is 192.168.1.17. When I do an ifconfig, I get something like the following:this. Makes me think you may have a conflict on your network with your static or some other thing unrelated to the switch (L2).
yep.
please do report back as to whether the blinkies were working correctly on your NIC when connected to BOTH 40Gbe interfaces on the switch.
Code:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.17 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::3efd:feff:feb2:cd30 prefixlen 64 scopeid 0x20<link>
ether 3c:fd:fe:b2:cd:30 txqueuelen 1000 (Ethernet)
RX packets 3392 bytes 504447 (504.4 KB)
RX errors 3819 dropped 0 overruns 0 frame 3819
TX packets 5184 bytes 637121 (637.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0This card acts the same in the other server. Try to set a static address, mentions the old one (192.168.1.3 on this machine) and some DHCP nonsense while killing it with ifdown. Won't DHCP, and RX errors out the wazoo with a static IP.
And yeah, both ports on the switch work. No idea why they do now, but I feel like a liar!
And yeah, both ports on the switch work. No idea why they do now, but I feel like a liar!
hi, can now access the web portal, and things connected to the switch now work(thanks )
can't get my 2nd router which is connected to the switch icx6450 (which is connection to the 1st router ) to connect to the internet though i still can do dns look ip but can't access any websites including the admin page of router one
Current configuration:
!
ver 08.0.30qT313
!
stack unit 1
module 1 icx6450-24-port-management-module
module 2 icx6450-sfp-plus-4port-40g-module
!
!
!
!
vlan 1 name DEFAULT-VLAN by port
router-interface ve 1
!
!
!
!
!
aaa authentication snmp-server default local
aaa authentication web-server default local
aaa authentication enable default local
aaa authentication login default local
hostname icx6450
ip dhcp-client disable
ip dns domain-list my-lan.ovh
ip dns server-address 10.0.0.1
ip route 0.0.0.0/0 10.0.0.1
!
no telnet server
username root password .....
!
ntp
server 129.250.35.251
server 85.199.214.99
server 185.103.117.60
server 90.155.73.34
server 109.74.206.120
server 103.214.44.30
server 162.159.200.1
server 193.47.147.20
!
router rip
neighbor 1 permit 10.0.0.2
learn-default
redistribute connected metric 1
redistribute static metric 1
redistribute bgp metric 1
redistribute ospf metric 1
!
interface ve 1
ip address 10.0.0.4 255.255.254.0
!
end
also any advice on setting up the vlans/ipsubnets please - my setup is below
Router1 <> 6450-switch <> router2
Router1 provides internet and main wifi – all running on vlan 1
Router3 has a VPN running on it, and multiple vlans 1, red, orange and green
6450-switch is running routing mode and has my nas and 6 interfaces spread over 2 severs all running on vlan 1. In addition I want to add the following vlans and/or subnets of /23 size.
For the Dell R710: Green(10.1.0.1/23), Yellow(10.2.0.1/23), Red(10.3.0.1/23)
For the Dell R810: Green(10.4.0.1/23), Yellow(10.5.0.1/23), Red(10.6.0.1/23)
Green has access to the internet and all device on vlan1, Orange has access to internet via VPN and can connect to any device in Orange), Red has no access to internet and can only talk to devices in red.
From reading the manuals think the right approach would be to create 3 vlans and 6 ip subnets (2 on each vlan) with an ip and port assigned to each ip subnet.
can't get my 2nd router which is connected to the switch icx6450 (which is connection to the 1st router ) to connect to the internet though i still can do dns look ip but can't access any websites including the admin page of router one
Current configuration:
!
ver 08.0.30qT313
!
stack unit 1
module 1 icx6450-24-port-management-module
module 2 icx6450-sfp-plus-4port-40g-module
!
!
!
!
vlan 1 name DEFAULT-VLAN by port
router-interface ve 1
!
!
!
!
!
aaa authentication snmp-server default local
aaa authentication web-server default local
aaa authentication enable default local
aaa authentication login default local
hostname icx6450
ip dhcp-client disable
ip dns domain-list my-lan.ovh
ip dns server-address 10.0.0.1
ip route 0.0.0.0/0 10.0.0.1
!
no telnet server
username root password .....
!
ntp
server 129.250.35.251
server 85.199.214.99
server 185.103.117.60
server 90.155.73.34
server 109.74.206.120
server 103.214.44.30
server 162.159.200.1
server 193.47.147.20
!
router rip
neighbor 1 permit 10.0.0.2
learn-default
redistribute connected metric 1
redistribute static metric 1
redistribute bgp metric 1
redistribute ospf metric 1
!
interface ve 1
ip address 10.0.0.4 255.255.254.0
!
end
also any advice on setting up the vlans/ipsubnets please - my setup is below
Router1 <> 6450-switch <> router2
Router1 provides internet and main wifi – all running on vlan 1
Router3 has a VPN running on it, and multiple vlans 1, red, orange and green
6450-switch is running routing mode and has my nas and 6 interfaces spread over 2 severs all running on vlan 1. In addition I want to add the following vlans and/or subnets of /23 size.
For the Dell R710: Green(10.1.0.1/23), Yellow(10.2.0.1/23), Red(10.3.0.1/23)
For the Dell R810: Green(10.4.0.1/23), Yellow(10.5.0.1/23), Red(10.6.0.1/23)
Green has access to the internet and all device on vlan1, Orange has access to internet via VPN and can connect to any device in Orange), Red has no access to internet and can only talk to devices in red.
From reading the manuals think the right approach would be to create 3 vlans and 6 ip subnets (2 on each vlan) with an ip and port assigned to each ip subnet.
@ramicio
dumb question. setting it back to DHCP or with the server assigned to .17 turned off - you can't ping .17 right? just checking. Same thing happen if you pick some other address for a static. one you've tested for no replies before assigning it?
you got some other funk going on in your network.
If it were me I'd at least finish testing the breakout ports (assuming you have a DAC or AOC 40gbe to 10gbe breakout... the breakouts are probably fine but would be ncie to know all the ports are good before your return window closes...
dont' feel like a liar. Having someone else help you - often is nothing more than a different set of eyes giving you a (slightly even) different process which forces you out of behaviors which may have contributed to you false negative testing of the ports. its why we help each other.
besides you re-learned how to pull a config and look at port stats on the switch. sounds like a winner afternoon of network geekdom to me.
dumb question. setting it back to DHCP or with the server assigned to .17 turned off - you can't ping .17 right? just checking. Same thing happen if you pick some other address for a static. one you've tested for no replies before assigning it?
you got some other funk going on in your network.
If it were me I'd at least finish testing the breakout ports (assuming you have a DAC or AOC 40gbe to 10gbe breakout... the breakouts are probably fine but would be ncie to know all the ports are good before your return window closes...
dont' feel like a liar. Having someone else help you - often is nothing more than a different set of eyes giving you a (slightly even) different process which forces you out of behaviors which may have contributed to you false negative testing of the ports. its why we help each other.
besides you re-learned how to pull a config and look at port stats on the switch. sounds like a winner afternoon of network geekdom to me.
If it's set to use DHCP it just hangs on the system looking for a DHCP lease forever and ever. On static it can send and receive pings, but it has no real connectivity. Pings only work within the LAN. It can't get any DNS info for some reason.@ramicio
dumb question. setting it back to DHCP or with the server assigned to .17 turned off - you can't ping .17 right? just checking. Same thing happen if you pick some other address for a static. one you've tested for no replies before assigning it?
you got some other funk going on in your network.
If it were me I'd at least finish testing the breakout ports (assuming you have a DAC or AOC 40gbe to 10gbe breakout... the breakouts are probably fine but would be ncie to know all the ports are good before your return window closes...
dont' feel like a liar. Having someone else help you - often is nothing more than a different set of eyes giving you a (slightly even) different process which forces you out of behaviors which may have contributed to you false negative testing of the ports. its why we help each other.
besides you re-learned how to pull a config and look at port stats on the switch. sounds like a winner afternoon of network geekdom to me.
I really don't think it has anything to do with anything on my network. Why is it these 2 ports with this specific NIC, and I have zero problem with my 10 gig stuff?
I don't have any kind of breakout cable and I don't plan on buying one for any reason.
I need to know if it's the switch, the DAC, or the NIC. How can I determine this? I'm honestly about to just junk it all, because I'm willing to bet it's all a problem with the XL710 and it's probably never going to work, and I refuse to buy a Mellanox or any other brand.
I ran a live Ubuntu Desktop thing. Couldn't do anything meaningful with that, but it did pull an address with DHCP and had some activity. But it was very flaky. Installed Windows, because the live Ubuntu thing was basically unusable. Got an IP address but can't do anything with the connection but ping. What information would one need from me at this point? Router is some older ASUS thing with DD-WRT installed. That's plugged into port 1 (RJ45) on this switch. No other devices on my network have a problem, it's only this 40gig nonsense.
the fact that you can ping the local lan with a static IP leads me to believe that dhcp packets aren't making it. ping with default is a very small packet. Have you looked at the interface statistics to see if there are errors (incrementing) on the connected switch port?If it's set to use DHCP it just hangs on the system looking for a DHCP lease forever and ever. On static it can send and receive pings, but it has no real connectivity. Pings only work within the LAN. It can't get any DNS info for some reason.
I really don't think it has anything to do with anything on my network. Why is it these 2 ports with this specific NIC, and I have zero problem with my 10 gig stuff?
I don't have any kind of breakout cable and I don't plan on buying one for any reason.
I need to know if it's the switch, the DAC, or the NIC. How can I determine this? I'm honestly about to just junk it all, because I'm willing to bet it's all a problem with the XL710 and it's probably never going to work, and I refuse to buy a Mellanox or any other brand.
Have you tried traceroute to a known ip - say 8.8.8.8 - again very small packets, would not involve dns if you disable ip to name resolution (traceroute option) it will even go relatively quickly. If it goes slowly then I'm inclined to believe packet corruption is occurring.
typically when I see a problem like this I suspect the cable first, then the nic, then the switch port. Just my experience is all that leads me to things in that order. not saying its right or wrong to look at it other ways. If you have another DAC, AOC, set of optics with patch, you may want to try that. If that doesn't work and you have another nic then try that. You may have to build a matrix of tests and results to ultimately weed out what is wrong. could be the switch too, could be the port on the switch, the nic, the DAC all of the above in combination. Key thing here is change 1 thing at a time and try again. record the result.
regarding your last post - it is very clear you are quite frustrated - and I say this with all due respect (and not knowing what other efforts and time have been spent, nor your skill, knowledge level or experience history)
This may not be the best solution set for you. Only you can decide if the return on your investment - time and money - is worth the return that you will get from making this work. for some people its the end result, for some folks its the end result as well as what they learned getting there. I don't know the answer for you. only you do.
I'm a hobbyist, so I don't have extra stuff, and won't have extra stuff.the fact that you can ping the local lan with a static IP leads me to believe that dhcp packets aren't making it. ping with default is a very small packet. Have you looked at the interface statistics to see if there are errors (incrementing) on the connected switch port?
Have you tried traceroute to a known ip - say 8.8.8.8 - again very small packets, would not involve dns if you disable ip to name resolution (traceroute option) it will even go relatively quickly. If it goes slowly then I'm inclined to believe packet corruption is occurring.
typically when I see a problem like this I suspect the cable first, then the nic, then the switch port. Just my experience is all that leads me to things in that order. not saying its right or wrong to look at it other ways. If you have another DAC, AOC, set of optics with patch, you may want to try that. If that doesn't work and you have another nic then try that. You may have to build a matrix of tests and results to ultimately weed out what is wrong. could be the switch too, could be the port on the switch, the nic, the DAC all of the above in combination. Key thing here is change 1 thing at a time and try again. record the result.
regarding your last post - it is very clear you are quite frustrated - and I say this with all due respect (and not knowing what other efforts and time have been spent, nor your skill, knowledge level or experience history)
This may not be the best solution set for you. Only you can decide if the return on your investment - time and money - is worth the return that you will get from making this work. for some people its the end result, for some folks its the end result as well as what they learned getting there. I don't know the answer for you. only you do.
Tracert to 8.8.8.8 is nothing but requests timed out.
I guess Monday I will have to get ahold of FS and try to get another cable. See if they know what would be the best bet for a DAC (if it needs to be programmed. For Intel on one end and Brocade on the other?)
No idea what to look for regarding looking at the interface statistics to see if there are errors on the connected switch port.