I've done the CCNA and am working on the CCNP bcran exam and I've got one major issue that steadfastly refuses to go away! When looking at diagrams of a frame relay network there appears to be no consistency in where the DLCI is drawn on the diagram. Sometimes the DLCI written above a link seems to mean the local dlci, whereas at other times it's the other ends DLCI.
frame-relay map ip 10.10.12.2 200 broadcast cisco
Sometimes has a diagram with the 200 drawn next to the 10.10.12.2 router, at other times the 200 is on the other side.
This is an issue that I've have for months and I'm getting nowhere. Am I just stupid or is there no set convention?
It should be the local dlci. The DLCI is only significant between the router and frame relay switch. The frame relay switch should do the rest in getting your packet to the correct destination. In theory you could have the same DLCI number for both the local and remote connection.
In your example and the diagram below. The frame map on R1 would be
You will be well aware that a DLCI is local to an interface.
Site A - DLCI 16 --FR Cloud -- DLCI 16 Site B Site A - DLCI 17 --FR Cloud -- DLCI 16 Site C
Site A uses 16 to reach Site B Site B uses 16 to reach Site A Site A uses 17 to reach Site C Site C uses 16 to reach Site A
The above is a standard addressing scheme and you would see the DLCI's on the outgoing link on the diagram.
There is another concept used to simplify understanding the destination of PVC's called global addressing. This is just a conceptual addressing and does not make frame-relay addressing work any different. It just means the DLCI's are picked intelligently and not just sequentially.
For this we allocate each site an id.
i.e. Site A = 101 Site B = 102 Site C = 103
We then use the DLCI number of the site we intend to connect to.
Site A - DLCI 102 --FR Cloud -- DLCI 101 Site B Site A - DLCI 103 --FR Cloud -- DLCI 101 Site C
Site A uses 102 to reach Site B Site B uses 101 to reach Site A Site A uses 103 to reach Site C Site C uses 101 to reach Site A
You could still label the DLCI on the outgoing link but now as you know that all DLCI 101 go to Site A, all DLCI 102 to site B etc. you can just label the site instead.
Actually, I found that both the carriers I dealt with in my last job (MCI aka Worldcomm and Sprint) were more than willing to work with us on DLCI number assignment. We used a system similar to the one described, where the DLCI number would always correspond to the remote site. In fact, we went one step further, and used the same number for a site's local ethernet subnet number, the subinterface to it from the central site's router, and the DLCI. This meant that only one unique number had to be tracked for each remote. For example, S0/1:0.120 on the home office router might be connected to DLCI 120, which would get you to the Houston branch office, which would have a local subnet of
10.1.120.0/24. Remote sites were all configured to use DLCI 100 on S0.100 to reach home. Only problem with this is that it tends to disguise the fact that the DLCI truely is a local number, which can get you in trouble if you forget. You still have to configure BOTH local ends of the PVC, and be sure the carrier knows which end you want with which number when adding.
R2 is hub and has reachability to both R1 and R3 via 2 pvcs with DLCIs
201 and 203. R1 and R3 are spokes and have only reacability to R2. To reach each other they have to go via R2. By looking at the first and last digit of the DLCI you can see source and destination router (taking into account that R1 and R3 are spokes).
On R2 you would have the following maps
frame-relay map ip 10.0.0.1 201 frame-relay map ip 10.0.0.3 203
On R1 and R3 everything has to go via the 1 DLCI
R1 frame-relay map ip 10.0.0.2 102 frame-relay map ip 10.0.0.3 102
R3 frame-relay map ip 10.0.0.2 302 frame-relay map ip 10.0.0.1 302
To have a fully meshed network you would create another 2 PVCs for R1 to talk to R3 ie DLCI 103 and R3 to talk to R1 ie 301. R1 and R3 would now look like
R1 frame-relay map ip 10.0.0.2 102 frame-relay map ip 10.0.0.3 103
R3 frame-relay map ip 10.0.0.2 302 frame-relay map ip 10.0.0.1 301
Thanks, I'm really please I posted now as this is really clearing up some of my confusions. One think I'm still slightly unsure of is point-to-point vs multipoint. Can you help out at all? In the sybex book it says something along the lines, "multipoint is used when all ip's are in the same subnet, point-to-point when they each have their own subnet" (cisco press book is more cryptic!). I'm not clear though on what is actually happening on a multipoint config. the packets still have to go via the hub router, right? I can't work out what the fundamental difference between the two is. Also do all routers in the network have to run the same? ie all multipoint or all point-to-point? Does the split horizion issue affect both multipoint and point-to-point?
It's not easy to understand and takes years to fully master. I wouldn't consider myself an expert on it yet and it's difficult to explain in one posting but I enjoy writing about it and can learn from it. As I said I am not an expert and I may have got something wrong here
A multipoint interface is an interface that can be used to connect multiple end points in the same IP subnet in a network.
If you look at the following diagram. 4 routers R1 is hub and R2 R3 and R4 spokes.
R1 has reachability to all spokes via 3 pvcs with DLCIs 102,103 & 104 (Remember DLCIs are identifiers for layer 2 pvcs). All routers are in the same subnet 10.0.0.0/8. There is more than 1 way of configuring this but to demonstrate we can create multipoint interfaces on all routers.You can create multipoint interfaces in 2 ways. By definition the physical interface is a multipoint interface or you can use a multipoint sub-interface.
So on R1 we could have configured it directly on the Serial 0 interface
interface s0 ip address 10.0.0.1 255.0.0.0 encapsulation frame-relay frame-relay map ip 10.0.0.2 102 broadcast frame-relay map ip 10.0.0.3 103 broadcast frame-relay map ip 10.0.0.4 104 broadcast
or with a sub-interface
interface s0 encapsulation frame-relay
interface s0.1 multipoint ip address 10.0.0.1 255.0.0.0 frame-relay map ip 10.0.0.2 102 broadcast frame-relay map ip 10.0.0.3 103 broadcast frame-relay map ip 10.0.0.4 104 broadcast
On R2, R3 and R4 the configuration will be similar. R2 interface s0 ip address 10.0.0.2 255.0.0.0 encapsulation frame-relay frame-relay map ip 10.0.0.1 201 broadcast frame-relay map ip 10.0.0.3 201 frame-relay map ip 10.0.0.4 201
If we now change the diagram and make R4 in a different subnet
With multipoint we now have a problem. The obvious problem is how are we going to define 2 separate subnets on the same interface. The other problem is split horizon. Split horizon is used with routing protocols to prevent loops. Split horizon says do not advertise a route out the same interface you received it from or think of it as don't tell the same joke to the person you first heard it from :o). So if there are networks behind R4 and R4 tells R1 about them R1 is not able to tell R2 and R3 since it is trying to tell them out the same interface that it first heard about them from R4.
To get around this we can create another sub-interface. In this case since there are only 2 end points we can create a point-to-point sub-interface
R1 would now be
interface s0 encapsulation frame-relay
interface s0.1 multipoint ip address 10.0.0.1 255.0.0.0 frame-relay map ip 10.0.0.2 102 broadcast frame-relay map ip 10.0.0.3 103 broadcast interface s0.2 point-to-point ip address 220.127.116.11 255.0.0.0 frame-relay interface-dlci 104
With point-to-point you just have to tell it what DLCI to use with the command "frame-relay interface-dlci " and do not need to define any frame-relay maps since this is a point-to-point interface and their is only 1 neigbour that it is going to reach.
R4 will now be configured as
interface s0 encapsulation frame-relay
interface s0.1 point-to-point ip address 18.104.22.168 255.0.0.0 frame-relay interface-dlci 401
R4 is just sending everything to R1 via DLCI 401. On R1 we now have 2 logical interfaces so we do not have the problem of split horizon since R1 is receiving the routing updates from R4 via s0.2 and sending them out to R2 and R3 via s0.1.
As I said in the beginning their are many ways to configure it. If you look at the first diagram
interface s0.1 multipoint ip address 22.214.171.124 255.0.0.0 frame-relay map ip 126.96.36.199 401 broadcast
As you can see there are many ways of doing it but just think if you are connecting to more than one end node in the same IP subnet use a physical or multipoint sub-interface and if its directly connected to one end-node use a point-to-point sub-interface.
Given the issue of split horizon, and the fact that the carrier's network is actually supplying multiple point-to-point links (PVCs) rather than a true "shared medium", can anybody think of a good reason for using multipoint configuration instead of point-to-point? The only thing that remotely comes to mind is that you can save on the number of subnet numbers needed for WAN addressing by sticking it all in one subnet, which when slicing up a "10" seems kinda lame.
True, any remote-to-remote traffic passes through via the hub router. Think of them as being on a "shared medium". It's a layer 2 (data-link - DLCI - see the connection?) issue (start thinking in terms of the 7-layer protocol model - we're working with the bottom 3 layers here)
No. This is one of the beauties of something called "sub-interfaces" on Cisco serial interfaces. Subinterfaces allow you to subdivide a physical serial interface into logical sub-interfaces, and those subinterfaces can be configured with their own DLCI's (as assigned by the frame switch). On routers with multiple serial interfaces, one can be running both a multipoint subinterface and a point-to-point subinterface, while the other serial interface runs a purely point-to-point interface. Study your configuration examples for those sorts of combination interfaces. (the routers on the same multipoint circuits have similar interface configurations, point-to-multipoint)
Split horizons affect multipoint circuits because a router cannot broadcast a routing update out of the same interface (or subinterface) that it received the update from. This is a problem in multipoint circuits, because it means that one of the remote routers will not receive a routing update from another remote router via the hub router. There is a solution, and you'll probably be studying that solution soon (if you haven't discovered it already)
I'm sure everyone will chime in to tell you that DLCIs are locally significant. And that's true. But there is something called "global DLCIs" or "global routing DLCIs"
Think of it this way. DLCIs are exit numbers on a freeway. If it's a local DLCI it signifies the on ramp number. If it's a global DLCI, it signifies the exit ramp number. Either way, you're going to your destination!
I agree that in the real world, in my experience, most people just use point-to-point links.
I guess their is no real good reason for using a multipoint interface. It's neater, quicker to setup and easier to manage if you have many spoke connections and save on some subnet numbers as you mentioned but other rhan that its easier just to stick with point-to-point.
Although this is possibly true of some service providers, The ones I have had contact with will allow the customer to select the DLCI's as they are local to the interface so have no detrimental effect to the service provider.
This is a simular approach to the global address scheme I described but uses source/destination site numbers. It is more useful though in a lab as it doesn't scale to a large number of sites. It could also be usefull in a private frame-relay network where it could be usefull to tell at a glance from the frame-relay switch which site an interface connects just by looking at the DLCI's of the PVC's on the interface (some switches including Cisco's MGX range don't allow descriptions on the interface). In the SP world though you wouldn't need the source site number in the dlci as there would be multiple customers all with at least a site 1 and 2 and maybe using different addressing conventions aswell. As for the customer themselves viewing PVC's from their own router's they would already know the source site as the router would be located there so a better approach here would be just to use the destination site number. N.B. as DLCI 1-15 and 1023 are reserved I recomend the following convention.
Site number +100 Destination Site 1-99 = 101-199 Destination Site 100-199 = 200-299
This method would scale to large networks, theoretically 922 sites although I feel the practical limit would be a lot lower than this. There also would be a cost deficit as each PVC in the network costs money. If you have just
100 sites fully meshed with PVC's you would need 4950 PVC's the formula to work this out is.
n * (n-1)
where n = number of sites.
For this reason most companies use an hub and spoke method where only the main site (site 1) connects to all other sites, or a partial mesh where they use an hub/spoke and also pvc's between other sites dependent on sufficient traffic loadsto justify them. A standard hub/spoke setup on a 100 site network would require just 99 PVC's but if redundency is used then this could be increased to 198 (2 routers at main site connected to all other sites). Either way substantially less than the 4950 needed for a fully meshed setup.
Sometimes split horizon rules can be usefull on a network where all traffic supposed to only pass between remote sites and head office. A multipoint set up here can simplify the set up and as you have already said only requires one subnet to achieve this.
I have read somewhere (on the web I think) that subinterfaces were invented because frame-relay configured on an interface only operated as a multipoint setup only. Sub-interfaces allowed the point-point approach each with their own subnet and evaded the split horizon problem. The multipoint sub-interface was included so you could mix and match and have some remote sites able to communicate with other remote sites along with other sites which were not allowed to talk to each other if on the same multipoint segment (sub-interface) but could still talk to sites on the other point-point sub-interfaces or other multipoint sub-interfaces. All this means is flexibility in design. Cisco gets A+ for this.
(dependent on routing protocols/router config) Site 1 and Site 2 can talk to all other sites via site 1. Site 3,4,5 can only talk to sites 1,2,6 & 7 (site 2,6 & 7 via site 1) Site 6 & 7 can talk to all other sites except eachother via site 1
I am not saying the above is a typical arrangement, just a simple explanation of what can be achieved. In fact Policy based routing is more common than this approach.
Forgot to mention that the OSPF routing protocol can get round the split horizon rule with certain configurations by treating the frame-relay network in a multi-point setup is special ways to prevent routing loops, it depends totally on the setup of the frame relay setup, i.e fully meshed, partially meshed, hub/spoke and the router's configs. Apart from that I would have to get my books out as I only have real experience with OSPF and frame-relay with point-point links.
Many many thanks for the replies. At the moment I'm overwhelmed by the responses and it's going to take me a couple of days to get my head around this stuff. Thanks very much to everyone that has chipped in for their comments and help, I'm incredibly grateful.