• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 552
  • Last Modified:

Static routing IP across a frame-relay

I have an issue where I am forced to use a T1 frame-relay to support a connection to a remote site.
This frame relay connection has three DLCI's on each end, and is indicating that the T1 and frame
relay is operational (LMI is up and transmitting and receiving).

On one side I have a Cisco 3925 router and on the other a Garretcom Magnum DX900 environmentally
hardened router on the remote end (the remote end is in an un-conditioned station with no heating
or cooling).

Requirements have forced the use of static routing, which has caused us some headaches on our end
as it is my belief that we must point a route across the frame-relay as well even though they are
in the same subnet (10.0.0.1/30 on the Cisco side and 10.0.0.2/30 on the Garrettcom end). We are
able to ping each end successfully. However we are not able to ping the far end of frame-relay from
either-end.

So my throught would be to put a static route in place, however the Cisco manuals don't talk about
it. My subnet interface setup is as below:

interface Serial0/0/0:0
 no ip address
 encapsulation frame-relay IETF
 !
!
interface Serial0/0/0:0.201 point-to-point
 description - connects to DLCI 801
 ip address 10.0.1.1 255.255.255.252
 frame-relay interface-dlci 201  
!
interface Serial0/0/0:0.202 point-to-point
 description - connects to DLCI 802
  ip address 10.0.1.5 255.255.255.252
 frame-relay interface-dlci 202  
!
interface Serial0/0/0:0.203 point-to-point
 description - connects to DLCI 803
 ip address 10.0.1.9 255.255.255.252
 frame-relay interface-dlci 203
 
I had entered frame-relay interface-dlci xxx broadcast, where xxx is the dlci number but apparently
it does not put it in the running configuration. However it displays the broadcast on when I run
an show frame-relay lmi command.

On the Garettcom router. The WAN status shows that it is functional and that the LMI is up.

The routing table shows the following:
(DLCI 801 connects to DLCI 201)
Route destination:10.0.1.2
Route mask:255.255.255.255
Next Hop: 172.16.1.5

(DLCI 802 connects to DLCI 202)
Route destination:10.0.1.6
Route mask:255.255.255.255
Next Hop: 172.16.1.14

(DLCI 803 connects to DLCI 203)
Route destination:10.0.1.10
Route mask:255.255.255.255
Next Hop: 172.16.1.22

So there is no way to get
10.0.1.2 to 10.0.1.1
or
10.0.1.6 to 10.0.1.5
or
10.0.1.10 to 10.0.1.9

If I was to enter static routes to cross the frame relay what would they be on each end?
0
fluce
Asked:
fluce
  • 4
  • 3
  • 2
  • +2
2 Solutions
 
Rick_O_ShayCommented:
Since the routers are on the same subnet for the DLCI you should not need a route added for them. However, you would need a static route from each side pointing to the other side LAN network with the remote end as the next hop.
0
 
fluceAuthor Commented:
Would the Cisco side require any other entries on a subinterface as a point-to-point frame relay connection, does Cisco not automatically assume the ip addresses assigned to the frame-relay are part of the same network as frame relay?
0
 
Rick_O_ShayCommented:
Sorry. I don't know the details of how Cisco does it.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
ccie22921Commented:
Since you are using point to point subinterfaces and you have already defined your DLCI all you need to do is verify that the frame DLCIs are mapped to the right interfaces.  So issue the command "show frame map" and hit enter on your Cisco router.  You should see your layer 3 and layer 2 associations as they relate to your frame sub interfaces.  You do not need to create a route for a destination that is in the same subnet.  So if I look at the config on your remote router I notice that the mask they are using is a /32 mask and your Cisco router masks are a /30.  You need to correct the IP subnet address at the remote end to reflect a /30 so you will be able to talk across the cloud.  For instance your
Route destination:10.0.1.2
Route mask:255.255.255.255
should look like
Route destination:10.0.1.2
Route mask:255.255.255.252
 
This should solve your problems.  255.255.255.255 is a host address where as you are using a two host mask on your Cisco side of 255.255.255.252.

Hit me back if I can be of further assistance to you.

0
 
Don JohnstonInstructorCommented:
>We are able to ping each end successfully. However we are not able to ping the far end of frame-relay from
either-end.

I'm not sure I follow... These two statements appear to contradict each other. Please restate what works and what doesn't.

Can you post the output of a "show frame pvc" from the Cisco?


0
 
