cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
527
Views
7
Helpful
10
Replies

Frame Relay Multipoint ?

philth_123_2
Level 1
Level 1

Hi,

I have set up a lab for hub and spoke F/R using multipoint. I have 3 routers Top, Middle (Hub) and bottom. I have configured 2 PVC's between Top/Middle and Bottom/Middle.

I have got full connectivity between all routers, however, I have had to place f/r map statements on all routers i.e 2 on the multipoint sub interface on the Hub i.e middle and one on each of the spokes. Is there anyway to utilise inverse Arp in this multipoint scenario ? I cannot appear to get inverse-arp to work in this scenario.

Any links to configs etc appreciated.

PS: I always rate posts.

Cheers,

Phil.

2 Accepted Solutions

Accepted Solutions

Hi Phil,

As you as you configure a static map entry, inverse ARP is disabled for that protocol on that DLCI. In your case, the static 'frame-relay map' statements on the Top and Bottom routers mean that InvARP is disabled on these DLCIs.

Paresh

View solution in original post

Phil,

Inverse-ARP works in the same way on multipoint interfaces as it does on physical interfaces. In the scneario you described, did you have static mappings on the hub router for the Top and Bottom routers. I would deduce that you did not and so what happened was that the hub router sent InvARP requests to the Top and Bottom routers which resulted in the Top/Bottom routers caching the information learned from the received InvARPs from the hub. When InvARP is disabled on an interface, that prohibits the interface from sending out InvARPs - it does not stop it responding to received InvARPs and caching the received information.

Hope that helps - pls rate the post if it does.

Paresh

View solution in original post

10 Replies 10

Richard Burts
Hall of Fame
Hall of Fame

Phil

I can understand the 2 maps on the hub. I would think that both spokes would also have 2 maps.

I interpret from your post that top has connectivity to bottom. Is this correct? (and if there is a single map on top, what does the map say?)

One of the weaknesses in multipoint frame relay is what is required to get connectivity between the spokes (and especially between the LANs that are attached to the spokes). If you use Inverse ARP then each spoke would easily learn the hub (since they are talking directly to it) but the difficulty is how the spokes would learn each other since they can not talk to each other directly but must go through the hub).

HTH

Rick

HTH

Rick

Rick,

Yes top has connectivity to bottom.

The single map on top maps to the remote ip of bottom and likewise bottom maps back to top giving full connectivity through the hub.

I guess I must have missed the dynamic map from top to middle/hub and bottom to middle/hub.

When I took the mappings of the sub-interface on middle the physical S0 kicked in to form the PVC's with an address of 0.0.0.0 and I was thinking why did inverse-arp not kick in instead on the sub-interface ?

This is where I am confused. Is it the fact that the DLCI's local to the sub-interface have been removed with the removal of the map statements or does inverse-arp not run on sub-interfaces ?

(I'll try and nail this tomorrow as the pub is calling)

Regards,

Phil.

Hi,

I have attached the configs for Top, Middle/hub and bottom along with 'sh frame map' for top and bottom. As can be seen, mappings have been created only for the static entries. Shouldn't there be dynamic entries for Top to Middle and Bottom to middle respectively ?

Regards,

Phil.

Hi Phil,

As you as you configure a static map entry, inverse ARP is disabled for that protocol on that DLCI. In your case, the static 'frame-relay map' statements on the Top and Bottom routers mean that InvARP is disabled on these DLCIs.

Paresh

A bit more ...

When you configure a 'frame-relay map ip' statement, Inverse ARP will be disabled for the IP protocol on the specified DLCI. It does not really matter what the mapped IP address is. So in the scenario, you have, you would need to configure 2 such statements on the top and bottom routers as such:

top:

frame-relay map ip 192.1.1.3 100 broadcast

frame-relay map ip 192.1.1.2 100 broadcast

Hope that helps - pls rate the post if it does.

Paresh

Paresh,

Thanks for that.

I have a lab scenario that appears to contradict this rule. i.e inverse-arp becoming disabled on the specified DLCI.

Using physical interfaces S0 on top, middle and bottom. Top/middle and Bottom/middle resolve dynamically via inverse arp. I then add static mappings for top to bottom and bottom to top to resolve the spoke connectivity and I have full connectivity. Now, if inverse arp becomes disabled I would expect that on rebooting my routers I would be left with just the spokes able to communicate however, both the static and the dynamic routes appear.

Does inverse arp only become disabled for point-to-point / point-to-multipoint as it doesn't appear to get disabled on a physical interface ?

Regards,

Phil.

Paresh,

Continuing on the above theme i.e F/R setup with physical interfaces. It appears that when I clear the frame-relay-inarp cache on Top or Bottom the entry is not relearned on these routers.

However, when I clear the Middle/Hub inarp cache the dynamic entries then appear in the spoke routers Top and Bottom.

Regards,

Phil.

Would anyone like to comment on my last two observations ?

rawatmohinder
Level 1
Level 1

hi Phil,

I am not able to understand ur topology. can u put the diagram.

bcoz it is not clear which router u r using as frame-realy switch.

ONe more thing...

if you enable static mapping on one dlci,it didn,t mean that inverse-arp will be disabled.

inverse-arp will still work.

we use static mapping if inverse-arp is not able to reach the network.

Thanks

Mahi

Phil,

Inverse-ARP works in the same way on multipoint interfaces as it does on physical interfaces. In the scneario you described, did you have static mappings on the hub router for the Top and Bottom routers. I would deduce that you did not and so what happened was that the hub router sent InvARP requests to the Top and Bottom routers which resulted in the Top/Bottom routers caching the information learned from the received InvARPs from the hub. When InvARP is disabled on an interface, that prohibits the interface from sending out InvARPs - it does not stop it responding to received InvARPs and caching the received information.

Hope that helps - pls rate the post if it does.

Paresh

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: