FRAME RELAY NETWORK TOPOLOGY

THERE IS A FR NETWORK HUB AND SPOKE
IN STAR TOPOLOGY. AT HUB ROUTER THERE ARE POINT-TO-POINT SUBINTERFACES TO SPOKE ROUTERS AND STATIC FR MAP ENTRIES ARE PRESENT. tHE SPOKE ROUTERS COMMUNICATE WITH HUB ROUTER BUT DO NOT COMMUNICATE WITH EACH OTHER.
MY QUESTION IS WHAT TO DO FOR COMMUNICATIONS BETWEEN SPOKE ROUTERS,
1. IS ANY MORE DLCI MAY BE REQUIRED BETWEEN SPOKE ROUTERS?.
2.IS MAP STATEMENT REQUIRED, DLCI WITH IP ADDRESS BETWEEN SPOKE ROUTERS ?

Abdul
There are a couple of things in your question that I hope you can clarify and if so we should be able to get good answers to your question.
At one point you describe the topology as hub and spoke and at another point you describe it as star. Most of us understand these to be two different topologies. So is it hub and spoke or is it star?
Many of us understand hub and spoke to be remote routers connected directly to a central (hub) router while a star is remote routers where some of the remote routers have direct connections to other remotes.
Also you say that the hub has point to point subinterfaces and this is generally the best practice for Frame Relay. Then you say that static FR map entries are present. I do not understand this because with p-t-p subinterfaces you do not need FR maps.
Based on what we have so far I would say that these are the answers to your questions:
1. you might choose to add additional DLCIs but they are not required. any spoke should be able to communicate with any spoke by going to the hub and having the hub forward to the other spoke.
2. No map statements should be required. Part of having p-t-p subinterfaces at the hub is that each spoke is an separate subnet. Therefore from any spoke to any other spoke is just going to a different subnet (through the hub) and no map would be required.
If these answers do not satisfy your requirements then perhaps you can clarify the points about your question.
HTH
Rick

Similar Messages

Why is everything on my Frame-relay network working fine with different encapsulation types ?

I have a cisco frame-relay switch with the encapsulation type on IETF.
I have a cisco router with
the encapsulation type on cisco.
Still everything works fine.
How come when it is a different dlsi byte structure ?
Is it because also my switch is a cisco and it uses cisco encap afterall ?

A cisco router will understand both the IETF and normal Cisco encapsulation when receiving data regardless of configuration. However, depending on the configuration, it will only send one type.

No modem conection with voip over frame-relay

I'm trying to connect two modems through voip over frame-relay network using the modem passthrough command but that is no working. The voice calls is operating very well but the modems no connect between them. I'm using G-729 codec with ip header compression and data fragment in 80 bytes.

There are some know issues with cisco dsps and V.90+ modems, but we have been able to get most modems to work correctly accross our network. If you are using g729 for all other voice calls you will want to use the modem passthrough command to have both gw's turn to modem passthrough. I typically set up each dial peer with the specific commands, since I have found the global commands are not consistently applied. Here is a sample dial peer config....
dial-peer voice 3 voip
description Default voip peer
preference 1
incoming called-number .T
destination-pattern .T
progress_ind setup enable 3
progress_ind connect enable 8
modem passthrough nse codec g711ulaw
voice-class codec 1
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
fax rate disable
fax protocol pass-through g711ulaw
ip qos dscp cs3 signaling
no vad
Some of these commands are specific to the isdn signaling set up we have at this site. Also, we are using sip hence the sip session target. But the modem and fax passthrough commands are pretty much universal.
Also, some of those commands are not supported until 12.2.13. You might want to think about an ios upgrade.

Frame Relay and MPLS

Hi,
I want to ask about the frame relay and MPLS.
Frame Relay Scenerio
The frames reached at the frame relay network and forwarded on the basis of DLCI. All the VCs are defined prior to the traffic on the network on the basis of DLCI (This is just like the MPLS network as packets are forwarded on the basis of Labels).
Now my Question is How can MPLS is used in frame relay network or what are its affects in the presence of DLCI (As DLCIs are also performing the same task and also works on layer 2) or these two are different equivalent technologies ?

Hi Muhammad,
The answer is : MPLS is working on FR like it's working on ethernet. Because the FR and Ethernet are running on Layer2. It's told that MPLS is working at layer 2.5 , meaning that is between Layer 3 , and Layer 2. So in order to work it needs a layer2 forwarding in your case FR's DLCI. On top of the Layer 2 it is the MPLS header.
Dan

PCM V.35 over Frame Relay

Hi,
I need to connect remote sites devices that are delivering two channels voice streams in PCM format (V.35 Interface) over a frame relay network (G.703 interface on service provider side) to a central location where the PCM streams need to be archived.
Can you advise for a solution?

http://www.cisco.com/en/US/products/hw/switches/ps525/products_technical_reference_chapter09186a00800d98b5.html will help to resolve your problem.

Video teleconferencing over frame-relay

I have a user who requires using a polycom video teleconferencing unit at one of my sites that has a t-1 frame-relay circuit. The video is extremly choppy and sometimes completly freezes. I was wondering if there was any particular qos for frame-relay. I have no qOS at the moment. I have found some sample configs for atm and would like to see one for frame-relay. If you have any suggestions any help would be appreciated.

QoS for video over frame relay can be difficult to achieve, although Cisco provides lots of tools to do the best you can. Typically you will want to keep the video traffic within the CIR of the frame circuit. This can be done through setting the TOS bits at the Polycom unit (or through the proxy feature on the Cisco MCM) and then using CBWFQ or other prioritization schemes with the ability to set the bandwidth.
The difficult part comes in that frame-relay is a layer 2 technology and once the traffic goes into the frame-relay network, there is no prioritization of your traffic versus other customers' traffic at each FR switch. CIR will guarantee bandwidth but not necessarily delay constancy which is as important for live video.
Some other considerations might include codec selection - H.264 gives good quality at lower bitrates if your Polycom unit supports it.
Hope this helps,
John

Frame Relay access into MPLS with QOS

My provider is telling me that I can take my frame relay network and map it into their MPLS network. Basically all my sites would connect into the providers Frame network and then mapped into the proivders MPLS network. Now I know this will work; but my concern is VoIP and QOS. If I have a single PVC and I am marking VoIP packets with an IPPREC of 5 how will the providers frame realy network see that? And how will it be honered from CE => Provider FR => PE => P => PE => Provider FR => CE

Todd, I doubt how would your SP provide you guranteed QOS SLA's with that setup. As there is no one to one mapping of PREC/EXP values to FR based QOS.
But although, if he gurantees or ensures that the FR access cloud is never going to be congested and everything is fifo in there then he can provide your per hop QOS behaviour based on your PREC value across the MPLS cloud.
HTH-Cheers,
Swaroop

Benifits of point to point over multipoint on frame relay

Can anyone tell me what the above is ?

This is a big area of discussion and difficult to summarise. There are pro's and con's for configuring frame-relay on p2p, p2m and on the physical interface. It really depends on your design requirements. P2P as the name suggests just has 2 devices connected while P2M can be hub and spoke or full/partial mesh. routing protocols work in different ways depending on how the frame-relay is configured (see ospf network types and eigrp/rip split horizon). The choice of frame-relay interface also has implication on how multicast will work.
So to summarise, if you have many frame PVC's in a hub and spoke topology and use P2P you will end up with lots of subinterface which may be undesirable. P2M can get around this issue as the spoke will only need one interface, but there are other issues to think about if you use P2M.

Can't ping routers across point-to-point frame-relay

