11 Replies Latest reply: Aug 20, 2019 6:30 AM by Ramabolu RSS

    What happened here with EIGRP routing?

    Learner

      Hello all,

       

      I have configured 2.2.2.2/24 on both R2 and R4. the middle router R1 has equal distance to reach both sides.

       

      Why do all pings from R1 to 2.2.2.2 went to R4?

       

      eigrp22.jpg

       

      R1#

      R1#show ip route

      Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

             D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

             N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

             E1 - OSPF external type 1, E2 - OSPF external type 2

             i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

             ia - IS-IS inter area, * - candidate default, U - per-user static route

             o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

             + - replicated route, % - next hop override


      Gateway of last resort is not set


            2.0.0.0/24 is subnetted, 1 subnets

      D        2.2.2.0 [90/130816] via 192.168.12.2, 00:00:08, GigabitEthernet0/0

                       [90/130816] via 10.0.0.4, 00:00:08, GigabitEthernet2/0

            10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

      C        10.0.0.0/24 is directly connected, GigabitEthernet2/0

      L        10.0.0.1/32 is directly connected, GigabitEthernet2/0

            192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks

      C        192.168.12.0/24 is directly connected, GigabitEthernet0/0

      L        192.168.12.1/32 is directly connected, GigabitEthernet0/0

      R1#

      R1#

      R1#ping 2.2.2.2 rep 2

      Type escape sequence to abort.

      Sending 2, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

      !!

      Success rate is 100 percent (2/2), round-trip min/avg/max = 16/16/16 ms

      R1#

      R1#ping 2.2.2.2 rep 2

      Type escape sequence to abort.

      Sending 2, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

      !!

      Success rate is 100 percent (2/2), round-trip min/avg/max = 4/10/16 ms

      R1#

      R1#ping 2.2.2.2 rep 2

      Type escape sequence to abort.

      Sending 2, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

      !!

      Success rate is 100 percent (2/2), round-trip min/avg/max = 4/10/16 ms

      R1#


      eigrp23.jpg

        • 1. Re: What happened here with EIGRP routing?
          Martin

          router knows you trying to trick him , ha ha 

           

          show ip cef 2.2.2.2   what do u see ?

          • 2. Re: What happened here with EIGRP routing?
            Learner

            Martin wrote:

             

            router knows you trying to trick him , ha ha 

             

            show ip cef 2.2.2.2  what do u see ?

             

            R1#

            R1#show ip cef 2.2.2.2

            2.2.2.0/24

              nexthop 10.0.0.4 GigabitEthernet2/0

              nexthop 192.168.12.2 GigabitEthernet0/0

            R1#

            • 3. Re: What happened here with EIGRP routing?
              Martin

              ok, so probably depends on your load balance method.  i think default is per-destination , so you need to change it to be per source-destination hash.  note different ios support different methods of load balance

              i think command is ip cef load-sharing  , try it using different method

              • 4. Re: What happened here with EIGRP routing?
                Ing_Percy

                Hi!

                 

                The effect is by CEF

                 

                In CCIE book:

                CEF supports two modes of load sharing: per-packet and per-destination.

                With per-packet load sharing, packets destined to a destination network are distributed across multiple paths in a packet-by-packet fashion.

                 

                With the per-destination mode, the CEF actually takes the source and destination IP address and optionally other data to produce a hash value that identifies the particular path to carry the packet. In effect, for a particular source and destination pair, all packets flow through a single path. Other particular source/destination address combinations toward the same destination network can produce a different hash and thus be forwarded over a different path.

                ...

                The per-destination load-sharing mode is the default (hardware-based CEF implementations might not support the per-packet load sharing mode), and in general, it is preferred because it avoids packet reordering within a single conversation.

                ...

                The particular method of per-packet or per-destination load sharing can be activated on egress interfaces of a router using the ip load-share { per-destination | per-packet } interface-level command.

                The availability of this command might be limited depending on the hardware capabilities of the device. Often, multilayer switches performing hardware-accelerated switching do not support this command while software-based ISR routers do.


                Source: https://books.google.com.pe/books?id=KQuaBQAAQBAJ&pg=RA1-PT283&lpg=RA1-PT283&dq=With+per-packet+load+sharing,+packets+de…


                In GNS3

                interface-cef-gns3.JPG

                Now, about "load-sharing" in packet generated by a local router, it is the comment by Peter Paluch:

                 

                "....My understanding is that you have configured per-packet load balancing in CEF for that interface if that interface uses CEF. You may not have CEF activated on the interface but if it was, it would be configured for per-packet load balancing, hence the output of the show cef interface command.

                 

                Now, you indicated that the per-packet load balancing is actually happening. How are you generating the flow of packets that are being per-packet load balanced? Locally originated traffic (i.e. packet originated by the sending router) are, to my best knowledge, always process-switched and therefore subject to per-packet load balancing regardlesss of the switching method of interfaces. So if you were sending, say, pings from the same router on which you changed the CEF interface settings, you will still see the packets being load balanced - but not because of CEF but rather because of process switching...."


                Source: https://community.cisco.com/t5/routing/is-per-packet-load-sharing-only-by-cef-is-this-something-that/td-p/1902826


                Regards!

                • 5. Re: What happened here with EIGRP routing?
                  Nkwo Peter Akachukwu

                  I like your statement martin. Ok

                  • 6. Re: What happened here with EIGRP routing?
                    Steven Davidson

                    Did you try traceroute instead?  To see whether or not the behavior is the same.

                     

                     

                    R2#show ip cef 1.1.1.1

                    1.1.1.1/32

                      nexthop 12.0.0.1 GigabitEthernet0/0.12

                      nexthop 23.0.0.3 GigabitEthernet0/0.23

                    R2#show ip access-list

                    Extended IP access list 100

                        10 permit icmp any host 1.1.1.1 (6 matches)

                    Extended IP access list 101

                        10 permit udp any host 1.1.1.1 (12 matches)

                    R2#debug ip packet 100 detail

                    IP packet debugging is on (detailed) for access list 100

                    R2#ping 1.1.1.1 repeat 2 time 1

                    Type escape sequence to abort.

                    Sending 2, 100-byte ICMP Echos to 1.1.1.1, timeout is 1 seconds:

                    !!

                    Success rate is 100 percent (2/2), round-trip min/avg/max = 20/22/24 ms

                    R2#show log | inc sending

                    *Aug 14 07:23:31.327: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet0/0.23 nh 23.0.0.3 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0

                    *Aug 14 07:23:31.327: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.23), len 100, sending

                    *Aug 14 07:23:31.327: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.23), len 100, sending full packet

                    *Aug 14 07:23:31.351: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet0/0.23 nh 23.0.0.3 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0

                    *Aug 14 07:23:31.351: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.23), len 100, sending

                    *Aug 14 07:23:31.351: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.23), len 100, sending full packet

                    R2#clear log

                    Clear logging buffer [confirm]

                    R2#debug ip packet 101 detail

                    IP packet debugging is on (detailed) for access list 101

                    R2#traceroute 1.1.1.1 probe 2 time 1 num

                    Type escape sequence to abort.

                    Tracing the route to 1.1.1.1

                    VRF info: (vrf in name/id, vrf out name/id)

                      1 12.0.0.1 8 msec

                        23.0.0.3 16 msec

                    R2#show log | inc sending

                    *Aug 14 07:23:53.843: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet0/0.12 nh 12.0.0.1 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0

                    *Aug 14 07:23:53.843: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.12), len 28, sending

                    *Aug 14 07:23:53.843: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.12), len 28, sending full packet

                    *Aug 14 07:23:53.863: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet0/0.23 nh 23.0.0.3 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0

                    *Aug 14 07:23:53.863: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.23), len 28, sending

                    *Aug 14 07:23:53.863: IP: s=23.0.0.2 (local), d=1.1.1.1 (GigabitEthernet0/0.23), len 28, sending full packet

                    • 7. Re: What happened here with EIGRP routing?
                      Mustafa

                      I've just tested with eve-ng and Cisco IOL.

                      here are the results:

                      ===========

                      R1#sh ip cef 2.2.2.0 detail

                      2.2.2.0/24, epoch 0, per-destination sharing

                        nexthop 10.0.0.4 Ethernet0/2

                        nexthop 192.168.12.2 Ethernet0/0

                      R1#

                       

                       

                       

                      *Aug 14 13:27:08.034: FIBipv4-packet-proc: route packet from (local) src 10.0.0.1 dst 2.2.2.2

                      *Aug 14 13:27:08.034: FIBfwd-proc: Default:2.2.2.0/24 process level forwarding

                      *Aug 14 13:27:08.034: FIBfwd-proc: depth 0 first_idx 0 paths 2 long 0(0)

                      *Aug 14 13:27:08.034: FIBfwd-proc: try path 0 (of 2) v4-anh-10.0.0.4-Et0/2 first short ext 0(-1)

                      *Aug 14 13:27:08.034: FIBfwd-proc: v4-anh-10.0.0.4-Et0/2 valid

                      *Aug 14 13:27:08.034: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/2 nh 10.0.0.4 deag 0 chg_if 0 via fib 0 path type attached nexthop

                      *Aug 14 13:27:08.034: FIBfwd-proc: packet routed to Ethernet0/2 10.0.0.4(0)

                      *Aug 14 13:27:08.034: FIBipv4-packet-proc: packet routing succeeded

                      *Aug 14 13:27:08.034: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/2 nh 10.0.0.4 uhp 1 deag 0 ttlexp 0

                      *Aug 14 13:27:08.034: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if Ethernet0/2 nh 10.0.0.4 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0

                      *Aug 14 13:27:08.034: IP: s=10.0.0.1 (local), d=2.2.2.2 (Ethernet0/2), len 100, sending

                      *Aug 14 13:27:08.034:     ICMP type=8, code=0

                      *Aug 14 13:27:08.035: IP: s=10.0.0.1 (local), d=2.2.2.2 (Ethernet0/2), len 100, sending full packet

                      *Aug 14 13:27:08.035:     ICMP type=8, code=0

                      *Aug 14 13:27:08.035: IP: s=2.2.2.2 (Ethernet0/2), d=10.0.0.1, len 100, input feature

                      *Aug 14 13:27:08.035:     ICMP type=0, code=0, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

                      *Aug 14 13:27:08.035: FIBipv4-packet-proc: route packet from Ethernet0/2 src 2.2.2.2 dst 10.0.0.1

                      *Aug 14 13:27:08.035: FIBfwd-proc: Default:10.0.0.1/32 receive entry

                      *Aug 14 13:27:08.035: FIBipv4-packet-proc: packet routing failed

                      *Aug 14 13:27:08.035: IP: tableid=0, s=2.2.2.2 (Ethernet0/2), d=10.0.0.1 (Ethernet0/2), routed via RIB

                      *Aug 14 13:27:08.035: IP: s=2.2.2.2 (Ethernet0/2), d=10.0.0.1 (Ethernet0/2), len 100, rcvd 3

                      *Aug 14 13:27:08.035:     ICMP type=0, code=0

                      *Aug 14 13:27:08.035: IP: s=2.2.2.2 (Ethernet0/2), d=10.0.0.1

                       

                       

                       

                      ==========

                       

                      R1#sh run int eth 0/0

                      Building configuration...

                       

                      Current configuration : 96 bytes

                      !

                      interface Ethernet0/0

                      ip address 192.168.12.1 255.255.255.0

                      ip load-sharing per-packet

                      end

                       

                      R1#sh run int eth 0/2

                      Building configuration...

                       

                      Current configuration : 92 bytes

                      !

                      interface Ethernet0/2

                      ip address 10.0.0.1 255.255.255.0

                      ip load-sharing per-packet

                      end

                       

                      R1#

                       

                       

                      R1#sh ip cef 2.2.2.0 detail

                      2.2.2.0/24, epoch 0, per-packet sharing

                        nexthop 10.0.0.4 Ethernet0/2

                        nexthop 192.168.12.2 Ethernet0/0

                      R1#

                      *Aug 14 14:04:14.664: FIBipv4-packet-proc: route packet from (local) src 192.168.12.1 dst 2.2.2.2

                      *Aug 14 14:04:14.664: FIBfwd-proc: Default:2.2.2.0/24 process level forwarding

                      *Aug 14 14:04:14.664: FIBfwd-proc: depth 0 first_idx 0 paths 2 long 0(0)

                      *Aug 14 14:04:14.664: FIBfwd-proc: try path 0 (of 2) v4-anh-10.0.0.4-Et0/2 first short ext 0(-1)

                      *Aug 14 14:04:14.664: FIBfwd-proc: v4-anh-10.0.0.4-Et0/2 valid

                      *Aug 14 14:04:14.664: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/2 nh 10.0.0.4 deag 0 chg_if 0 via fib 0 path type attached nexthop

                      *Aug 14 14:04:14.664: FIBfwd-proc: packet routed to Ethernet0/2 10.0.0.4(0)

                      *Aug 14 14:04:14.664: FIBipv4-packet-proc: packet routing succeeded

                      *Aug 14 14:04:14.664: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/2 nh 10.0.0.4 uhp 1 deag 0 ttlexp 0

                      *Aug 14 14:04:14.664: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if Ethernet0/2 nh 10.0.0.4 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0

                      *Aug 14 14:04:14.664: IP: s=192.168.12.1 (local), d=2.2.2.2 (Ethernet0/2), len 100, sending

                      *Aug 14 14:04:14.664:     ICMP type=8, code=0

                      *Aug 14 14:04:14.664: IP: s=192.168.12.1 (local), d=2.2.2.2 (Ethernet0/2), len 100, sending full packet

                      *Aug 14 14:04:14.664:     ICMP type=8, code=0

                      *Aug 14 14:04:14.666: IP: s=2.2.2.2 (Ethernet0/2), d=192.168.12.1, len 100, input feature

                      *Aug 14 14:04:14.666:     ICMP type=0, code=0, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

                      *Aug 14 14:04:14.666: FIBipv4-packet-proc: route packet from Ethernet0/2 src 2.2.2.2 dst 192.168.12.1

                      *Aug 14 14:04:14.666: FIBfwd-proc: Default:192.168.12.1/32 receive entry

                      *Aug 14 14:04:14.666: FIBipv4-packet-proc: packet routing failed

                      *Aug 14 14:04:14.666: IP: tableid=0, s=2.2.2.2 (Ethernet0/2), d=192.168.12.1 (Ethernet0/0), routed via RIB

                      *Aug 14 14:04:14.666: IP: s=2.2.2.2 (Ethernet0/2), d=192.168.12.1, len 100, rcvd 4

                      *Aug 14 14:04:14.666:     ICMP type=0, code=0

                      *Aug 14 14:04:14.666: IP: s=2.2.2.2 (Ethernet0/2), d=192.168.12.1, len 100, stop process pak for forus packet

                      *Aug 14 14:04:14.666:     ICMP type=0, code=0

                      *Aug 14 14:04:14.666: FIBipv4-packet-proc: route packet from (local) src 192.168.12.1 dst 2.2.2.2

                      *Aug 14 14:04:14.666: FIBfwd-proc: Default:2.2.2.0/24 process level forwarding

                      *Aug 14 14:04:14.666: FIBfwd-proc: depth 0 first_idx 1 paths 2 long 0(0)

                      *Aug 14 14:04:14.666: FIBfwd-proc: try path 1 (of 2) v4-anh-192.168.12.2-Et0/0 first short ext 0(-1)

                      *Aug 14 14:04:14.666: FIBfwd-proc: v4-anh-192.168.12.2-Et0/0 valid

                      *Aug 14 14:04:14.666: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/0 nh 192.168.12.2 deag 0 chg_if 0 via fib 0 path type attached nexthop

                      *Aug 14 14:04:14.666: FIBfwd-proc: packet routed to Ethernet0/0 192.168.12.2(0)

                      *Aug 14 14:04:14.666: FIBipv4-packet-proc: packet routing succeeded

                      *Aug 14 14:04:14.666: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/0 nh 192.168.12.2 uhp 1 deag 0 ttlexp 0

                      *Aug 14 14:04:14.666: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if Ethernet0/0 nh 192.168.12.2 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0

                      *Aug 14 14:04:14.666: IP: s=192.168.12.1 (local), d=2.2.2.2 (Ethernet0/0), len 100, sending

                      *Aug 14 14:04:14.666:     ICMP type=8, code=0

                      *Aug 14 14:04:14.666: IP: s=192.168.12.1 (local), d=2.2.2.2 (Ethernet0/0), len 100, sending full packet

                      *Aug 14 14:04:14.666:     ICMP type=8, code=0

                      *Aug 14 14:04:14.667: IP: s=2.2.2.2 (Ethernet0/0), d=192.168.12.1, len 100, input feature

                      *Aug 14 14:04:14.667:     ICMP type=0, code=0, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

                      R1#

                      *Aug 14 14:04:14.667: FIBipv4-packet-proc: route packet from Ethernet0/0 src 2.2.2.2 dst 192.168.12.1

                      *Aug 14 14:04:14.667: FIBfwd-proc: Default:192.168.12.1/32 receive entry

                      *Aug 14 14:04:14.667: FIBipv4-packet-proc: packet routing failed

                      *Aug 14 14:04:14.668: IP: tableid=0, s=2.2.2.2 (Ethernet0/0), d=192.168.12.1 (Ethernet0/0), routed via RIB

                      *Aug 14 14:04:14.668: IP: s=2.2.2.2 (Ethernet0/0), d=192.168.12.1 (Ethernet0/0), len 100, rcvd 3

                      *Aug 14 14:04:14.668:     ICMP type=0, code=0

                      *Aug 14 14:04:14.668: IP: s=2.2.2.2 (Ethernet0/0), d=192.168.12.1, len 100, stop process pak for forus packet

                      *Aug 14 14:04:14.668:     ICMP type=0, code=0

                      • 8. Re: What happened here with EIGRP routing?
                        Learner

                        Hi Steven,

                         

                        On my topology, traceroute works differently from ping. The traffic goes both ways.

                         

                        R1#

                        R1#traceroute 2.2.2.2

                        Type escape sequence to abort.

                        Tracing the route to 2.2.2.2

                        VRF info: (vrf in name/id, vrf out name/id)

                          1 192.168.12.2 12 msec

                            10.0.0.4 20 msec

                            192.168.12.2 16 msec

                        R1#

                        • 9. Re: What happened here with EIGRP routing?
                          Steven Davidson

                          Do you think that's a bit odd?  Ping and traceroute are both locally originated packets yet ping only goes one way and traceroute goes both ways.  What do you suppose causes that?

                          • 10. Re: What happened here with EIGRP routing?
                            isuremu26@live.fr

                            Hi,

                            Why using the same network address twice ??

                            A private network address must be localised in a unique physical localisation when u work in the same domaine.

                            • 11. Re: What happened here with EIGRP routing?
                              Ramabolu

                              Well explained Ing_Percy