Options

EIGRP & OSPF over frame-relay

Darian929Darian929 Member Posts: 197
Hello,

I am having a lot of problems learning the sections on how EIGRP & OSPF work differently in frame-relay networks. Whether they are NBMA or broadcast or point-to-point or multipoint. I guess there are so many ways of configuring it that it's confusing me overall.

The real problem I have is I have never used frame-relay in my career besides in labs and reading and it's one of those topics where I read it.. ok then 2 weeks later I forget it because I don't use it and frankly don't see any use for it out there at this time.

Anyone have any page or blog that might explain it stupid simple?

Thanks

Comments

  • Options
    fredrikjjfredrikjj Member Posts: 879
    Layer 2 issues:
    Frame Relay doesn’t support multicast or broadcast which means that no IGP will work over it by default. The best you can hope for is “pseudo broadcast” which makes the router copy the multicast and send it across every pvc. This is configured by adding the broadcast keyword to the frame-relay map command. If you rely on inverse arp to discover mappings, pseudobroadcast works by default, I think.


    The second L2 issue is the fact that the FR’s inverse ARP function only discovers the IP addresses of router’s directly connected through a PVC. This means that in a partial mesh, a router will not know how to find the the data link information of IP addresses that have L3 reachability, but not L2 reachability. You need to statically configure these mappings for frame relay to work properly with IGPs because otherwise, a router won’t be able to reach those next hops. And if you are doing that, FR becomes quite cumbersome to configure since you need to manually add a mapping to every router each time you add a new spoke to a hub-and-spoke network.


    IGP issues:
    The IGP hello packets can only reach one layer 2 hop, which means that you can only form neighbors over directly connected PVCs. EIGRP is pretty easy to configure since it doesn’t have DR/BDRs or network types. You simply determine if the FR network supports broadcast, and in that case, you just ensure that you have L3 reachability everywhere, and enable EIGRP.
    If you have static mappings without the broadcast parameter, you need to configure static neighbors with the neighbor ip-address outgoing interface router command. Hellos are now sent unicast to the addresses you specify in the neighbor statements.


    With OSPF it gets a bit more complicated since you can get FR to work with all 5 network types.


    Point-to-point: You need to use a frame relay point-to-point subinterface, attach the right DLCI with frame-relay interface-dlci command, and mirror the configuration on the other side of the pvc. This supports multicast and everything will work pretty much automatically. The drawback of this is that you need to use a subnet for reach point-to-point link. With a large FR network, you would use a ton of subnets.


    Broadcast: This network type uses a DR/BDR which really isn’t ideal in a network with pseudowires, or frame-relay pvcs. The issue is that the database exchange requires a direct l2 connect, and the sending of IP packets doesn’t. With Frame Relay this means that the only routers that can acts as DR are the ones with a direct PVC to all other routers. In a hub-and-spoke, this means that the hub must be the DR, and all spokes must be taken out of the DR election with ip ospf priority 0. The second step with this network type is to make sure that the broadcast parameter is enabled over the direct pvcs to the DR, and that you have static mappings to all IPs in the subnet, from all routers. Once that is done you can enable ospf on all interfaces and it should run properly.


    Nonbroadcast: This mirrors the previous type, except that you don’t have the capability to use multicast over the FR network. This is mostly a training exercise since you always have the pseudobroadcast capability, but if it’s forbidden, you need to statically configure the neighbors with the neighbor router command. Remember that you can only form neighborship with routers over directly connected pvcs. On the classic hub-and-spoke network, this essentially means that you only have one neighbor command on each spoke, to the hub/DR, and on the hub, you have a neighbor statement for every other router.


    Point-to-multipoint: This type does away with the DR/BDR, just like point-to-point, while still allowing multiple routers on the same subnets. Don’t ask me exactly how OSPF makes this work, but the key thing is that you no longer have to rely on having a direct PVC to a DR and your network having issues if this link goes down. You still need broadcast capabilities over each pvc to form neighborships, and static mappings to all routers not directly connected.


    Point-to-multipoint nonbroadcast:
    The same as point-to-multipoint except that you are not allowed to use the broadcast parameter on the frame-relay mappings. Just like with Nonbroadcast, this means having to manually configure the neighbors under the ospf process. Again, you can only form relationships where you have a direct L2 connection.

    Written fror memory, so there are probably some errors, but the gist of it should be correct.
  • Options
    Darian929Darian929 Member Posts: 197
    Fred,

    Thanks very much for the explanation. Much appreciated. I will start doing some labs on each type so I can get a deeper understanding and how each one works and I think that should settle the differences in each and what the capabilities for each our.

    I hope I can get to the point where I can remember them from memory like you!

    Thanks,

    Darian
  • Options
    fredrikjjfredrikjj Member Posts: 879
    Start with the network types because how you configure Frame Relay flows from for how those work.
  • Options
    fredrikjjfredrikjj Member Posts: 879
    Addendum:
    You need to statically configure these mappings for frame relay to work properly with IGPs because otherwise, a router won’t be able to reach those next hops. And if you are doing that, FR becomes quite cumbersome to configure since you need to manually add a mapping to every router each time you add a new spoke to a hub-and-spoke network.
    Or, configure the hub router to change the next-hop of the routes from the spokes to be the actual hub router.
    Nonbroadcast: This mirrors the previous type, except that you don’t have the capability to use multicast over the FR network. This is mostly a training exercise since you always have the pseudobroadcast capability
    Or, maybe you run EIGRP over three links, and you have 100 PVCs and don't want to replicate the multicast over all those pvcs.
Sign In or Register to comment.