Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

EIGRP

i found this statement in a file but did not explain it any further.

These neighbour/peer relationships only occur over primary interface addresses NOT via any secondary addresses that may be configured!

does that include subinterfaces? only the primary interface will establish an ajacency. thanks

  • LAN Switching and Routing
11 REPLIES
Cisco Employee

Re: EIGRP

Hello,

These neighbour/peer relationships only occur over primary interface addresses NOT via any secondary addresses that may be configured!

does that include subinterfaces? only the primary interface will establish an ajacency. thanks

No, this statement does not relate to subinterfaces. A secondary IP address is something independent and different from a subinterface. It is perfectly valid to use subinterfaces with EIGRP, and adjacencies will be established over subinterfaces in a totally normal and usual way.

A secondary address is an IP address that is configured in addition to the primary address on the same (sub)interface, for example:

interface FastEthernet 0/0

ip address 192.0.2.1 255.255.255.0

ip address 10.0.0.1 255.255.255.0 secondary

The IP address 10.0.0.1/24 in my example is the secondary address on this interface. EIGRP will advertise this network when added to the EIGRP process using the network command but it will not establish any adjacencies on this IP address. If there was another EIGRP router connected to the same interface using an IP address from the 10.0.0.0/24 network, no adjacency would be established with it. Only neighbors addressed in the 192.0.2.0/24 IP space would be considered for neighborship.

So, subinterfaces will work absolutely fine. Secondary IP addresses can be advertised but will not be used to establish adjacencies with neighboring routers.

Best regards,

Peter

New Member

Re: EIGRP

thanks Peter for the reply.

Obviously my subinterfaces are not establishing adjacencies in EIGRP nor OSPF.

i tried it with two sets of different routers. tried removing ip address from the primary interface.

the subnet is in the routing table, it shows up in show ip eigrp interface but not in the neighbor table.

attached is the config for ospf. am i missing anything?

thanks

Re: EIGRP

Hi Riz,

i suggest following config ..should work fine with this, im a bit confused about why you are forming ospf relationship with both the primary interface ( serial0  and the subint serial 0.1 ) to the same router ?  -- could you explain a little or perhaps send us a simple diagram as am a little confused

you can check ospf interfaces ( ie ones that can form neighbours )  # sh ip ospf interface

I dont see any eigrp process enabled -- was this removed?

Router 1...

!

router ospf 10

log-adjacency-changes

redistribute connected subnets

network 172.16.12.0 0.0.0.3 area 0

network 172.16.12.4 0.0.0.3 area 0

network 172.16.12.12 0.0.0.3 area 0

network 192.168.1.0 0.0.0.255 area 0

Router 2...

outer ospf 10

log-adjacency-changes

redistribute connected subnets

area 20 range 172.16.2.0 255.255.255.0

network 172.16.12.0 0.0.0.3 area 0

network 172.16.12.12 0.0.0.3 area 0

network 172.16.23.0 0.0.0.7 area 23

network 172.16.2.0 0.0.0.255 area 20

Hall of Fame Super Silver

Re: EIGRP

I believe that the configuration of subinterfaces as shown in the attached configs is not valid:

!
interface Serial0
bandwidth 250
ip address 172.16.12.2 255.255.255.252
no fair-queue
down-when-looped
!
interface Serial0.1
ip address 172.16.12.14 255.255.255.252
!

It would appear that Serial0 is an HDLC interface and HDLC does not support subinterfaces. This appears to be from the running config of the router and I do not understand how it got into the running config since it appears to be an invalid configuration.

As far as troubleshooting this issue I would suggest that the first step is to verify IP connectivity. Do the routers see each other as CDP neighbors? And if so on what interfaces/subinterfaces do they see each other.

Next troubleshooting step would be can you ping the interfaces of the 2511 from the 2503 and ping the 2503 from the 2511?

And it may also be helpful to see the output of show ip interface brief from both of the routers.

HTH

Rick

Cisco Employee

Re: EIGRP

Rick,

I think you've just hit the nail on its head. I have had not the time yet to go over the configuration, I've just briefly checked the comments available and from what I see, you are completely correct - the interface does not have its encapsulation changed, so it must be HDLC - and HDLC has indeed no provision for subinterfaces.

The funny thing is that I have seen myself that the IOS is actually quite happy with subinterfaces even if the encapsulation is set to HDLC. I haven't researched further what that may be good for, I just thought it was a nuisance or a forgotten issue in the CLI as it should not be accepted but I can confirm myself that you actually can create subinterfaces under HDLC interface. Whether they are good for anything - I doubt that.

Best regards,

Peter

New Member

Re: EIGRP

yes, i have different parts of the network with OSPF and others with EIGRP.

