(l) Multilink Frame Relay
(m) PPP over Frame-Relay
(n) Dynamic Mappings to 0.0.0.0
(o) Troubleshooting Hub and Spoke
(p) Frame Relay Switch Configuration
(q) Subinterfaces
Multilink Frame-Relay
This sounds awfully a lot like PPP over Frame (and it is) the idea of encapsulating PPP on top of frame was to support service interworking between Frame-Relay and ATM and granting the capability for link fragmentation (thanks to ML-PPP) ML-PPP works fine over a single physical interface (or PVC in this case)
Multi-link PPP allows you to specify a fragment size, where packets smaller than the fragment size are transported as is (in a priority queue), while larger packets are chopped into fragments and given the ML-PPP header in order to be re-assembled on the other size - smaller packets can be interleaved between fragments of larger packets allowing realtime packets such as voip packets to be delivered without requiring a large de-jitter buffer (however by default a FIFO queue is used but it is certainly possible to use an alternate queueing method such as LLQ, WFQ, CBWFQ to achieve this)
Configuration involves:
- Frame-Relay Traffic Shaping has to be enabled on the interface at hand
- A Frame-Relay class-map needs to be defined with the appropriate traffic shaping which will be bound to the PVC
- A ClassBased QoS Policy Map which will be bound to the virtual-template to handle the classification and queueing of egress traffic
- Defining a virtual-template interface that uses PPP encapsulation and has an unnumbered interface (bound to a loopback) in particular the below commands are required:
- bandwidth [xxx] (Where [xxx] is the PVC CIR)
- ppp multilink
- ppp multilink interleave
- ppp multilink fragment delay
[yyy] (Where in [yyy] ms is used to determine the fragment size and is based on both the physical port and PVC CIR with typically no more than 10ms serialisation delay [yyy] = [phys_interfacebandwidth] / [PVC_CIR] * [Max_serialisation_delay] the size in bytes could be calculated as [PVC_CIR_bps] * ([yyy] / 1000) / 8 - service-policy output
[marked, limited and queued traffic]
- The Frame-Relay sub-interface would have:
- frame-relay interface-dlci [dlci] ppp virtual-Template [n] (Where [dlci] is the PVC id and [n] identifies the particular virtual-template)
- class[fr-shapingclass]
PPP over Frame-Relay
The majority of how this is done (using a virtual-template) is described up above. The only extra information that can be described is that you can add other PPP related things such as authentication which may be useful rather than blindly trusting the service provider has given you the correct PVC between your devices without necessarily needing the overhead of IPSec.
The other good thing is that there is no L3 information configured on the Frame-Relay interface, no Inverse-ARP and no static mapping required since L3 information is contained in the virtual template.
Another INE Blog Post gives an example here, however I think this area is really a subset of the above.
Understanding Dynamic Mappings to 0.0.0.0
Those guys at INE have another post talking about this but the long and the short is, this is a carry over from AutoInstall where a router which does not have a saved configuration but has WAN connections to a FR network autodetects that it's on a FR network, uses LMI to determine active PVCs and since it has no configuration but is attempting to find a BOOTP server (since there is no configured L3 information, the mechanism binds 0.0.0.0 to the active PVCs hoping to find a config server which will send down a config)
If you have since applied a config - it's possible that these bindings may not disappear (visible if you do a show frame-relay map) unless you write mem and reload, however changing the interface encapsulation from frame-relay and back may fix this.
Troubleshooting Hub and Spoke
Shamelessly ripped from Brian Dennis
- Use point-to-point subinterfaces on the spokes. This option is preferred as all IP addresses on the subnet will automatically be mapped to the DLCI that is bound to the subinterface.
- Multipoint interfaces (physical or multipoint subinterfaces) on the spokes with Frame-Relay mappings pointing to the hub’s DLCI to reach the other spokes.
- Multipoint interfaces on the spokes along with using the OSPF point-to-multipoint network type on all routers on the subnet. Each end point will advertise out a /32 and this advertisement will be relayed to the other spokes by the hub. This is exactly what the OSPF point-to-multipoint network type was designed for (full layer 3 reachability in a network that doesn’t have full layer 2 connectivity.
- Use PPP over Frame-Relay (PPPoFR). By using PPPoFR IP will now be running over PPP and not directly over Frame-Relay. This means that IP sees everything as point-to-point links and no layer 3 to layer 2 mappings are needed.
- Static /32 routes on the spokes point to the hub to reach the other spokes. Not a pretty solution but it will resolve the reachability issue.
Frame-Relay Switch Configuration
Frame-Relay switches can be implemented by regular routers. A few conventions exist at Layer 1 and Layer 2 which are not mandatory but best mimic what a service provider frame-switch does and makes is somewhat more normal for the non Frame-Switch
Layer 1:
On the serial interface, there are two types of interfaces, DTE and DCE, typically the non-service provider device would appear as the DTE and the frame-switch as the DCE (it doesn't have to be this way but it is usually the convention) one of the reasons why the SP is the DCE is that the physical interface clock-rate is specified by the DCE
Layer 2:
Once you specify the interface encapsulation type i.e. encapsulation frame-relay your interface type is DTE by default (Layer 1 and Layer 2 DTE/DCE configurations are independant of each other) The Frame-Relay DCE provides the LMI status messages, while the DTE makes the LMI enquiries. This is configurable using the frame-relay intf-type [type] command where [type] can be dce, dte (default) or nni (for frame-switch to frame-switch connections) actually if you disable LMI on both interfaces by configuring no keepalive this area of the configuration is not required, however you miss out on the OAM features that LMI brings to the party (such as allowing you to know that a PVC is down either because the SP network doesn't know of its existance, or possibly the far end device is off the air)
Frame-Switch Configuration:
hostname FR-SW
!
frame-relay switching
!
interface Serial0/0
description To R1
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
frame-relay route 102 interface Serial0/1 201
!
interface Serial0/1
description To R2
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
frame-relay route 201 interface Serial0/0 102
!
frame-relay switching enables the router to perform "routing" or cross-connecting Frame-Relay PVCs
frame-relay route [SRC_PVC] interface [DST_Interface] [DST_PVC] provides the layer 2 mapping to switch frames from the source interface/pvc to the destination interface/pvc - since this is a unidirectional mapping, it requires a corresponding entry in the reverse direction.
Subinterfaces
I don't know what to say here - these things are a somewhat fundamental construct. It's certainly possible to configure multiple PVCs under the main interface configuration, however it can cause some problems with routing protocols due to the split-horizon rule. One way around this is to use logically interfaces which are children of the main physical interface which are attached to a logical circuit (PVC). In Frame-relay you can have either point-to-point or multipoint sub-interfaces and they can logically coexist. A Multipoint interface would support multiple PVCs in the same L3 domain, while a point-to-point interface supports only a single PVC in the L3 domain.
No comments:
Post a Comment