Routing - Gateway IP the same as the network address?

Routing - Gateway IP the same as the network address?

Author
Discussion

Durzel

Original Poster:

12,430 posts

174 months

Wednesday 22nd November 2023
quotequote all
I feel like I'm going mad and starting to doubt myself...

I've got a Cisco 800 series router connected to a Technicolor DGA4134 router that was provided preconfigured by our broadband supplier. I've been trying to replace the Cisco 800 with a beefier ISR4451 router, in readiness for a leased line install, but I'm hitting a brick wall. I can't get Internet access to the new router or anything behind it.

We have a single routed subnet of 1.1.1.136/29 (first three octets obviously redacted). The gateway IP we were provided is 1.1.1.136. Our Cisco router outside interface is on 1.1.1.137 and is pointing to .136 as the next hop for the internet.

Until I tried to get the new router working I didn't think anything was wrong with this, and hadn't put too much thought into it. Everything was working, the Cisco was doing NAT for inside hosts, everyone could access the internet - job done.

After doing some more digging, and trying to plug a laptop into the Cisco and setting its IP as the gateway - to see if the Cisco could ping it - and failing, with Windows telling me that .136 was an invalid IP (all host bits are zero)... it occured to me that this Technicolor router might be misconfigured.....



So, resident IT brain trust..

1) is the Technicolor configured incorrectly? Is it possible to have a gateway IP be the same as the network address?
2) Why does my current Cisco 800 series accept it? I'm using the same subnet (.248) on the VLAN, so technically there's no reason it should work?

Thanks in advance!

Edited by Durzel on Wednesday 22 November 17:28

anonymous-user

60 months

Wednesday 22nd November 2023
quotequote all
What are you trying to achieve? Assuming your Technicolor is performing NAT, I would expect your internal address pool to be something like 192.168.0.1 - 254. Look at the DHCP settings to see what it’s dishing out. Then make sure your new router is configured in the same address range and plug it into one of the LAN ports and off you go. When I did this years ago the Cisco switch I used needed to be configured with a VLAN before it would do anything. It’s probably simpler now and almost certainly not as difficult as you appear to be making it.

markiii

3,790 posts

200 months

Wednesday 22nd November 2023
quotequote all
I'm not entirely sure what your asking but the gateway address will be the internal network address of the gateway router

so yes sort of

Durzel

Original Poster:

12,430 posts

174 months

Wednesday 22nd November 2023
quotequote all
Technicolor isn't doing NAT or DHCP.

Cisco is doing NAT (and an internal server is doing DHCP) for an internal 10.1.0.0/24 network.

The "routed subnet" in the image above is an actual public IP range, if it matters. it's what is seen on the internet when I go to www.whatsmyip.org from an internal host currently (on the existing Cisco router).

somouk

1,425 posts

204 months

Wednesday 22nd November 2023
quotequote all
So what you need to consider is if the upstream device is mac address locked to stop you changing kit over, might be worth confirming that.

From a basic networking perspective, you just need to make sure you have the same IP on the external interface, connect something to an internal interface and then SSH on to the router. Ping from the router to the gateway, if it can't get there then nothing routing through it can as it will logically pick the interface on the right subnet.

Durzel

Original Poster:

12,430 posts

174 months

Wednesday 22nd November 2023
quotequote all
I managed to fix it by changing the Technicolor gateway address to. 137 and bumping the Cisco interface address to .138, with a corresponding default route change.

I did also discover that I had a overly restrictive ZBFW setup, so inside hosts still couldn’t ping or reach anything externally, but after I changed the gateway & Cisco IP I could at least ping Internet things from the router whereas I couldn’t before.

Also found out that the Technicolor is unmanaged (despite being preconfigured) so I might just bin it off and install a NIM-VAM card instead and handle the SOGEA connection myself.

Thanks for the help. smile

theboss

7,083 posts

225 months

Saturday 25th November 2023
quotequote all
You figured it out correctly, the first IP identifies the subnet and is unusable. It should never have been set on the ISP router.

The remaining 5 IP’s are yours to use, the 6th and last is the broadcast address which again is unusable.

You managed to change the ISP router config - did they leave it unsecured / default password or did you reset it? If this is from a LL provider it doesn’t instil much confidence. Usually when they supply a router for the customer premises its a business grade device which is managed by them and you wouldn’t be able to logon to it.

If you do remove it be aware you’ll need to know what their wan-side routing config looks like in order to replicate it on your own device. It won’t be comparable to replacing a broadband router in most cases.

Durzel

Original Poster:

12,430 posts

174 months

Saturday 25th November 2023
quotequote all
They provided me with the admin login to it. I was led to believe it was a managed service, but as it turns out - it isn’t. It’s just a piece of equipment they provided and apparently don’t maintain or even have access to themselves.

What confused me greatly, and still does, is why the Cisco 800 series router we were using worked with the original configuration. The only real difference between the two routers is that on the 800 series one the connection to the ISP router was on a layer 2 port, whereas on the ISR router it’s layer 3.

Appreciate the heads up about the WAN side. Now that I have access I can see all of the config (minus the password, but I think I can get that from the ISP). I must admit I’m a bit old school when it comes to this stuff, I do everything via CLI, don’t like “consumer style” GUIs, etc.