fluceAuthor Commented:
As requested the show frame-relay pvc. DLCI 203/803 is on order and is not yet functional so it can be disregarded right now.

sh frame-relay pvc

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          2            0            1            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.201

  input pkts 0             output pkts 1434         in bytes 0        
  out bytes 531599         dropped pkts 0           in pkts dropped 0        
  out pkts dropped 0                out bytes dropped 0        
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0        
  out BECN pkts 0          in DE pkts 0             out DE pkts 0        
  out bcast pkts 1422      out bcast bytes 530431    
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 23:42:59, last time pvc status changed 23:41:45
         
DLCI = 202, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.202

  input pkts 0             output pkts 1432         in bytes 0        
  out bytes 531580         dropped pkts 0           in pkts dropped 0        
  out pkts dropped 0                out bytes dropped 0        
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0        
  out BECN pkts 0          in DE pkts 0             out DE pkts 0        
  out bcast pkts 1422      out bcast bytes 530431    
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 23:43:37, last time pvc status changed 23:42:23
         
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0/0:0.203

  input pkts 0             output pkts 0            in bytes 0        
  out bytes 0              dropped pkts 0           in pkts dropped 0        
  out pkts dropped 0                out bytes dropped 0        
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0        
  out BECN pkts 0          in DE pkts 0             out DE pkts 0        
  out bcast pkts 0         out bcast bytes 0        
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 23:43:39, last time pvc status changed 23:43:37

As far as what works and what does not is as follows. We are able to ping up to the DLCI's on each side of frame-relay T1. The frame-relay looks to be up

After reviewing the answers above I went back to the Garrettcom manual on the DX900 software and found a mention that in order to route IP frames out of the W1 port on a frame relay (T1 WAN port), that you need to not only associated the proper DLCI's but enter a next hop IP address outside of the router which would be the IP addresses associated with the Cisco DLCI's. Hopefully it is that easy.
0
 
Don JohnstonInstructorCommented:
>As far as what works and what does not is as follows. We are able to ping up to the DLCI's on each side of frame-relay T1. The frame-relay looks to be up

So once again, what DOESN'T work?

0
 
MoriatoCommented:
From your listing above I see several possible issues. Mind you, I don't know anything about Garettcom but here is what I see as issues.

Your routing table on the Garettcom looks odd. Each of the routes has a mask of 255.255.255.255 which should be 255.255.255.252 or /30. The typical ping from a Cisco uses the IP address of the egress port as the source. In this case, your first PVC (201 to 801) would have a source ip of 10.0.1.1 and a destination of 10.0.1.2.

Based on what I see, your pings from the Cisco would indeed go out to the Garettcom but wouldn't come back (the show frame pvc verifies packets going out but none coming in). Thus, ping would fail. Same problem on the other side except it wouldn't even leave the router. The fact that each route on the Garettcom points to a 172.16.1.x address is odd to since it should have the route for the 10.0.1.x addresses to be the DLCI interfaces and related IPs.

I suspect an issue on the Garettcom. I would check to be sure the IPs are set to 10.0.1.2 255.255.255.252 on each interface. You shouldn't need static routes as they are considered connected networks and should be accessible without adding statics.

On other thing, the 3rd PVC (203 to 803) doesn't appear to be provisioned by the telco (PVC STATUS = DELETED).
0
 
fluceAuthor Commented:
Sorry all, been out and forbaded from working for the holidays.

As far as what is working and what is that on each side we can ping up to the ip address that is assigned to the DLCI but not across.

I attempted to set up a route on the Cisco 3925 side to reach each of the routes on the opposite side of the DLCI but when I did I got an "inconsistent address and mask error".

The command I was attempting to use was:
ip route 172.16.1.5 255.255.255.248 10.0.1.2

the only way I can get a route set is if I use:
ip route 172.16.1.5 255.255.255.255 10.0.1.2

So what am I not getting here as I am getting the equivalent on the Garretcom side as well? The actual ip address I would like to get to is eventually 172.16.1.1. which I can ping from 172.16.1.5.
0
 
Rick_O_ShayCommented:
The ip route command would be:

ip route 172.16.1.0 255.255.255.248 10.0.1.2

to get to the whole subnet.
0
 
fluceAuthor Commented:
The issue turned out to be that the PVC was losing parts of frame when using the Garrettcom, but the telco also ended up tmaking changes at the CO. How the routing info is correct.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 4
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now