since i do not have other interfaces on the 2500. i would use one subinterface S0.1 for OSPF in the 172.16.0.0. network and S0.2 for EIGRP in the 10.0.0.0 network.

yes, the interface is HDLC and if subinterfaces are not supported then troubleshooting is over.

the pings are working both direction, everything is there except adjacencies.

Hall of Fame Super Silver

Re: EIGRP

The additional outputs are helpful (and to me are quite surprising). I still believe that HDLC does not support subinterfaces and that this is the fundamental problem. I believe that there is some support for this in looking at the debug output which shows Hello messages on the physical interfaces but not on the subinterfaces.

It might be helpful to post the output of show ip interface brief (although from the output of show ip ospf interface I am guessing that the subinterfaces will show as up/up).

It might also be helpful to post the output of show cdp neighbor. I believe that we will see neighbors (verifying connectivity) on the physical interfaces and not on the subinterfaces.

The ping to the subinterface address is a bit surprising. I would have expected it to fail but it succeeds. I would suggest a follow up test which would be to traceroute to the subinterface address. I suspect that we will see that the response is from the neighbor physical address (and not from the subinterface address as it should be if the subinterface were working).

HTH

Rick

Cisco Employee

Re: EIGRP

Rick,

I concocted a quick test in Dynamips:

R1:

interface Serial1/0
ip address 192.0.2.1 255.255.255.252
interface Serial1/0.1
ip address 192.0.2.5 255.255.255.252

R2:

interface Serial1/0
ip address 192.0.2.2 255.255.255.252
interface Serial1/0.1
ip address 192.0.2.6 255.255.255.252

Now:

R1#ping 192.0.2.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 12/12/12 ms
R1#
*Mar  1 16:15:45.475: ICMP: echo reply rcvd, src 192.0.2.2, dst 192.0.2.1
R1#ping 192.0.2.6 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.0.2.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
R1#
*Mar  1 16:15:50.447: ICMP: echo reply rcvd, src 192.0.2.6, dst 192.0.2.5
R1#

The pings are responded to as expected - when pinging 192.0.2.2, the response comes from that address. When pinging 192.0.2.6, the response indeed comes forom that address as well. The traceroute comes from 192.0.2.2, though (not shown here). Nevertheless, I can telnet to the 192.0.2.6:

R1#telnet 192.0.2.6
Trying 192.0.2.6 ... Open
  
R2#

Personally, I find nothing wrong with the subinterfaces actually being usable for communication. The HDLC just does not know how to distinguish them, and from the framing perspective, they are totally equivalent and undistinguishable - in essence, they behave very similarly to secondary IP addresses defined on a single interface. That is also why they work - from the viewpoint of R1, the 192.0.2.6/30 is reachable via S1/0.1 so it sends it. The HDLC frame is no different from a frame that would be sent via S1/0 directly. It arrives on R2 and R2 finds a packet inside destined to one of its own IP addresses, so it processes it. It seems to me to be that simple.

By the way, I've tried to configure the EIGRP over the physical interface and subinterface, and I've got this:

R1(config)#router eigrp 1
R1(config-router)#net 192.0.2.0
R1(config-router)#
*Mar  1 16:21:47.039: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.0.2.2 (Serial1/0) is up: new adjacency
R1(config-router)#
*Mar  1 16:21:52.007: IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 192.0.2.6 not on common subnet for Serial1/0

Obviously, R1 tries to process all EIGRP packets on the primary physical interface, and understandably, the 192.0.2.6 is not in the same subnet as 192.0.2.1/30. That's probably the reason why the EIGRP adjacencies could not be established, as described in OP.


Best regards,

Peter

New Member

Re: EIGRP

thanks Rick for your help,

i am convinced that DHCP doesn't support subinterfaces. that's why adjacency is not forming. so, i should go to frame relay encapsulation.

you are right traceroute the ip on the primary interface is answering.

RTR-1(2511)#sh cdp neig

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater

Device ID Local Intrfce Holdtme Capability Platform Port ID

RTR-5(2503) Ser 1 143 R 2500 Ser 0

RTR-2(2503) Ser 0 178 R 2500 Ser 0.1

RTR-2(2503) Ser 0 178 R 2500 Ser 0

RTR-1(2511)#tra?

traceroute

RTR-1(2511)#tra

RTR-1(2511)#traceroute 172.16.12.14

Type escape sequence to abort.

Tracing the route to 172.16.12.14

1 172.16.12.2 40 msec * 8 msec

RTR-1(2511)#traceroute 172.16.12.13

Type escape sequence to abort.

Tracing the route to 172.16.12.13

1 172.16.12.2 8 msec 8 msec 8 msec

2 172.16.12.1 12 msec * 12 msec

1203
Views
10
Helpful
11
Replies
This widget could not be displayed.