EIGRP reply message blocking

I am wondering if there is a way to block only the EIGRP reply messagage?

I am trying to see the result of a SIA route along with the SIA-query message. The way I have understood the SIA-query message is that it is supposed to be sent out to all the neighbors that have not replied to the query message yet when the SIA timter is at the half-way point. This is to allow routers to remove only the SIA route and not reset the neighbor relationships. The problem i am having is that when I use an extended access list (below) I am able to block the eigrp packets but since all of the packets except the hellos are blocked. Since the ACK packets are needed to respond to the SIA-query, the neighbor session is always reset either because of the SIA timer ending or the unicast reply's reaching the 16 retry limit which tears down the session. So does anyone know how to do this?

Ip access-list extended EIGRP

permit eigrp any host 224.0.0.10

deny eigrp any any

Thanks

Comments

  • Hi.

    You could try using Flexible Packet Matching - but I think it would be too much effort for a test.

    Also, I think that when SIA occurs, the router is supposed to clear the neighbor that did not reply to the query.

  • I thought about FPM as well but would like an easier way before I look into that. I was reading the CCNP route book by Odom and came across the SIA-query message. I thought the router would always reset the neighbor but according to the book, ever since IOS 12.2 the router will try and prevent this by sending a SIA-query message to all the neighbors that have not replied to the query. Supposedly this occurs at 90 secs by default when the active timer is 3 mins.

  • Hi,
    actually you can test SIA by applying an ACL on an interface and blocking all EIGRP packets.
    But you also need to set the hold timer higher than the SIA timer. This prevents your
    routers from declearing the other neighbor as dead before the SIA timer expires.

    Best regards,
    Jochen
    <br />
    Here is a short explanation on how I tested it:
    <br />
    Topology
    --------
    150.1.6.0/24
     |
     lo0
     |
    [R6]-f0/0.146-----f0/1-[R4]-s0/1----s0/1-[R5]
    <br />
    Configs
    -------
    <br />
    hostname R6
    !
    router eigrp 10
     no auto-summary
     network 150.1.6.6 0.0.0.0
     network 155.1.146.6 0.0.0.0
    !
    interface FastEthernet0/0.146
     ip address 155.1.146.6 255.255.255.0
    !
    interface Loopback0
     ip address 150.1.6.6 255.255.255.0
    hostname R4
    !
    router eigrp 10
     no auto-summary
     network 150.1.4.4 0.0.0.0
     network 155.1.45.4 0.0.0.0
     network 155.1.146.4 0.0.0.0
     ! Set SIA timer to 1 minute because we are impatient
     timers active-time 1
    !
    interface FastEthernet0/1
     ip address 155.1.146.4 255.255.255.0
    !
    interface Serial0/1
     ip address 155.1.45.4 255.255.255.0
     ip hold-time eigrp 10 600
    <br />
    hostname R5
    !
    ip access-list extended ACL_EIGRP
     deny   eigrp any any
     permit ip any any
    !
    router eigrp 10
     no auto-summary
     network 150.1.5.5 0.0.0.0
     network 155.1.45.5 0.0.0.0
    !
    interface Serial0/1
     ip address 155.1.45.5 255.255.255.0
     ip hold-time eigrp 10 600
    <br />
    <br />
    SIA Test and Verification
    -------------------------
    <br />
    1) Enable debugging on R4
    R4# debug eigrp packets SIAquery SIAreply query
    EIGRP Packets debugging is on
        (QUERY, SIAQUERY, SIAREPLY)
    <br />
    2) Block EIGRP on R5's Serial0/1 interface
    
    Neighbors will stay up since our hold timer is configured for 10 minutes (600 secs) on the
    serial link between R4 and R5
    <br />
    R5#conf t
    R5(config)#int s0/1
    R5(config-if)#ip acce
    R5(config-if)#ip access-group ACL_EIGRP in
    3) Shutdown Loopback0 on R6 to trigger a query for 150.1.6.0/24 which propagates from R6 to R4 to R5
    <br />
    R6# conf t
    R6(config)#int lo 0
    R6(config-if)#shut
    4) Wait 1 minute (we changed the timer from 3 to 1) on R4's console for the SIA debug messages to show up
    *Mar  1 00:06:26.075: DUAL: dest(150.1.6.0/24) active
    *Mar  1 00:06:26.079: DUAL: send SIAQUERY(r40/n40) about 150.1.6.0/24 to 155.1.45.5
    <br />
    Have a look "show ip eigrp neighbors detail". Without the "detail" keyword you would only see that the queue
    count increases. Which basically means that there are some unacklowledged EIGRP messages in
    the queue for a neighbor.
    <br />
    R4#sh ip eigrp neighbors detail
    IP-EIGRP neighbors for process 10
    H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                                (sec)         (ms)       Cnt Num
    1   155.1.45.5              Se0/1            599 00:03:48   28  5000  2  5	<-- Queue count
       Version 12.4/1.2, Retrans: 12, Retries: 12, Prefixes: 1			    increases
        QUERY seq 13 ser 6-6 Sent 30152 Sequenced
        SIAQUERY seq 14 ser 7-7 Sequenced						<-- Neighbor in
    										    SIA
    R4#sh ip eigrp traffic
    IP-EIGRP Traffic Statistics for AS 10
      Hellos sent/received: 966/960
      Updates sent/received: 27/12
      Queries sent/received: 38/2
      Replies sent/received: 2/3
      Acks sent/received: 11/15
      SIA-Queries sent/received: 1/0			<--- One SIA query sent
      SIA-Replies sent/received: 0/0
      Hello Process ID: 257
      PDM Process ID: 244
      IP Socket queue:   0/2000/3/0 (current/max/highest/drops)
      Eigrp input queue: 0/2000/3/0 (current/max/highest/drops)
    
  • Hi Jochen,

    That was a great reply and was similar to what I was labbing up. The two show commands were one part of what I was missing to see the SIAquery stats. After looking at the solution though it seemed to have the same problem that I am having with seeing the actual SIAquery accomplish the ultimate task of not tearing down the neighborship at the end of the active timer. This is of course due to all of the eigrp packets being blocked from the access list which prevents the ACK packet response to the SIAquery.

     

    So I was able to see the SIAquery messages using the debug and show commands you posted but I was not able to see the intended result of the SIAquery.

  • Great posts guys!

    Thanks!

  • Hi guys,

    In Jochen Bartl's scenario, it is infact impossible to see the SIA reply in R4/R6. This is because the active timer is only reduced in R4 but not in R6 which is still the default 180 seconds. 

     

    As you may all know, SIA query is sent when the SIA-retransmit timer expires which is by default set to 1/2 of active timer.

     

    So R6 will send the SIA-query 90 seconds after it first send the query

     

    But before it do, R4 will declare the route as stuck-in-active and reply to R6 that it does not have a route ( and tearing down the R5 neighbourship). This is because R4 will retransmit the query to R5 for about 14 times every 5 seconds ( totally for 70 seconds after the first query is recieved from R6).

     

    To see the SIA-reply on R6/R4, change the active timer to 1 minute in both routers and you should see the following debug output:

     

    R6


    *Mar  1 00:41:12.215: EIGRP: Enqueueing SIAQUERY on Serial0/1 nbr 136.1.23.4 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 115-115

    *Mar  1 00:41:12.231: EIGRP: Sending SIAQUERY on Serial0/1 nbr 136.1.23.4

    *Mar  1 00:41:12.235:   AS 100, Flags 0x0, Seq 40/55 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 115-115

    *Mar  1 00:41:12.295: EIGRP: Received SIAREPLY on Serial0/1 nbr 136.1.23.4

    *Mar  1 00:41:12.299:   AS 100, Flags 0x0, Seq 58/40 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

     

    R4


    *Mar  1 00:40:01.835: EIGRP: Received SIAQUERY on Serial1/3 nbr 136.1.23.6

    *Mar  1 00:40:01.839:   AS 100, Flags 0x0, Seq 40/55 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

    *Mar  1 00:40:01.859: EIGRP: Enqueueing SIAREPLY on Serial1/3 nbr 136.1.23.6 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 118-118

    *Mar  1 00:40:01.875: EIGRP: Sending SIAREPLY on Serial1/3 nbr 136.1.23.6

    *Mar  1 00:40:01.875:   AS 100, Flags 0x0, Seq 58/40 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 118-118

     

     

  • So I was able to see the SIAquery messages using the debug and show commands you posted but I was not able to see the intended result of the SIAquery.

    Dear armyusde,

    Here is a quote from the book  Routing TCP/IP, Volume I, Second Edition  by Jeff Doyle and Jennifer Carroll


    "The SIA-retransmit timer does two things. If neighbors are
    responding to SIA-queries, large networks are given more time to respond to
    address queries. If neighbors are not responding, the neighbor is reset. Only
    the router that is not receiving responses from its neighbor will reset the
    adjacency. Before the SIA-retransmit timer was introduced, any router that did
    not receive a response to an active query after the Active timer expired would
    reset the neighbor adjacency, even if the problem was somewhere downstream in
    the network."

  • ...

    This is because the active timer is only reduced in R4 but not in R6 which is still the default 180 seconds. 

    ...


     

    Robecho, thanks for pointing that out and the additional debugs. I've set the active timer on all routers in an initial test but forgot it later somehow.

     

    Regards,

    Jochen

  • Thanks for the reply. The quote from Routing TCP/IP  was kind of confusing about what happens to the neighbor that does reply until I read the explanation before the part you posted. I found out that if a SIA reply is received then the router that sent out the SIA-query will reset the active timer and the SIA query timer. This SIA query is sent at a maximum of three times if a SIA reply is always received. If at the third SIA query message a reply is received, the timers are not reset and at the end of the active timer the neighborship is reset. The default time for a SIA query is 90 secs so 90 X 3 is 270 and the final 90 seconds to complete the active timer is added to give a total of 360 secs. So at most the default time allowed is 6 mins.

    So as the quote said, this gives larger networks more time to address queries. The book by Odom didn't go into that level of detail and only stoped at saying that the neighborship is not torn down if a reply is received. This is true but is not a definate action as the timers are just reset. So that makes sense as to why I wasn't getting my expected result of the neighborship not being torn down.

     

    Thanks for the help

  • dear bro,

     

    i have little trick for that and i hope it works, since neighbors are forming adjacencies through multicast packets, you can block unicast packets at the inside interface for the router which supposed to receive the reply packet, since reply packets are unicast, you will still be able to maintain adjacencies and you wil send query but tou wont receive reply, i hope your try this solution and send your feedback

     

    thanks

  • Hi,

     

    Good idea. I would turn NSF on as well.

Sign In or Register to comment.