2

Diagram:

enter image description here

Here's the simplest way I know how to explain how the internal networking of this Dell VRTX works.

So, you have your 4 blades and your network switch module that have integrated remote management controllers, for the blades it's iDRAC and for the switch it's an internal OOB port that I can't actually physically plug into anything else.

According to Dell documentation these ports communicate with the CMC module of the enclosure. So technically the CMC is like a really dumb switch in some sense.

On my RT-N66U, I created 2 separate VLANs to segment the management interfaces and the rest of the interfaces of the switch and gave said interfaces 10.1.0.0 /24 addresses for management and a simple 169.254.255.1-2 /30 address set just to bridge the router and the switch module.

In the diagram I have the management interfaces set on a the range from .2 to .7, with a default gateway of 10.1.0.1. These all work fine.

However, the weird behavior is when I try to do static routes on the switch module.

The switch module supports layer 3 static routing. One primary issue is that in the Dell VRTX CMC, to access the web GUI I can set the IP for the OOB interface on the switch module. In this instance, it would show as 10.1.0.3 with a default gateway of 10.1.0.1. The odd thing is that for the switch, it sets the "ip default-gateway" property to this value and all of traffic ends up defaulting to this route which I don't necessarily want.

What i've tried:

  • I remove the default-gateway and I add my own static routes. Problem is, 10.1.0.3 should technically be a directly connected interface so I can't really route back to 10.1.0.0 with any gateway that makes sense.
  • If I do a default route of 0.0.0.0 0.0.0.0 10.1.0.1 which is the equivalent of a default gateway AND I add my other static routes for my VMs to get back out to my other networks, I am unable to access the web interface of the switch module for some reason. So here's a quick sample of what some configs look like and the behavior:

Able to access web GUI but cannot ping/access devices in 10.2.0.0 subnet


show run
...
ip default-gateway 10.1.0.1
...

show ip route
...
S   0.0.0.0/0 [1/1] via 10.1.0.1, 00:01:15, oob
C   10.1.0.0/24 is directly connected, oob
C   10.2.0.0/24 is directly connected, vlan 3
C   169.254.255.0/30 is directly connected, gi0/1
...

Add in a static route, lose access to web GUI but can ping/access devices in 10.2.0.0 subnet


show run
...
ip default-gateway 10.1.0.1
ip route 192.168.1.0 /24 169.254.255.1
...

show ip route
...
S   0.0.0.0/0 [1/1] via 10.1.0.1, 00:04:32, oob
C   10.1.0.0/24 is directly connected, oob
C   10.2.0.0/24 is directly connected, vlan 3
C   169.254.255.0/30 is directly connected, gi0/1
S   192.168.1.0/24 [1/1] via 169.254.255.1, 00:01:32, gi0/1
...

Lastly, if I remove the ip default-gateway and add my own static routes, the behavior is essentially the same as the first one above.

This embedded / internal port sharing setup is weird to me and I'm just wondering if I'm missing something stupid simple here. I've done a similar setup on a Cisco 3560E and Quanta LB6M and had no issues at all.

Thanks.

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 25 '18 at 8:36
1

There are some problems with your use of the IPv4 link-local addressing:

  • One problem is that you are trying to route with the addressing in the 169.254.0.0/16 network, and you are not allowed to route using those addresses.

An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP Requests for addresses in the 169.254/16 prefix. A router may of course answer ARP Requests for one or more IPv4 Link-Local address(es) that it has legitimately claimed for its own use according to the claim-and- defend protocol described in this document.

  • Another problem is that you have subnetted the 169.254.0.0/16 into 169.254.255.0/30, and you are not allowed to subnet the link-local network addressing.

The non-forwarding rule means that hosts may assume that all 169.254/16 destination addresses are "on-link" and directly reachable. The 169.254/16 address prefix MUST NOT be subnetted.

  • Nor are you allowed to manually configure addresses in the 169.254.0.0/16 network.

Administrators wishing to configure their own local addresses (using manual configuration, a DHCP server, or any other mechanism not described in this document) should use one of the existing private address prefixes [RFC1918], not the 169.254/16 prefix.

RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses explains the reasons for, and how to use, the IPv4 link-local addressing:

Until you fix those problems, you have no way to know if there is any other problem with your configuration. Simply readdress the link-local addressing to an allowed address range.

  • I've gone ahead and changed that interface to 10.100.10.1 and .2 for the end to end interfaces. – That Feel Jun 1 '18 at 14:53
  • We need to see what you have now. You should also include the full network device configurations. – Ron Maupin Jun 1 '18 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.