• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Routing question (img attached)

D

dawks

Diamond Member
Bit of a networking newb here.. Our business runs a network with two subnets, 172.25.200.x and 172.25.211.x.

We connect to another organization that runs on the subnet 172.25.0.x

172.25.200.x can connect to 172.25.0.x just fine
172.25.211.x is attempting to connect to 172.25.0.x but cannot
172.25.211.x connects through the 172.25.200.x network.

The default gateway of 172.25.211.7 can ping 172.25.0.25 just fine, but the computers in that subnet cannot.

I've tried creating a route on the 172.25.211.7 gateway to point to 172.25.0.25 but still doesnt work for clients..

I dont know what I'm missing since the router can ping the 172.25.0.x subnet but the clients on that router cannot.


Thanks
 
Last edited:
What's the subnet mask set to for the clients of 172.25.211.25? Done a tracert from a client to 172.25.200.25 and 172.25.0.25, to see what's going on from that perspective?
 
You are missing some IP addresses in there. Routing requires at least 2 ip address.

172.25.211.7 must have an interface on 172.25.200.x.
172.25.200.1 must have an interface on 172.25.0.x

The way you drew it makes me think there is a route that is missing somewhere in the chain. The information that GeekDrew requested will help determine this. It also may be handy to post your routing table and which protocol you are using. BGP / OSPF / statics / etc

My guess is 172.25.211.7 has no idea how to get to 172.25.0.x or 172.25.200.1 has no idea how to get to 172.25.211.25. (I assume all /24 subnets until more info is posted)
 
GeekDrew said:
What's the subnet mask set to for the clients of 172.25.211.25? Done a tracert from a client to 172.25.200.25 and 172.25.0.25, to see what's going on from that perspective?
Click to expand...

The subnet mask is 255.255.255.0.

A 172.25.200.25 client can tracert right to the proper server through the 172.25.200.1 gateway.
A 172.25.211.25 client goes to 172.25.200.4, then stops...

imagoon said:
You are missing some IP addresses in there. Routing requires at least 2 ip address.

172.25.211.7 must have an interface on 172.25.200.x.
172.25.200.1 must have an interface on 172.25.0.x

The way you drew it makes me think there is a route that is missing somewhere in the chain. The information that GeekDrew requested will help determine this. It also may be handy to post your routing table and which protocol you are using. BGP / OSPF / statics / etc

My guess is 172.25.211.7 has no idea how to get to 172.25.0.x or 172.25.200.1 has no idea how to get to 172.25.211.25. (I assume all /24 subnets until more info is posted)
Click to expand...

I should clarify, we are using HP Procurve 2626 Switches that I am adding static routes too.
172.25.211.7 has an interface on 172.25.200.x
172.25.200.1 has an interface on 172.25.0.x

172.25.200.1 is a box controlled by the organization we are connecting to (172.25.0.x) that I have no access too so I'm hoping thats not the issue.

I thought it might be the problem that 172.25.211.7 doesn't know how to get to 172.25.0.x so thats where I tried adding a route, but it itself can ping 172.25.0.25. The clients connected to it, using it (172.25.211.7) as a gateway cannot ping 172.25.0.25.
I also suspected that 172.25.0.25 wasn't able to find 172.25.211.x but 172.25.211.7 can successfully ping 172.25.0.25 so the packets are finding their way back.

This is on 172.25.200.4 and clients using it as their default gateway can reach 172.25.0.x just fine.
ip route 172.25.0.0 255.255.192.0 172.25.200.1

This is on 172.25.211.7 and it can reach 172.25.0.x fine, however clients using it as their gateway CANNOT ping 172.25.0.x
ip route 172.25.0.0 255.255.192.0 172.25.200.1

I guess the thing thats throwing me off right now is that the default gateway of 172.25.211.7 CAN ping the target of 172.25.0.25, but the clients connected to it cannot.

Hope this clarifies a little bit.. 🙂 Thanks again!
 
dawks said:
The subnet mask is 255.255.255.0.

A 172.25.200.25 client can tracert right to the proper server through the 172.25.200.1 gateway.
A 172.25.211.25 client goes to 172.25.200.4, then stops...



I should clarify, we are using HP Procurve 2626 Switches that I am adding static routes too.
172.25.211.7 has an interface on 172.25.200.x
172.25.200.1 has an interface on 172.25.0.x

172.25.200.1 is a box controlled by the organization we are connecting to (172.25.0.x) that I have no access too so I'm hoping thats not the issue.

I thought it might be the problem that 172.25.211.7 doesn't know how to get to 172.25.0.x so thats where I tried adding a route, but it itself can ping 172.25.0.25. The clients connected to it, using it (172.25.211.7) as a gateway cannot ping 172.25.0.25.
I also suspected that 172.25.0.25 wasn't able to find 172.25.211.x but 172.25.211.7 can successfully ping 172.25.0.25 so the packets are finding their way back.

This is on 172.25.200.4 and clients using it as their default gateway can reach 172.25.0.x just fine.
ip route 172.25.0.0 255.255.192.0 172.25.200.1

This is on 172.25.211.7 and it can reach 172.25.0.x fine, however clients using it as their gateway CANNOT ping 172.25.0.x
ip route 172.25.0.0 255.255.192.0 172.25.200.1

I guess the thing thats throwing me off right now is that the default gateway of 172.25.211.7 CAN ping the target of 172.25.0.25, but the clients connected to it cannot.

Hope this clarifies a little bit.. 🙂 Thanks again!
Click to expand...

EDIT thinking I know i did something wrong here

From that I think your side is ok. The reason 172.25.211.7 can likely ping 172.25.0.25 is because it has and interface on 172.25.200.x and 172.25.200.1 has 172.25.0.1.

For example only:
Say 172.25.211.7 has 172.25.200.3 as it's other interface.
Ping goes out 172.25.200.3 -> 172.25.200.1 -> 10.25.0.1 -> 172.25.0.25
ICMP reply 172.25.0.25 -> 172.25.0.1 -> 172.25.200.1 -> 172.25.200.3

So that device can ping it fine. In router/switches there is often a command to force a ping out a certain interface. Likely that ping will fail because the origination will look like this:

ping 172.25.211.7 (-> 172.25.211.7) -> 172.25.200.3 -> 172.25.200.1 -> 172.25.0.1 -> 172.25.0.25
ICMP reply 172.25.0.25 -> 172.25.0.1 -> 172.25.200.1 -> 172.25.200.3 -> 172.25.211.7

Note the extra steps. The parentheses are there to indicate that even though the ping went out 172.25.211.7 it technically "comes back in" there as far as routing is concerned because it is the gateway.

Odds are this is happening then:

ICMP reply 172.25.0.25 -> 172.25.0.1 (who? I don't have a route to that network)-> 0.0.0.0 (next router who?) -> 0.0.0.0 until the TTL times out or is filtered since it is a private IP range. Where 0.0.0.0 is the gateway of last resort.

Or the subnets are incorrect in the 172.25.200.1 router.

----EDIT----

172.25.0.0/18 is rather "odd" subnet to use... 4 networks with a range of 64 so...

172.0.0.0 172.63.255.255
172.64.0.0 172.127.255.255
172.128.0.0 172.191.255.255
172.192.0.0 172.255.255.255

You may want to ask the remote guys if they have 172.192.0.0/18 routed back to your router or if it is 172.25.200.0/24 and 172.25.211.0/24

172.192.0.0/18 of course is easiest for them as it makes 172.25.200.1 handle all of your routing. Otherwise they need to add all of your class C's.
 
Last edited:
You must log in or register to reply here.

TRENDING THREADS

Back
Top