Frame Relay PVCs are identified to DTE end devices by Data Link Connection Identifiers (DLCIs). A Frame Relay service provider typically assigns DLCI values, which are used on Frame Relay interfaces to distinguish between different virtual circuits. Because many virtual circuits can be terminated on one multipoint Frame Relay interface, many DLCIs are often affiliated with it.
Let me explain—suppose you have a central HQ with three branch offices. If you were to connect each branch office to HQ using a T1, you would need three serial interfaces on your router at HQ, one for each T1. Simple, right? Well, suppose you use Frame Relay PVCs instead. You could have a T1 at each branch connected to a service provider and only a single T1 at HQ. There would be three PVCs on the single T1 at HQ, one going to each branch. And even though there’s only a single interface and a single CSU/DSU, the three PVCs function as three separate circuits. Remember what I said about saving money? How much for two additional T1 interfaces and a pair of CSU/DSUs? Answer: A lot! So, why not just go ahead and ask for a percentage of the savings in your bonus?
Okay, before we go on, I want to define Inverse ARP (IARP) and discuss how it’s used with DLCIs in a Frame Relay network. Yes, it is somewhat similar to ARP in the fact that it maps a DLCI to an IP address—kind of like ARP does with MAC addresses to IP addresses. And even though you can’t configure IARP, you can disable it. It runs on a Frame Relay router and maps the DLCI to an IP address for Frame Relay so it knows how to get to the Frame Relay switch. You can see IP-to-DLCI mappings with the show frame-relay map command.
But if you have a non-Cisco router living in your network and it doesn’t support IARP, then you’re stuck with having to statically provide IP-to-DLCI mappings with the frame-relay map command—something I’ll demonstrate in a bit.
Let’s talk about DLCIs a bit more. They’re locally significant—global significance requires the entire network to use the LMI extensions that offer global significance. This is why you’ll mostly find global DLCIs only in private networks.
But the DLCI doesn’t have to be globally significant for it to be functional in getting a frame across the network. Let me explain: When RouterA wants to send a frame to RouterB, it looks up the IARP or manual mapping of the DLCI to the IP address it’s trying to get to. Equipped with the DLCI, it then sends the frame out with the DLCI value it found in the DLCI field of the FR header.
The provider’s ingress switch gets this frame and does a lookup on the DLCI/physical-port combination it observes. Associated with that combination, it finds a new “locally significant” (meaning, between itself and the next-hop switch) DLCI to use in the header, and in the same entry in its table, it finds an outgoing physical port. This happens all the way to RouterB. So basically, you
actually could say that the DLCI RouterA identifies the entire virtual circuit to RouterB, even
though every DLCI between every pair of devices could be completely different. The big point here is that RouterA is unaware of these differences. That’s what makes the DLCI locally significant. So
make a mental note that DLCIs really are used by the telco to “find” the other end of your PVC.
To discover why DLCIs are considered locally significant, take a look at Figure 1. In the figure, DLCI 100 is considered locally significant to RouterA and identifies the circuit between RouterA and its ingress Frame Relay switch. DLCI 200 would identify the circuit between RouterB and its ingress Frame Relay switch.
Figure 1: DLCIs are local to your router
DLCI numbers that are used to identify a PVC are typically assigned by the provider and
start at 16.
You configure a DLCI number to be applied to an interface like this:
Let me explain—suppose you have a central HQ with three branch offices. If you were to connect each branch office to HQ using a T1, you would need three serial interfaces on your router at HQ, one for each T1. Simple, right? Well, suppose you use Frame Relay PVCs instead. You could have a T1 at each branch connected to a service provider and only a single T1 at HQ. There would be three PVCs on the single T1 at HQ, one going to each branch. And even though there’s only a single interface and a single CSU/DSU, the three PVCs function as three separate circuits. Remember what I said about saving money? How much for two additional T1 interfaces and a pair of CSU/DSUs? Answer: A lot! So, why not just go ahead and ask for a percentage of the savings in your bonus?
Okay, before we go on, I want to define Inverse ARP (IARP) and discuss how it’s used with DLCIs in a Frame Relay network. Yes, it is somewhat similar to ARP in the fact that it maps a DLCI to an IP address—kind of like ARP does with MAC addresses to IP addresses. And even though you can’t configure IARP, you can disable it. It runs on a Frame Relay router and maps the DLCI to an IP address for Frame Relay so it knows how to get to the Frame Relay switch. You can see IP-to-DLCI mappings with the show frame-relay map command.
But if you have a non-Cisco router living in your network and it doesn’t support IARP, then you’re stuck with having to statically provide IP-to-DLCI mappings with the frame-relay map command—something I’ll demonstrate in a bit.
Let’s talk about DLCIs a bit more. They’re locally significant—global significance requires the entire network to use the LMI extensions that offer global significance. This is why you’ll mostly find global DLCIs only in private networks.
But the DLCI doesn’t have to be globally significant for it to be functional in getting a frame across the network. Let me explain: When RouterA wants to send a frame to RouterB, it looks up the IARP or manual mapping of the DLCI to the IP address it’s trying to get to. Equipped with the DLCI, it then sends the frame out with the DLCI value it found in the DLCI field of the FR header.
The provider’s ingress switch gets this frame and does a lookup on the DLCI/physical-port combination it observes. Associated with that combination, it finds a new “locally significant” (meaning, between itself and the next-hop switch) DLCI to use in the header, and in the same entry in its table, it finds an outgoing physical port. This happens all the way to RouterB. So basically, you
actually could say that the DLCI RouterA identifies the entire virtual circuit to RouterB, even
though every DLCI between every pair of devices could be completely different. The big point here is that RouterA is unaware of these differences. That’s what makes the DLCI locally significant. So
make a mental note that DLCIs really are used by the telco to “find” the other end of your PVC.
To discover why DLCIs are considered locally significant, take a look at Figure 1. In the figure, DLCI 100 is considered locally significant to RouterA and identifies the circuit between RouterA and its ingress Frame Relay switch. DLCI 200 would identify the circuit between RouterB and its ingress Frame Relay switch.
Figure 1: DLCIs are local to your router
start at 16.
You configure a DLCI number to be applied to an interface like this:
RouterA(config-if)#frame-relay interface-dlci ?
<16-1007> Define a DLCI as part of the current
subinterface
RouterA(config-if)#frame-relay interface-dlci 16
<16-1007> Define a DLCI as part of the current
subinterface
RouterA(config-if)#frame-relay interface-dlci 16
No comments:
Post a Comment