Frame-Relay inARP

How does inARP actually work? It doesn't send a broadcast packet out so how does inARP actually work? I realize that the router knows which DLCI and the goal is to learn the IP addresses associated with that DLCI. 

 

I have a specific example. 

Volume 1 Frame-Relay lab 2.9. 

Router 5 is setup with multipoint sub-interface connecting to R1 and R2. 

router 1 and router 2 both are using physical interfaces. You are also instructed to disable inverse-arp per dlci which I have done and obviously at that point router 1 and router 2 are not able to talk. 

When I remove the inverse arp on let's say r1, then inverse-arp does its thing and router 1 can now talk to r2. Now this is going through R5 so how does inverse arp work going through R5s multipoint interface? 

Comments

  • If you are using VOL I topology, FR switch has already been configured with all the interconnection DLCIs.

     

    Thus, when Inverse ARP in enabled on R1, it will advertise the interface ip address with all DLCI. That means R1 will advertise to R2,R3,R4 and R5. If no static mapping is configured in those routers, they will map R1 ip address with their respective DLCI.

     

    You can verify this on R1,R2,R3,R4,R5 with show frame-relay map command.

     

    Interestingly, disabling Inverse arp will stop the advertisment only in that router. But the recieved Inverse arp advertisments from another routers will be processed and mapped accordingly. 

  • How does inARP actually work?

    You might also find the following link useful - it's useful to take a look at RFCs - this one is quite short - http://www.rfc-editor.org/rfc/rfc2390.txt

     

    In addition inverse arp learned information can be seen - as stated by the previous poster by using show frame-relay map.  These entries will have the dynamic keyword as opposed to static for a particular address familar.  Remember inverse arp works per protocol you have configured under frame relay - but there is no support for IPv6.

  • Hi -

    The InARP process will pickup this other DLCI's in the full mesh of PVCs that are pre-provisoned so long as the interfaces are addressed.  Remember also that InARP only prevents the initiating of the InARP, and the reply cannot be turned off.  If you only turn off InARP on one side of the link, you will find that the InARP process initiated by the other side will allow both ends to actually map their requisite PVC.  If there is a static mapping for a DLCI the static mapping will prevent InARP from being initiated as well.

    As for the question below:

    When I remove the inverse arp on let's say r1, then inverse-arp does its thing and router 1 can now talk to r2. Now this is going through R5 so how does inverse arp work going through R5s multipoint interface? 

    The pre-provisioned FRS has a full-mesh of PVCS in place.  If you just leave on InARP on all the main interfaces and address each one, you can issue the show frame-relay map command and see the dynamic mappings.

    r/w




    On Aug 20, 2012, at 1:24 AM, justin0104 <[email protected]> wrote:

    How does inARP actually work? It doesn't send a broadcast packet out so how does inARP actually work? I realize that the router knows which DLCI and the goal is to learn the IP addresses associated with that DLCI. 

     

    I have a specific example. 

    Volume 1 Frame-Relay lab 2.9. 

    Router 5 is setup with multipoint sub-interface connecting to R1 and R2. 

    router 1 and router 2 both are using physical interfaces. You are also instructed to disable inverse-arp per dlci which I have done and obviously at that point router 1 and router 2 are not able to talk. 

    When I remove the inverse arp on let's say r1, then inverse-arp does its thing and router 1 can now talk to r2. Now this is going through R5 so how does inverse arp work going through R5s multipoint interface? 




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • …and so my response appears to be a repeat - sorry gang - I didn't see the other replies before I sent mine.


    On Aug 20, 2012, at 2:50 AM, Robecho <[email protected]> wrote:

    If you are using VOL I topology, FR switch has already been configured with all the interconnection DLCIs.

     

    Thus, when Inverse ARP in enabled on R1, it will advertise the interface ip address with all DLCI. That means R1 will advertise to R2,R3,R4 and R5. If no static mapping is configured in those routers, they will map R1 ip address with their respective DLCI.

     

    You can verify this on R1,R2,R3,R4,R5 with show frame-relay map command.

     

    Interestingly, disabling Inverse arp will stop the advertisment only in that router. But the recieved Inverse arp advertisments from another routers will be processed and mapped accordingly. 




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • How does inARP actually work? It doesn't send a broadcast packet out so how does inARP actually work? I realize that the router knows which DLCI and the goal is to learn the IP addresses associated with that DLCI. 

    Check out this discussion

    http://ieoc.com/forums/p/15986/164137.aspx#164137

  • you question is not clearly stated but i shall conceive to contrive (ha!) a reply!

     

     

    after  you encapsulate a interface for frame-relay (encap frame-relay) the local switch learns all the DLCIs thru the LMI.

    once IP is configured over an interface an inarp request is sent over all DLCIs learned over the interface.

    Inarp requests can be disabled but inarp replies CANNOT be disabled.

    you can perform Layer 2 to Layer 3 mapping with BOTH inarp requests and replies.

    inarp requests will not be sent for a PVC if a static mapping for that DLCI also exists (but it will reply to inarp requests)

    inarp is link local and CANNOT be forwarded between different circuits.

    you can solve spoke to spoke communication issues in 2 ways

    a) at layer 2 you can map between the spokes

    b) at layer 3 you can create host routes between the spokes

     

    MAKE SURE THE 2 SPOKES IE ROUTER 1 AND ROUTER 2 ARE NOT MAPPING DIRECTLY BY CHECKING THE FRAME MAP COMMAND since the INE frame switch configs are fully meshed.

    (if they are then>>>shutdown interface and then clear frame inarp and dont no shut it till you are DONE with all configs to save yourself some teeth grinding)

     

    each should only be mapped to R5

     

     

     

    HTH

     

     

     

    Tox!

Sign In or Register to comment.