11-19-2020 10:02 AM
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
11-19-2020 10:12 AM
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
11-19-2020 12:40 PM
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.
11-20-2020 12:42 AM - edited 11-20-2020 12:53 AM
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?
11-20-2020 12:42 AM
why protocol nr should be 88?
11-20-2020 01:01 AM
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
11-20-2020 01:25 AM - edited 11-20-2020 01:33 AM
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.
11-20-2020 02:11 AM - edited 11-20-2020 02:12 AM
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
11-20-2020 03:10 AM
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?
11-20-2020 04:35 AM
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
11-21-2020 01:30 AM
With permit any any I am surprised that the capture buffer is empty. How long did you let the capture run?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide