EIGRP Issue

R1, SW1 and SW4 are all in EIGRP AS 100.

R1 is configured:

router eigrp 100

 network 183.1.17.1 0.0.0.0

SW1 is configured

router eigrp 100

network 183.1.17.7 0.0.0.0

However, SW4 does not know about the 183.1.17.0/24 network. Why is this?

 

Comments

  • Hi there,

    You'll also need a network statment on Sw1 for 183.1.107.0/24 and the same on sw4 - as it stands you've only enabled EIGRP on R1 f0/0 and Sw1 f0/1 - you also need to enable it on the link between Sw1 and Sw4..

    Hope I haven't misunderstood your question.

    Dan

  • I did not post the full configuration for brevity. My configuration matches what is in the answers on pages 37-38 of the lab answer manual under task 3.6

    The problem is that the network 183.1.17.0/24 is not propagated by EIGRP to SW4.

  • OK fair enough - is it in Sw4's  routing table by some other protocol? If not you'll probably need to post more (maybe a show ip eigrp topology from both switches) to get an idea why..

  • No it is not in SW4's routing table by any other protocol.

    Here are my thoughts on the issue:

    The EIGRP adjacency is formed without problems between R1 and SW1 with the commands:

     

    R1

    183.1.17.1 0.0.0.0

    SW1

    183.1.17.7 0.0.0.0

     

    However, SW1 will not advertise the 183.1.17.7 0.0.0.0 network onto SW4 because SW1 sees it as directly connected from its perspective.

     

    If  I change the config on SW1 to 183.1.17.0 0.0.0.255 then EIGRP sees that R1 is not directly connected to SW4 (the network is bigger than 1 IP address) and passes the 183.1.17.0 route to it.

     

    This is reason for this issue is that the 0.0.0.0 inverse mask in EIGRP tells the router to only pass the interface exactly how it is. For example, 183.1.17.7 0.0.0.0 only passes 183.1.17.7 and its associated subnet mask which is /24 due to the fact that EIGRP includes the subnet mask in its updates. However, this does not mean that anything other than 183.1.17.7 is advertised from the router or switches perspective.


    I may be completely wrong in this logic. I am happy to post some show commands if you don't agree with my reasoning.
  • Turned out to be an IOS bug in c2600-adventerprisek9-mz.124-13b.bin

  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    A note on this, the "network 1.2.3.4 0.0.0.0" statement doesn't mean to
    "advertise" 1.2.3.4, it means that the interface with that IP address
    has EIGRP enabled on it.  There is no effective difference from saying
    "network 1.2.3.0 0.0.0.255" or "network "1.2.3.4 0.0.0.0".  The only
    real difference is that if you make a mistake with the more specific
    network statement you could end up troubleshooting a typo, where if you
    do the whole subnet this is less likely.





    HTH,



    Brian McGahan, CCIE #8593 (R&S/SP/Security)

    [email protected]

     

    Internetwork Expert, Inc.

    http://www.InternetworkExpert.com

    Toll Free: 877-224-8987 x 705

    Outside US: 775-826-4344 x 705

    Online Community: http://www.IEOC.com

    CCIE Blog: http://blog.internetworkexpert.com






    mrcobbar wrote:

    No it is not in SW4's routing table by any other protocol.

    Here are my thoughts on the issue:

    The EIGRP
    adjacency is formed without problems between R1 and SW1 with the
    commands:

     

    R1

    183.1.17.1
    0.0.0.0

    SW1

    183.1.17.7
    0.0.0.0

     

    However,
    SW1 will not advertise the 183.1.17.7 0.0.0.0 network onto SW4 because
    SW1 sees it as directly connected from its perspective.

     

    If 
    I change the config on SW1 to 183.1.17.0 0.0.0.255
    then EIGRP sees that R1 is not directly connected to SW4 (the network
    is bigger than 1 IP address) and passes the 183.1.17.0 route to it.

     

    This is
    reason for this issue is that the 0.0.0.0 inverse mask in EIGRP tells
    the router to only pass the interface exactly how it is. For example,
    183.1.17.7 0.0.0.0 only passes 183.1.17.7 and its associated subnet
    mask which is /24 due to the fact that EIGRP includes the subnet mask
    in its updates. However, this does not mean that anything other than
    183.1.17.7 is advertised from the router or switches perspective.


    I may be
    completely wrong in this logic. I am happy to post some show commands
    if you don't agree with my reasoning.







    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">






    Hi Brian,

     

    I thought network 1.2.3.4 0.0.0.0 is the preferred
    way as it is most specific. It is also what is in the solution guide. Is this
    correct?

     

    Steve.

    ----- Original Message -----



    Sent: Wednesday, July 30, 2008 11:51
    PM

    Subject: Re: [IEWB-RS-VOL2-V4-LAB1] EIGRP
    Issue


    A note on this, the "network 1.2.3.4 0.0.0.0" statement doesn't
    mean to "advertise" 1.2.3.4, it means that the interface with that IP address
    has EIGRP enabled on it.  There is no effective difference from saying
    "network 1.2.3.0 0.0.0.255" or "network "1.2.3.4 0.0.0.0".  The only real
    difference is that if you make a mistake with the more specific network
    statement you could end up troubleshooting a typo, where if you do the whole
    subnet this is less likely.


    HTH,


    Brian McGahan, CCIE #8593
    (R&S/SP/Security)
    [email protected]
     
    Internetwork
    Expert, Inc.
    http://www.InternetworkExpert.com
    Toll
    Free: 877-224-8987 x 705
    Outside US: 775-826-4344 x 705
    Online
    Community: http://www.IEOC.com
    CCIE Blog:
    http://blog.internetworkexpert.com


    mrcobbar
    wrote:

    No it is not in SW4's routing table by any other protocol.

    Here are my thoughts on the issue:

    The EIGRP
    adjacency is formed without problems between R1 and SW1 with the
    commands:

     

    R1

    183.1.17.1
    0.0.0.0

    SW1

    183.1.17.7
    0.0.0.0

     

    However, SW1 will
    not advertise the 183.1.17.7 0.0.0.0 network onto SW4 because SW1 sees it as
    directly connected from its perspective.

     

    If 
    I change the config on SW1 to 183.1.17.0 0.0.0.255 then
    EIGRP sees that R1 is not directly connected to SW4 (the network is bigger
    than 1 IP address) and passes the 183.1.17.0 route to it.

     

    This is reason for
    this issue is that the 0.0.0.0 inverse mask in EIGRP tells the router to
    only pass the interface exactly how it is. For example, 183.1.17.7 0.0.0.0
    only passes 183.1.17.7 and its associated subnet mask which is /24 due to
    the fact that EIGRP includes the subnet mask in its updates. However, this
    does not mean that anything other than 183.1.17.7 is advertised from the
    router or switches perspective.


    I may be
    completely wrong in this logic. I am happy to post some show commands if you
    don't agree with my reasoning.



    Internetwork Expert -
    The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

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



    Internetwork
    Expert - The Industry Leader in CCIE
    Preparation
    http://www.internetworkexpert.com

    Subscription
    information may be found
    at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Just jumping in here --  us old guys learned to add the subnet (ex. network 1.2.3.4 0.0.0.255). I'm not sure what the reasoning was. Personally, I do it that way so I can cut-n-paste the same entry into all the participating routers. But like Brian said, there is no difference whatsoever -- you are simply specifying the range of addresses that will be included in the routing protocol. You could do a 'network 0.0.0.0 255.255.255.255', which includes all the interfaces and then do a "passive-interface default' and select the only the interfaces you want to route. I suppose there's all kinds of ways to do the same thing.

  • Hi Bam,

    Your absolutely right. The inverse mask can be configured a number of ways. Have a look at the 3.11 post and let me know what you think.

    Regards,

    Mr Cobbar

Sign In or Register to comment.