'evening,
Really basic setup. Designed with Packet Tracer, trying to ping routers across a point-to-point frame-relay. I've designed this according to three different training sources who all say the same thing. Yet, all pings failed.
The shows:
R1
R1#copy run st
Destination filename [startup-config]?
Building configuration...
[OK]
R1#show run
Building configuration...
Current configuration : 883 bytes
version 12.2
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
hostname R1
no ip domain-lookup
interface FastEthernet0/0
no ip address
duplex auto
speed auto
shutdown
interface FastEthernet0/1
no ip address
duplex auto
speed auto
shutdown
interface Serial1/0
no ip address
encapsulation frame-relay
interface Serial1/0.12 point-to-point
ip address 192.168.12.1 255.255.255.0
frame-relay interface-dlci 102
interface Serial1/0.13 point-to-point
ip address 192.168.13.1 255.255.255.0
frame-relay interface-dlci 103
ip classless
end
R1#show frame-relay lmi
LMI Statistics for interface Serial1/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 638 Num Status msgs Rcvd 638
Num Update Status Rcvd 0 Num Status Timeouts 16
LMI Statistics for interface Serial1/0.12 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 0 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 16
LMI Statistics for interface Serial1/0.13 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 0 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 16
R1#show frame-relay map
Serial1/0.12 (up): point-to-point dlci, dlci 102, broadcast, status defined, active
Serial1/0.13 (up): point-to-point dlci, dlci 103, broadcast, status defined, active
R1#show frame-relay pvc
PVC Statistics for interface Serial1/0 (Frame Relay DCE)
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0.12
input pkts 14055 output pkts 32795 in bytes 1096228
out bytes 6216155 dropped pkts 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 32795 out bcast bytes 6216155
DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0.13
input pkts 14055 output pkts 32795 in bytes 1096228
out bytes 6216155 dropped pkts 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 32795 out bcast bytes 6216155
R2
R2#SHOW RUN
Building configuration...
Current configuration : 772 bytes
version 12.2
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
hostname R2
no ip domain-lookup
interface Serial1/0
no ip address
encapsulation frame-relay
interface Serial1/0.12 point-to-point
ip address 192.168.12.2 255.255.255.0
frame-relay interface-dlci 201
ip classless
end
R2#show fr map
Serial1/0.12 (up): point-to-point dlci, dlci 201, broadcast, status defined, active
R2#show fr pvc
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0.12
input pkts 14055 output pkts 32795 in bytes 1096228
out bytes 6216155 dropped pkts 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 32795 out bcast bytes 6216155
R2#show fr lmi
LMI Statistics for interface Serial1/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 679 Num Status msgs Rcvd 678
Num Update Status Rcvd 0 Num Status Timeouts 16
LMI Statistics for interface Serial1/0.12 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 0 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 16
R3
R3#show run
Building configuration...
Current configuration : 772 bytes
version 12.2
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
hostname R3
interface Serial1/0
no ip address
encapsulation frame-relay
interface Serial1/0.13 point-to-point
ip address 192.168.13.2 255.255.255.0
frame-relay interface-dlci 301
ip classless
end
R3#show fr map
Serial1/0.13 (up): point-to-point dlci, dlci 301, broadcast, status defined, active
R3#show fr lmi
LMI Statistics for interface Serial1/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 703 Num Status msgs Rcvd 702
Num Update Status Rcvd 0 Num Status Timeouts 16
LMI Statistics for interface Serial1/0.13 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 0 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 16
R3#show fr pvc
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0.13
input pkts 14055 output pkts 32795 in bytes 1096228
out bytes 6216155 dropped pkts 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 32795 out bcast bytes 6216155
Any input would really be appreciated.
Thanks

Turns out the mistake was not adding a mask to the subnet. Ex:
Router_2(config_router)# network 192.168.0.0 0.0.255.255
Router_2(config_router)# network 172.27.0.0 0.0.255.255
Doing that on both routers made the hosts capable of pinging each other.
Thanks for the tips everyone

ASR1K 5xE1 MFR Frame relay traffic not forwarding in one direction

Dear Techies,
Hope all is well !
Im doing this inter-op testing with Alcatel device for frame-relay and MFRs and got stuck at this situation which is actually mind boggling and I think i might be missing something "silly" :-(
Its a simple setup of
1. My ASR 1002-X with a LAN (Gig0/0/0) port is connected to a traffic generator.(ixia).
2. ASR WAN port is a 5xE1 bundled into a MFR circuit.
3. WAN link goes to a Alcatel box giving me my FR-DCE with E1s over MFR.
Issue is , I can send traffic to max throughput with  flow initiated from LAN to WAN bit NOT the reverse flow initiated  from WAN side to LAN port. I see traffic coming into my 5xE1s (1.8 mbps each) but the traffic just wont go to the LAN side , somewhere it gets "stuck" or "dropped".
PING works fine from both sides.......but sending traffic is not possible !!
ASR CONFIG
controller SONET 0/3/0
framing sdh
clock source line
aug mapping au-4
au-4 1 tug-3 1
mode c-12
tug-2 1 e1 1 unframed
tug-2 1 e1 2 unframed
tug-2 1 e1 3 unframed
tug-2 2 e1 1 unframed
tug-2 2 e1 2 unframed
tug-2 2 e1 3 unframed
au-4 1 tug-3 2
mode c-12
tug-2 1 e1 1 unframed
tug-2 1 e1 2 unframed
tug-2 1 e1 3 unframed
au-4 1 tug-3 3
mode c-12
interface MFR1
no ip address
encapsulation frame-relay IETF
load-interval 30
frame-relay multilink bid 10MB-PiPe
frame-relay multilink bandwidth-class a
frame-relay lmi-type ansi
interface MFR1.1 point-to-point
ip address 10.10.17.2 255.255.255.0
frame-relay interface-dlci 100
interface GigabitEthernet0/0/0
no ip address
load-interval 30
negotiation auto
interface GigabitEthernet0/0/0.110
encapsulation dot1Q 110
ip address 11.11.11.1 255.255.255.0
interface Serial0/3/0.1/1/1/1:0
no ip address
encapsulation frame-relay MFR1
frame-relay multilink lid First-Link
interface Serial0/3/0.1/1/1/2:0
no ip address
encapsulation frame-relay MFR1
frame-relay multilink lid Second-Link
interface Serial0/3/0.1/1/1/3:0
no ip address
encapsulation frame-relay MFR1
frame-relay multilink lid Third-Link
interface Serial0/3/0.1/1/2/1:0
no ip address
encapsulation frame-relay MFR1
frame-relay multilink lid Fourth-Link
interface Serial0/3/0.1/1/2/2:0
no ip address
encapsulation frame-relay MFR1
frame-relay multilink lid Fifth-Link
SDH_FR#sh frame-relay mul
SDH_FR#sh frame-relay multilink
Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = 10MB-PiPe
Bundle links:
Serial0/3/0.1/1/1/1:0, HW state = up, link state = Up, LID = First-Link
Serial0/3/0.1/1/2/2:0, HW state = up, link state = Up, LID = Fifth-Link
Serial0/3/0.1/1/2/1:0, HW state = up, link state = Up, LID = Fourth-Link
Serial0/3/0.1/1/1/3:0, HW state = up, link state = Up, LID = Third-Link
Serial0/3/0.1/1/1/2:0, HW state = up, link state = Up, LID = Second-Link
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#sh fram
SDH_FR#sh frame-relay pvc 100
PVC Statistics for interface MFR1 (Frame Relay DTE)
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.1
input pkts 8045 output pkts 8044 in bytes 515748
out bytes 527920 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 1000 bits/sec, 2 packets/sec
5 minute output rate 1000 bits/sec, 2 packets/sec
pvc create time 01:07:58, last time pvc status changed 01:07:58
fragment type end-to-end fragment size 1400
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#ping 10.10.17.1-------------------------------------------------------------------------- THIS IS ALCATEL SIDE FROM TRAFFIC HAS TO COME.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.17.1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
SDH_FR#
SDH_FR#
SDH_FR#sh frame-relay traffic
Frame Relay statistics:
ARP requests sent 0, ARP replies sent 0
ARP request recvd 0, ARP replies recvd 0
SDH_FR#

What is the access rate of the head end?
Are you using a codec other than G711?
How many total sites are involved, what protocols are you running?
From the math, 32K is not enough CIR to ensure 4 calls proper Bandwidth. At what point is the voice degrading, is is choppy missing message, sound, jitter, echo or after 1, 2 or 3 calls.
Even if you are using G729a, voice packets could be dropped. Not to say that it is here, but look at the FRS stats to see ip packets are being dropped.
Traffic shaping is always recommended, rtp header compression will help, but the trade-off is around a 20% CPU hit.
If you implement traffic shapping , it needs to be done throughout the network as queueing delays related to data on other slow links and at the headend (specifically here) could be the cause of the distortion alone. I would at least try traffic shapping first, then if the problem doen't go away, increase CIR for Voice, if there are still issues, implement LLQ.

Fram Relay hub and spoke scenario

See the attachment please
Requirements:
1.Using only physical interfaces configure a Frame Relay hub-and-spoke network between RTA and RTB and RTC, RTB as the hub.
2.Traffic from RTA destined for RTC should transit RTB, and vice versa.
3.Use only the DLCIs specified in the diagram.
4.Do not use any Dynamic layer 3 to layer 2 mappings over these frame Relay connections.
5.Do not send any redundant broadcast traffic from the spokes to the hub.
RTB (Hub):
interface Serial0/0
ip address 3.1.1.2 255.255.255.0
encapsulation frame-relay
frame-relay map ip 3.1.1.1 200 broadcast
frame-relay map ip 3.1.1.3 300 broadcast
no frame-relay inverse-arp
RTA (Spoke):
interface Serial0/0
ip address 3.1.1.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 3.1.1.2 22 broadcast
frame-relay map ip 3.1.1.3 22
no frame-relay inverse-arp
RTC (Spoke):
interface Serial1/0
ip address 3.1.1.3 255.255.255.0
encapsulation frame-relay
frame-relay map ip 3.1.1.2 33 broadcast
frame-relay map ip 3.1.1.1 33
no frame-relay inverse-arp
My queries:
A- Does he use these two statements because (frame-relay map ip 3.1.1.3 22 and frame-relay map ip 3.1.1.1 33 ) of requirement number 2 ?
B- Doesnt he use keyword broadcast in these two statements (frame-relay map ip 3.1.1.3 22 and frame-relay map ip 3.1.1.1 33) because of requirement 5?
C- Does that mean if requirement 5 is not there we should have used broadcast keyword ?
D- Does not that contradict with what Cisco syas: The broadcast keyword is commonly used with the frame relay map command ?
E- By using these two statements (frame-relay map ip 3.1.1.3 22 and frame-relay map ip 3.1.1.1 33) doesnt my network become full mesh? but if you look to the diagram it is partial mesh ?

Answers to your queries:
A. Correct
B. Correct
C. That depends. In most cases, it is a good idea to have broadcasts on, especially when using routing protocols like OSPF which send traffic to multicast destinations. I would habe it on most times.
D. The recommendation from Cisco is not contradictory. The lab scenario is making you do something quite specific so you have to follow that. You don't always have to follow requirements in order to make things work.
E. No. Full-mesh refers to a full mesh of PVCs. If there was a PVC from A to C it would be full mesh.
Hope that helps - pls rate the post if it does.
Paresh

Network Topology for Performance/Redundancy

Hello there,
I am projecting my first Oracle VM Pool for the test the virtualization the many Single Oracle Databases 11Gr2 Standard Edition One, but I have difficult about the network topology best practices.
I have imagined this:
bond0(2x 1gb) - Manament Network and Heartbeat.
bond1(2x 1gb) - Live Migration. ( I want use DRS )
bond2(2x 1gb) - VM Public Network.
bond3(2x 1gb) - VM Manament Network ( Manamgement and Backup for VMs ).
bond4(2x 10GBE) - Storage. ( with Jumbo Frame )
All bonds in active-backup (mode=1)
All ports to be connected to two distinct switchs for redundancy.
Is that correct ?
Any suggestion ?
Best Regards,
Rodrigo.

This blog post will provide the networking design details your looking for: Oracle Cloud Reference Design

Voice over Frame-Relay

Hi,
Customer of me has several sites connected with leased lines. The leased lines have frame-relay encapsulation (frame-relay back-to-back)
The line has two pvc's configured, one for voice and one for data. The voice PVC works fine. On the data pvc we want to put some QoS.
Here is the partial configuration:
interface Serial0
bandwidth 2000
no ip address
encapsulation frame-relay
no ip route-cache cef
ip route-cache flow
no ip mroute-cache
frame-relay intf-type dce
interface Serial0.1 point-to-point
ip address 10.xx.xx.1 255.255.255.252
no ip mroute-cache
frame-relay interface-dlci 120
interface Serial0.2 point-to-point
ip address 10.0.0.1 255.255.255.252
no ip mroute-cache
frame-relay interface-dlci 100
class VOICE
vofr cisco
map-class frame-relay VOICE
frame-relay cir 512000
frame-relay voice bandwidth 256000
frame-relay fragment 320
frame-relay fair-queue
Question is can I just apply a service policy out to the data DLCI or doi i also have to enable frame-relay traffic shaping?
Thanks,
JH

The disadvantage of shaping is that it will actually limit you bandwidth. That is, you won't be able to use the circuit at full capacity, because of the artificial limitation induced by shaping. This is particularly true for a situation like you where the actual circuits is a leased line, and not a FR network.
A better approach would be to reconfigure for simple hdlc encap, and run VoIP instead. This way, you would have all the QOS features you need for voice and data, and be able to use the full capacity with a much simpler configuration.
Actually, even if you want to retain the FR encapsulation and the voice over FR approach, still using a single PVC would be better, for the same reasons given above.
Hope this helps, please rate post if it does!

AToM Frame Relay over MPLS

Is it possible to have multipoint topologies with FRoMPLS? In other words, if I'm receiving some Frame Relay PVCs on one physical interface on a PE, can I transport some of them to one remote PE and others to another remote PE? Or do I need to have separate physical interfaces to talk to different remote PEs?
Thanks
Tarek

On the PE router, you can indeed take each one of the DLCIs from a same physical interface and connect them to a different egress PE.
Hope this helps,

Cdp ? in Frame Relay environment

Hi,
I have set up a lab to look at F/R with a partial mesh and sub-interfaces.
I have 3 DTE routers connected to a Frame Switch. One Router named 'middle' has the sub-interfaces configured on it. The other 2 routers named 'Top' & 'Bottom' are just physical interfaces.
I used RIP to route the two networks between Top & Middle and Bottom & Middle respectively. The F/R side has gone well, however, CDP switched itself off on both of the physical interfaces on routers Top & Bottom !!!
Is there a good reason for this ?
To rectify this I have simply enabled cdp on both the serial interfaces.
Regards,
Phil.

Hi Phil,
CDP is disabled by default on (physical) serial interfaces configured for frame-relay encapsulation. That is also the case on multipoint frame-relay interfaces. That is standard IOS behaviour. I think it's due to the fact that these interface types do not inherently support multicast.
Hope that helps - pls rate the post if it does.
Paresh

FRAME RELAY NETWORK TOPOLOGY

Similar Messages

Maybe you are looking for