Dell N2000: switch will not respond on configured in-band IP

Question

I have an existing switch configuration which works, but is not satisfactory, and I want to switch to a different configuration that seems straightforward but I cannot get to work in production, though my scripts work perfectly in a staging setup here.

We have a rack in a distant DC. We have 2 stacked Dell N2024s, and various servers. Our ISP has supplied us with 2 subnets - one is a /26 range of public IPs, and the other is a /30 range, for routing: they have .165 at their end and we must have .166 at our end which they will use as a gateway. Currently, we have a gateway server which has the .166 allocated to one of its ethernet ports. What I want is to allocate .166 to the switch, so that other devices can stay available even if the gateway host goes down (one of which is the gateway host's iDRAC), essentially using the layer 3 routing features of the switch to make it behave a bit like a router.

I am able to apply updates to both the gateway host and the switch via screen, which I have set up to reboot both GFW and server if I cannot get in after the config updates, which so far has happened 100% of the time. I have however been able to collect, diagnostics, logs and PCAPs of me trying to ping the .166 address.

I have a great deal of data I can share, but I will start with the basics, and perhaps anyone who is willing to help could tell me what needs to be expanded upon. The gist of the process is this:

1. ssh to gateway via switch, on .166.
2. connect to switch CLI via 10.x.x.x network via a different port to the 166 interface.
3. download the modification script to the switch
4. run screen scripts to take down the switch ports to .166 on the gateway, and configure the switch with a new VLAN and give it the .166 ip address.
5. collect diagnostics and capture PCAP.
6. screen script reloads switch and reboots gateway host to get us back to the current setup.

The PCAP shows ping ICMPs arriving at the switch, but it doesn't reply. I can also see the switch sending ARP requests. Here are a few data points concerning the configuration (I have much more detail if needed), with x's to protect public subnets:

ip routing is enabled.

I am setting up the .166 address in vlan 4010.

interface vlan 4010
ip address x.x.8.166 255.255.255.252
exit

Here is the routing table after the configuration changes have been applied:

No default gateway is configured.
C      *10.x.x.x/15 [0/0] directly connected,   Vl999
C      *x.x.8.164/30 [0/0] directly connected,   Vl4010
C      *x.x.13.192/26 [0/0] directly connected,   Vl4000

I am using ACLs to manage inter-VLAN routing. I am currently allowing 'any' ip to access the router subnet from the internet:

ip access-list internet-to-router
permit ip any x.x.8.164 0.0.0.3
exit

route-map internet-routing deny 20
match ip address internet-to-router
exit

Note I am using deny in the route-map to fall back to using the routing table (shown above), but I have also tried permit and that doesn't work either.

I can see that my pings are hitting the route-map:

route-map "internet-routing" deny 20
     Match clauses:
       ip address (access-lists) : internet-to-router
     Set clauses:
Policy routed: 17 packets, 0 bytes

But I don't get any response from .166. Any suggestions would be very welcome.

Answer 1

The only thing that I have spotted at the moment is that you have no default route. Currently you have traffic only destined to x.x.8.164/30 routed out of VLAN 4010.

If this interface goes to the internet I would expect something like the following to be added to tell it that anything not found in the routing table (ie. Internet), send out out the vlan that is connected to your providers IP.

Router(config)#ip route 0.0.0.0 0.0.0.0 x.x.x.165

I hope this helps you on your quest.

SleepyMan