Frame-relay and inverse-arp

Hi,

I am using a pretty basic frame-relay configuration on Dynamips. 2 routers through a Frame-relay switch.

I was playing around with the inverse-arp settings, but cant quite understand the scenarios im getting.

I am disabling inverse-arp on the Router1's serial interface (no frame-relay inverse-arp), but for some reason it is still sending out both requests and answers, cause it will (in time) build a frame-relay map (dlci<->ip).

In Cisco's documentation it simply states:

Use the frame-relay inverse-arp interface configuration command to enable the Inverse Address Resolution Protocol (Inverse ARP) on the router configured for Frame Relay. Use the no form of this command to disable this feature.

Shouldnt it just ignore both sending out i-arp messages as well as not responding to them?

I hope its okay to quote from the documentation.

Configuration:
R1:
interface Serial0/0
ip address 10.0.0.1 255.255.255.0
encapsulation frame-relay
no frame-relay inverse-arp

R2:
interface Serial0/0
ip address 10.0.0.2 255.255.255.0
encapsulation frame-relay

Thanks!

Edit: oh, and howcome, if i add R3 hooking up to R1's serial. That way R1 has two DLCIs, one for each spoke. I can ping from R1 to R2, and R1 to R3, but not from R2 to R3.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

tech-airman

kpjungle,

The key words in that technology is called "frame relay." That means Data Link Layer frames are being sent out of and received on the frame relay interface. With inverse-arp enabled, inverse-arp will figure out the association between the IP address and the DLCI for the interface or subinterface. However, if you disable inverse-arp, then you have to manually configure something else that will associate an ip address with a DLCI. That is done with frame-relay map statements.

gojericho0

kpjungle, do you know some topology configurations that would require frame-relay mapping instead of inverse arp?

mikej412

When you disable inverse arp, it should stop sending, but if the other side of the connection hasn't been disabled you'll still receive and process the messages from the other side -- and create dynamic mappings. That's why it's a good idea to shutdown both sides of the connection when configuring frame-relay -- that prevents you from creating dynamic mappings (when both sides will have inverse arp disabled) while you are in the middle of your configuration.

kpjungle

gojericho0 wrote:

kpjungle, do you know some topology configurations that would require frame-relay mapping instead of inverse arp?

Not if inverse-arp is supported by both routers I dont. I was just skimming over the Frame-Relay chapter in the chapter 4 material for netacad, to help on my weak areas and decided to do a lab on it, to see how it works, if it would behave like the passive-interface commands for routing protocols, that doesnt send but will receive. In that chapter, there is a topology (hub and spoke, with two spoke routers) where the hub router is configured with static-mappings.

Anyways, for some reason if R1 config is the same, but R2 is configured with a subint with the same IP address and everything, R1 wont reply to in-arp requests..

Serial0/0(i): dlci 100(0x1841), pkt type 0x2000, datagramsize 284

However, if both are configured on the physical interface, the mentioned behaviour occurs:

00:47:43: Serial0/0(i): dlci 100(0x1841), pkt type 0x800, datagramsize 104
00:47:43: Serial0/0(o): dlci 100(0x1841), pkt type 0x800(IP), datagramsize 104

Just a curiousity.

However, the hub and spoke topology is still confusing me

gojericho0

kpjungle wrote:

gojericho0 wrote:

kpjungle, do you know some topology configurations that would require frame-relay mapping instead of inverse arp?

One scenerio is if you have more than one subinterface. The physical interface will notice that is receiving X amount of DLCIs, but will have no idea which subinterface it belongs to to map up the IP address unless you configure it.

Frame-relay does have a lot of terms and variations. I would definitely try and master it before moving on. BSCI assumes understanding of it and you still see it in production networks. Mostly all in the point-to-point variety however. Less configuration headaches that way.

kpjungle

gojericho0 wrote:

kpjungle wrote:

gojericho0 wrote:

kpjungle, do you know some topology configurations that would require frame-relay mapping instead of inverse arp?

One scenerio is if you have more than one subinterface. The physical interface will notice that is receiving X amount of DLCIs, but will have no idea which subinterface it belongs to to map up the IP address unless you configure it.

Frame-relay does have a lot of terms and variations. I would definitely try and master it before moving on. BSCI assumes understanding of it and you still see it in production networks. Mostly all in the point-to-point variety however. Less configuration headaches that way.

As far as I know, even in a scenario with more than one subinterface, direct mapping is not nessecary, since you will have to identify each subinterface with its own DLCI (frame-relay interface-dlci <number>), after that inverse-arp will work. (Since LMI does not support subinterfaces natively). The mapping part, as far as i kan tell, is only used when inverse-arp is not in use.

I think I have an OK understanding of it (frame-relay), this is just very detailed. The section of this particular frame-relay issue (inverse-arp), only takes up about 30 lines totally in my CCNA material.

If you were to fully master frame-relay before moving on to BSCI (which I started reading yesterday

), I think you would have to get a separate book on it. So I hope with this level of detail, im ready to tackle the BSCI study material?

Turgon

kpjungle wrote:

gojericho0 wrote:

kpjungle wrote:

gojericho0 wrote:

kpjungle, do you know some topology configurations that would require frame-relay mapping instead of inverse arp?

One scenerio is if you have more than one subinterface. The physical interface will notice that is receiving X amount of DLCIs, but will have no idea which subinterface it belongs to to map up the IP address unless you configure it.

Frame-relay does have a lot of terms and variations. I would definitely try and master it before moving on. BSCI assumes understanding of it and you still see it in production networks. Mostly all in the point-to-point variety however. Less configuration headaches that way.

As far as I know, even in a scenario with more than one subinterface, direct mapping is not nessecary, since you will have to identify each subinterface with its own DLCI (frame-relay interface-dlci <number>), after that inverse-arp will work. (Since LMI does not support subinterfaces natively). The mapping part, as far as i kan tell, is only used when inverse-arp is not in use.

I think I have an OK understanding of it (frame-relay), this is just very detailed. The section of this particular frame-relay issue (inverse-arp), only takes up about 30 lines totally in my CCNA material.

If you were to fully master frame-relay before moving on to BSCI (which I started reading yesterday ), I think you would have to get a separate book on it. So I hope with this level of detail, im ready to tackle the BSCI study material?

Inverse ARP only resolves network addresses of remote Frame-Relay connections that are directly connected. Inverse ARP alone cannot resolve the unreachability problems between two spokes in a partial mesh topology. To get over this you can go for a full mesh of PVCs or frame-relay map statements on the spokes.

Check out Bruce Caslow's Bridges, Routers and Switches for CCIEs. You should find this mostly forgotten book used on Amazon these days for the price of a happy meal. Still great coverage on frame relay and other things.

kpjungle

Inverse ARP only resolves network addresses of remote Frame-Relay connections that are directly connected. Inverse ARP alone cannot resolve the unreachability problems between two spokes in a partial mesh topology. To get over this you can go for a full mesh of PVCs or frame-relay map statements on the spokes.

Check out Bruce Caslow's Bridges, Routers and Switches for CCIEs. You should find this mostly forgotten book used on Amazon these days for the price of a happy meal. Still great coverage on frame relay and other things.

Thank you for the book suggestion!

The partial connectivity, is an example of this, what i mentioned earlier, that R1 (hub), could see and ping (R2) and (R3), both spokes, but they could not reach each other? (if i add a static route to go through R1 on both R2 and R3, they can ping each other however). I tried your suggestion regarding creating a frame-relay map on each of the spokes, but with no dice im afraid, they still need the layer 3 connectivity.

Edit: Got it working now. Think the dlci assignment from the FR switch was playing tricks on me. It works fine now with mappings on the spokes. Thanks for making me understand

gojericho0

Turgon wrote:

Check out Bruce Caslow's Bridges, Routers and Switches for CCIEs. You should find this mostly forgotten book used on Amazon these days for the price of a happy meal. Still great coverage on frame relay and other things.

I just picked me one up... it even came with a toy!

Turgon

kpjungle wrote:

Inverse ARP only resolves network addresses of remote Frame-Relay connections that are directly connected. Inverse ARP alone cannot resolve the unreachability problems between two spokes in a partial mesh topology. To get over this you can go for a full mesh of PVCs or frame-relay map statements on the spokes.

Check out Bruce Caslow's Bridges, Routers and Switches for CCIEs. You should find this mostly forgotten book used on Amazon these days for the price of a happy meal. Still great coverage on frame relay and other things.

Thank you for the book suggestion!

The partial connectivity, is an example of this, what i mentioned earlier, that R1 (hub), could see and ping (R2) and (R3), both spokes, but they could not reach each other? (if i add a static route to go through R1 on both R2 and R3, they can ping each other however). I tried your suggestion regarding creating a frame-relay map on each of the spokes, but with no dice im afraid, they still need the layer 3 connectivity.

Edit: Got it working now. Think the dlci assignment from the FR switch was playing tricks on me. It works fine now with mappings on the spokes. Thanks for making me understand

No problem. Often a bit of fun with frame switches