Frame Relay

ignign0ktignign0kt Posts: 42Member ■■□□□□□□□□
I have just watched the Frame Relay video on the Trainsignal video lectures, but am confused on one thing. First of all here is the topology he used:

untitledus8.jpg


He said that he configured th R3 serial interface as a point-to-point interface for the sake of showing how to configure it... but I don't understand how you can use a point to point link here. If it is just point-to-point, what device will it be able to communicate with? Also.. on the other routers, he didn't include the "multipoint" parameter when entering the interface modes... is it multipoint by default? I thought this video would help me, but I think it just confused me more on the configurations...

Comments

  • DW [banned]DW [banned] Posts: 240Inactive Imported Users
    Let's see if I can help on this one.

    All the DLCI's will by default land on the PHYSICAL interface. (Thus negating the Mutlipoint requirement).

    You must ask yourself what type of interface is going to be used when dealing with any interface, but especially FRAME RELAY:

    1. Physical

    2. Point-to-Point

    3. Point-to-Multipoint

    Can they work together?

    Yes

    Can they mis-match?

    Yes

    Do you need to know the tricks per type?

    Yes

    I'll have to watch the video example, so forgive my ignorance on that one.

    But I'll give you a quick config off the top of my head and you tell me if I'm wrong or crazy...

    :)


    And oh yes - unless I forget - That R2 is a point to point link and it will send all traffic out of it to the next hop - you do not even need the broadcast keyword... How kewl is that?

    And BTW - in the real world it is probably the widest used - cause it is THAT easy. It just works.


    So based on your diagram and requirements, here's me config:

    R2

    int s0/0/0
    ip address 172.12.123.2 255.255.255.0
    encap fram (can't use subinterfaces without it)
    fram map ip 172.12.123.3 201 br
    fram map ip 172.12.123.1 201 br

    R3

    int s0/0/0
    encap frame

    int s0/0/0.31 p
    ip addr 172.13.123.2 255.255.255.0
    fram interface-dlci 301

    R1

    int s0/0/0
    encap fram
    ip address 172.12.123.1 255.255.255.0
    fram map ip 172.12.123.2 102 br
    fram map ip 172.12.123.3 103 br

    sh fram map

    sh fram lmi

    sh fram pvc

    ping 172.12.123.x from each router.


    Does this help?

    You should be able to ping one spoke from the other and vice versa.


    Again off the top of my head - so let me know if I missed something.

    :)
  • ignign0ktignign0kt Posts: 42Member ■■□□□□□□□□
    The instructor says that.. in order for R2 and R3 to communicate, the data has to travel through R1. That's one thing I don't understand... why can't data from R2 go through the frame close and then to R3? In the Frame Relay TechLab at this site, each router has a PVC set up to connect to each other. Is that not a hub and spoke topology? How can you tell? And I assume that when using sub-interfaces, the router assumes it's multipoint? Because the instructor didn't include the multpoint parameter, but he clearly said it was multipoint interface.
    For example, on R2, here is how he set the frame maps:
    R2(config-subif)# frame map ip 172.12.123.1 221 broadcast (to R1)
    R2(config-subif)# frame map ip 172.12.123.3 221 broadcast (to R3)

    He used the same DLCI for both connections since data has to go through R1 to get to R3. What happens if you use a different DLCI?

    lol man questions galore ;\
  • EdTheLadEdTheLad Posts: 2,112Member ■■■■□□□□□□
    By default a physical interface will work as multipoint FR, so in your example both R1 and R2 are configured on the physical interface so therefore they are multipoint. When an interface is multipoint it means multiple dlcis can terminate on that interface, which means it can simulate a broadcast environment when a mesh of pvcs is created.
    Since R3 is configured as a ptp FR interface using a subinterface, it can only support one dlci. In this case that dlci is connected to R1, so any time traffic is destined for the 172.12.123.x network it will be sent to R1. R1 will receive the packet, see its destination is 172.12.123.2 and send it out onto he dlci to R2.If R3 were a multipoint interface you could have created two separate dlcis, one for R1 and one for R2.
    The dlci you choose for your mapping must be configured on the connected FR switch, the switch will map the dlcis between the routers.If there is a dlci mismatch the dlci will not become active and you will not have connectivity.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • ignign0ktignign0kt Posts: 42Member ■■□□□□□□□□
    I think I understand now, thanks.
    And while on the subject... I only have 2 routers at home, and would like to set up a frame relay lab. Well from what I understand I would need at least 3 routers to use frame relay. I tried doing frame relay on Boson (the framerelay techlab) but it wouldn't support some frame switch commands. Specifically the frame route commands.
  • ignign0ktignign0kt Posts: 42Member ■■□□□□□□□□
    I have another question. In the labs I've seen (TestOut labs), they only used 1 subinterface to communicate with multiple routers using frame relay. What's the point in that? Wouldn't you want multiple subinterfaces to do this?
  • DW [banned]DW [banned] Posts: 240Inactive Imported Users
    That is the easiest way and I believe the recommended best practice - or at least common practice.


    CCIE Lab is another matter entirely.

    :)
  • ignign0ktignign0kt Posts: 42Member ■■□□□□□□□□
    But I thought the point of making subinterfaces was to get past the split horizon limitation with sending data out the same interface.
    Why make one sub-int if you can just use the physical interface :P
  • DW [banned]DW [banned] Posts: 240Inactive Imported Users
    Flexibility and Scalability...

    Fact is P-2-M and P-2-P are what I seem to always see deployed.


    Unless we are talking about a direct connection between two sites... then we don't see Frame...


    Frame was designed for inverse multiplexing...

    Sharing bandwidth.

    The idea is you can use more bw if your neighbors are not...

    But as to physical or P2P...

    Not sure in real life...

    Come to think of it...

    Most of the frame circuits I've dealt with are P2P come to think of it...

    Maybe all of them?

    P2P is the easiest and works well from an implementer's standpoint is probably the best reason.

    In life, we want it to work the 1st time and not troubleshoot...

    On labs, we do what is required to test the technology and theory.
Sign In or Register to comment.