Re: discover eigrp neighbor as system

Per_Cas · ‎11-19-2020

hello forum Guys,

I would like to discover eigrp neighbor AS system nr to configure eigrp in between 2 routers - is there any debug command I can use to achieve this?

I have:

top:

R1----------R2

R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 unassigned YES unset administratively down down
...
GigabitEthernet0/8 38.1.1.3 YES manual up up



R3#p 38.1.1.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 38.1.1.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/7 ms

R2 - I can not access R2 at all but I know that there is eigrp configured

R1#sh cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
...
R2 Gig 0/8 176 R B Gig 0/3

Total cdp entries displayed : 5

Giuseppe Larosa · ‎11-19-2020

Hello @Per_Cas ,

make a packet capture you should be able to see EIGRP hello packets and then using wireshark you should be able to decode them

inside EIGRP hello you should be able to see EIGRP AS number

They are sent every 5 seconds on a LAN interface and EIGRP protocol number should be 88.

Hope to help

Giuseppe

Richard Burts · ‎11-19-2020

Packet capture is certainly one way to find the AS number. I would think that debug eigrp neighbor would be another alternative to find that information.

HTH

Rick

Per_Cas · ‎11-20-2020

debug eigrp neighbor does not show anything... packet capture yes, but assume that I have only routers to play with.

when I configure:

router eigrp 2
 network 38.1.1.3 0.0.0.0

then I get:

R1#debug eigrp packets all

*Nov 20 08:37:54.647: EIGRP: Sending HELLO on Gi0/8 - paklen 20
*Nov 20 08:37:54.647:   AS 2, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0

R1#debug IP PACket

*Nov 20 08:44:56.650: IP: s=38.1.1.3 (local), d=224.0.0.10 (GigabitEthernet0/8), len 60, sending broad/multicast
*Nov 20 08:44:56.650: IP: s=38.1.1.3 (local), d=224.0.0.10 (GigabitEthernet0/8), len 60, sending full packe

R1#p 224.0.0.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.10, timeout is 2 seconds:

...
Reply to request 0 from 38.1.1.8, 3 ms
..
..

R1 is sending hello out of gi0/8, however I do not see any hello from R2 on this interface, how can I see that?

Per_Cas · ‎11-20-2020

why protocol nr should be 88?

Giuseppe Larosa · ‎11-20-2020

Hello @Per_Cas ,

EIGRP is not based on TCP or UDP so it has its own protocol number in the IP header and the decimal value of that field is 88 like it is 6 for TCP.

Hope to help

Giuseppe

Richard Burts · ‎11-20-2020

I had suggested debug eigrp neighbor. The output posted was for debug eigrp packet which would be even more inclusive. But the debug output does not show receiving any eigrp packets. How long did that debug run?

The output of show cdp neighbor does confirm that R2 is a neighbor. The lack of output in debug and the fact that ping to 224.0.0.10 gets no response suggests that there is some problem about eigrp on R2. It would suggest that either R2 is not running eigrp on its interface or that R2 has some policy implemented that denies eigrp packets on that interface, or that perhaps R1 has some policy implemented on its interface that prevents eigrp.

[edit] When I first read the response I thought that the ping to 224.0.0.10 received not response. Now when I look at the post it does seem that there was a response. Not sure how I made that mistake. If there is a response to the ping but there are no eigrp hello packets then it seems to suggest that R2 may have configured that interface as passive in eigrp. We really need some information from R2 about its configuration to be able to understand this issue.

HTH

Rick

Per_Cas · ‎11-20-2020

this is config for R2:

router eigrp ???
net 38.1.1.8 0.0.0.0

btw - network statement was discovered from multicast ping.

we need to find out what is AS of eigrp without looking at R2 - we do not have access to R2. if interface on R2 was passive, we would not receive response from multicast ping. I left debug for like 30 sec at least. all I get is:

R1#debug eigrp packets all detail

*Nov 20 10:08:22.268: EIGRP: Sending HELLO on Gi0/8 - paklen 20
*Nov 20 10:08:22.268:   AS 2, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Nov 20 10:08:22.268:   {type = 1, length = 12}
*Nov 20 10:08:22.268:   {vector = {
*Nov 20 10:08:22.268:             {01000100 0000000F}
*Nov 20 10:08:22.269:   }
*Nov 20 10:08:22.269:   {type = 4, length = 8}
*Nov 20 10:08:22.269:   {vector = {
*Nov 20 10:08:22.269:             {14000200}
*Nov 20 10:08:22.269:   }
...
*Nov 20 10:08:26.688: EIGRP: Sending HELLO on Gi0/8 - paklen 20
*Nov 20 10:08:26.688:   AS 2, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Nov 20 10:08:26.688:   {type = 1, length = 12}
*Nov 20 10:08:26.688:   {vector = {
*Nov 20 10:08:26.688:             {01000100 0000000F}
*Nov 20 10:08:26.688:   }
*Nov 20 10:08:26.688:   {type = 4, length = 8}
*Nov 20 10:08:26.688:   {vector = {
*Nov 20 10:08:26.688:             {14000200}
*Nov 20 10:08:26.689:   }
...

I know that this task is not simple that is why I posted that on professional forum

Richard Burts · ‎11-20-2020

If "network statement was discovered from multicast ping." then you are just guessing at what is configured on R2. Have you done packet capture? If so do the results in that match up with the results of your debug?

What we know at this point is that R1 is running eigrp on its interface but that R2 does not seem to be active for eigrp on this connection. I am not sure how we make any progress on this issue without some insight into R2. Perhaps we should ask for some clarification about R2 and why you do not have any information about its configuration?

HTH

Rick

Per_Cas · ‎11-20-2020

I created packet capture however it does not show anything:

access-list 100 permit ip any any
monitor capture buffer CAP-BUF size 2048 max-size 1518 linear
monitor capture buffer CAP-BUF filter access-list 100
monitor capture point ip cef CAP-POINT gi0/8 both
monitor capture point associate CAP-POINT CAP-BUF
monitor capture point start CAP-POINT
monitor capture point stop CAP-POINT

#show monitor capture buffer CAP-BUF
12:28:06.401 UTC Nov 20 2020 : IPv4 LES CEF    : Gi0/8 None

Richard Burts · ‎11-21-2020

With permit any any I am surprised that the capture buffer is empty. How long did you let the capture run?

HTH

Rick