can't get sites to communicate

The first thing i see is the ESNG router needs a route back to BRDG. ESNG has no clue how to return traffic to BRDG.

The static routes seem fine but the router(s) in the middle need to know about these networks (10.24.2.0/24 and 172.16.0.0/16) as well otherwise it will simply drop the packets or forward them to its own default gateway, wherever that might be.

Are you running RIP / OSPF or how are these routes to be advertised to the inbetween router(s)?

thatguy, I didnt include the other static routes. But ESNG has full connectivity back to BRDG. THe route looks like this  10.24.0.0  255.255.0.0   10..240.1.2

grimkin, since we do not own the router(s) in the middle, I relied on our service provider to enter the proper static routes. This is what they entered:

172.16.0.0   255.255.0.0    10.24.1.1   and it is not working

any ideas?

Thanks

here is the tracert. Keeps bouncing back and forth
scad.JPG

Your ESNG server is pointing a route to the 172 network back to 10.240.2.2.

Doulbe check your routes on that router for errors or post your "sh ip route" and we will take a look at it.

The ESNG router has this:

172.16.0.0   255.255.0.0   10.24.1.2
10.24.0.0 255.255.0.0   10.240.1.2

that traceroute is from BRDG by the way

Those routes are correct but you are having a routing loop (hence the traceroute going back and forth). Please post your "Sh ip route" or a cleaned up "sh run"

the routers we control for this network, are actually not cisco. They are verilink wansuite (aka big POS).  The routers in between are controlled by our service provider

Since the traceroute keep bouncing back and forth on ESNG this is were i think the problem is. Do you control this router?

If so could you post something showing all your routes?

the ESNG router we own . However, isn't this bouncing between the router in the middle and BRDG?  The address bouncing in the tracert is 10.240 , not 10.24

Oh yes you are correct, My mistake.

Yeah your traceroute (and traffic) is making it to the router in the middle. But it is bouncing it back. Do you control this router? This is the router with the routing loop.

Run a traceroute from the 172 network to the BRDG network 10.24 to verify this is were your issue is.

Yes I have our provider looking at this.   We do not manage that router

To verify this is were the trouble is Run a traceroute from the 172 network to the BRDG network 10.24

Tracing route to 10.24.2.102
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  172.16.14.1
  2     1 ms     1 ms     1 ms  172.17.1.31
  3     1 ms     1 ms     2 ms  [10.24.1.1
  4     8 ms     7 ms     7 ms  10.240.1.2
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *

Here are several things I am seeing:

Routes on ESNG:

172.16.0.0   255.255.0.0   10.24.1.2 <-this looks good
10.24.0.0 255.255.0.0   10.240.1.2 < --points both 10.24.1 and .2 to the 10.240.1.2 router which is the ISP router. Traffic can not get to the 10.24.1 network because it is sent back to the ISP.

This is an issue since the two subnets are on either side of the router. So split that route into two seperate routes on ESNG.

10.24.1.0 255.255.255.0   10.24.1.2 <-points routes to your f/w
10.24.2.0 255.255.255.0   10.240.1.2 <-points routes to the ISP

ISP route (per earlier post):

172.16.0.0   255.255.0.0    10.24.1.1   and it is not working

This route is pointing to the wrong interface on ESNG. Your ISP most likley has no idea how to get to this subnet. You need to have them change the route to the next hop address.

172.16.0.0   255.255.0.0    10.2401.1 <--this will point all traffic for this network to ESNG

Also your ISP will need a route to point traffic to the 10.24.2 network at your remote location.

10.24.2.0   255.255.255.0    10.240.2.1

This should correct your routing issues.