OSPF neighborship can't form on ADSL

Unanswered Question
Sep 1st, 2010

Hi,

I have an issue with OSPF on ADSL interfaces. It seems that my router's interface can't "see" the provider's ADSL interface during DR elections. I checked the configuration and it is the same on other routers in my company.

Please have a look at the files.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.7 (17 ratings)
Loading.
Peter Paluch Wed, 09/01/2010 - 13:00

Wass,

You have an interesting problem (and an interesting configuration, too).

The problem in my opinion is even deeper: the two OSPF routers are not even able to see any OSPF packets sent over the DSL line. That leads us to the following set of questions:

  1. Is it possible to successfully ping the 192.168.200.17 from your router, and vice versa?
  2. Are you bridging the ATM (DSL) interface with another interface? If so, which one? Is that necessary?
  3. Is the integrated bridging and routing activated for the bridge group 1 using the commands bridge irb and bridge 1 route ip?
  4. In the debug output you have provided, I do not see any targeted OSPF hello packets being sent to 192.168.200.17 via the BVI1 interface. I should have seen at least some of them. This is interesting because it suggests that the OSPF is not, for some reason (perhaps because of Item 3), willing to send OSPF packets through the BVI1 interface.
  5. Try creating ACL 199 as follows: access-list 199 permit ospf any any and use it in the debug ip packet 199 command to see all OSPF packets generated and received by your router. Closely verify whether there are any OSPF packets arriving via BVI1, whether there are any being sent out of BVI1, and also check for any "encapsulation failed" messages.

Please try to answer all these questions. Also, having the opportunity to see your entire configuration would be most helpful.

Best regards,

Peter

Wassim Aouadi Thu, 09/02/2010 - 01:24

Peter,

1. Yes I can ping 192.168.200.17 from my router:

TNRTAGCS01008#sh ip int bvi1
BVI1 is up, line protocol is up
  Internet address is 192.168.200.19/28
  Broadcast address is 255.255.255.255
  Address determined by setup command

...

TNRTAGCS01008#
TNRTAGCS01008#ping 192.168.200.17

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

2. Regarding ATM configuration, I had a template that I simply pushed on the router to make DSL interface work. So I can give you the whole ATM and bvi configuration if it may clarify things:

interface ATM0/3/0
mtu 1500
no ip address
ip ospf network non-broadcast
no atm ilmi-keepalive
dsl operating-mode auto
bridge-group 1
pvc 0 0/35
!
end

here is the bvi configuration:

interface BVI1

ip address 192.168.200.19 255.255.255.240
ip ospf network non-broadcast
ip ospf cost 333
ip ospf priority 100
end

and the global settings:

bridge irb
bridge-group 1
bridge 1 protocol ieee
bridge 1 route ip

3. from the configuration, yes.

5. I can not see any OSPF packets on the bvi interface hitting the ACL, and there are no "encapsulation failed" messages.

I didn't manage to get the full configuration since my client didn't agree on that. But, actually we have two WAN links: one is MPLS (192.168.100.0/30) and the other is ADSL (192.168.200.0). OSPF is working fine on the MPLS link.

Regards,

Wassim

Peter Paluch Thu, 09/02/2010 - 02:06

Wassim,

Until you know precisely that you need the bridging and until there indeed are more interfaces in the bridge-group 1 than the ATM interface then the entire bridging stuff is largely unnecessary. If there is no bridging necessary between the DSL circuit and some other internal network, the IP configuration can be made on the ATM interface itself which is a far better choice.

As the first step of solving this issue, I recommend removing the BVI configuration if the bridging is not required (verify that please!) and instead, creating a point-to-point ATM subinterface. The configuration would be as follows:

interface ATM0/3/0

no shutdown
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!

interface ATM0/3/0.1 point-to-point

mtu 1500

ip ospf network non-broadcast

ip address 192.168.200.19 255.255.255.240

pvc 0/35

!

!

router ospf 1

area 2 stub ! The no-summary is valid only on ABR routers

network 192.168.200.19 0.0.0.0 area 2

neighbor 192.168.200.17

...

...

This configuration should be functionally equivalent to what you have configured right now.

There is little point in using the non-broadcast OSPF network type unless the router 192.168.200.17 is performing some kind of bridging between all the DSL circuits leading to it. What is the configuration of the 192.168.200.17 router, anyway? Do multiple OSPF routers talk to it? Are they all on the same subnet, or is each of them in a separate IP?

Regarding the debug - please leave it running again and let it run for 5 minutes. We need more time to observe the behavior.

Best regards,

Peter

Wassim Aouadi Thu, 09/02/2010 - 02:49

Peter,

I understand what you meant in the bridging point. My client has only one interface in the bridge-group 1. However, from the ISP side, the network is a kind of point-to-multipoint, because the ISP DSL entry point (192.168.200.17) serves two of our branch offices, including this router. And they are all three on the same IP subnet 192.168.200.16/28. So I guess bridging and non-broadcast OSPF network are needed on the ISP side, aren't they?

I followed your configuration. Ping no longer succeeds:

TNRTAGCS01008(config-subif)#do sh run int atm0/3/0.1              
Building configuration...

Current configuration : 141 bytes
!
interface ATM0/3/0.1 point-to-point
mtu 1500
ip address 192.168.200.19 255.255.255.240
ip ospf network non-broadcast
pvc 0/35
!
end

TNRTAGCS01008(config-subif)#
TNRTAGCS01008(config-subif)#do sh run int atm0/3/0                
Building configuration...

Current configuration : 90 bytes
!
interface ATM0/3/0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
end

TNRTAGCS01008(config-subif)#
TNRTAGCS01008(config-subif)#do ping 192.168.200.17

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.17, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

OK for the debug, here's a fresh new copy. I did a shut/no shut on the bvi1 interface to try to fire up some OSPF packets.

Peter Paluch Thu, 09/02/2010 - 03:14

Hi Wassim,

In your case, yes, the headend needs to use the BVI interface, and as that is probably immutable, we also need to run the BVI on the spoke routers (this probably has to do with the fact that the circuit is using the SNAP encapsulation and it distinguished between packets that are routed and between packets that are switched according to the RFC 1483 - having one side of the PVC as bridged and the second as routed will lead to reachability issues like this one). I assume you have reverted your configuration back to the BVI and at least the pings started working, right?

This puts us back to the original problem - why is the OSPF unable or unwilling to send packets out the interface BVI1? Is this related to this particular router only, or did you observe this problem on multiple locations?

Regarding the debug: please do not modify the BVI state - let it up and running and during the 5 minutes try to capture the OSPF traffic. Thanks!

What is the exact model of your router and the exact IOS version?

Best regards,

Peter

Wassim Aouadi Thu, 09/02/2010 - 04:12

I see this issue only on this router which has IOS 12.4. We borrowed it from our ISP for ADSL tests. The remaining of my client's routers have a different model and IOS, and ADSL is working fine on them.

Regarding the debug,I did as you told me. I saw the "encapsulation failed" message on the new debug file. Bvi interface is trying to send OSPF packets to its peer 192.168.200.17. What could it mean?

Peter Paluch Thu, 09/02/2010 - 04:25

Wassim,

Thank you for the debug. We needed to wait at least 120 seconds after the BVI came up (the WAIT interval) for OSPF to start sending the Hello packets on this NBMA circuit.

Well, we have an onging mystery here. We can see now that the router actually sends the OSPF Hello packets but either they do not make it to the headend router 192.168.200.17, or the headend router does not process them, or its own Hello packets are not being received for whatever reason by this router.

Do you have access to the headend router? Using the same debug ip packet 199 as on this router plus debug ip ospf adj and debug ip ospf events and debug ip ospf packet, can you confirm that the headend router is receiving the OSPF Hello packets from 192.168.200.19?

The "encapsulation failed" message in general means that the router does not know how to encapsulate the packet into a frame and send it out some interface - mostly because it does not know what Layer2 address should be put into the frame header. I am not quite sure why this message appeared to you only once - perhaps the PVC 0/35 flapped momentarily.

As a side question, do you think it would be possible to upgrade the IOS on this router? The newest 12.4T version is c2801-spservicesk9-mz.124-24.T3.bin. I am not suggesting at this point that this is a bug but we should consider that a possibility.

Best regards,

Peter

Wassim Aouadi Thu, 09/02/2010 - 04:48

I asked the Telco to configure debugging with ACL filtering. However, they can not issue the other OSPF debug commands because it would generate a lot of unacceptable traffic (to them). I'll let you know. As for upgrading the router, this may be a last resort.

Wassim Aouadi Thu, 09/02/2010 - 06:00

The telco company did not agree to do a "debug ip packet 199". Is there another way to check whether their router can receive our OSPF packets?

Peter Paluch Thu, 09/02/2010 - 06:30

Hello Wassim,

Your ISP is not making things easy for us. Typical.

I suspect that these command should do the trick:

debug condition interface bvi1

debug ip ospf events

debug ip ospf adj

This should limit the debugging to OSPF actions on the interface BVI1 (assuming that this is the proper interface under which the PVC from your router is terminated at the ISP side).

Best regards,

Peter

Giuseppe Larosa Thu, 09/02/2010 - 06:47

Hello Wassim,

giving a look at this interesting thread

*Sep  2 10:52:20.973 UTC: IP: s=192.168.200.19 (local), d=192.168.200.17 (BVI1), len 76, sending

*Sep  2 10:52:20.973 UTC: IP: s=192.168.200.19 (local), d=192.168.200.17 (BVI1), len 76, encapsulation failed

I would try to help router to encapsulate with

int atm0/3/0

pvc 0/35

protocol ip 192.168.200.17

unless using a point to point subif main atm interface is point to multipoint

Hope to help

Giuseppe

Peter Paluch Thu, 09/02/2010 - 07:14

Hello Giuseppe,

Thanks for this idea. Originally, I thought about it, too. Then I've made an experiment on a Dynamips two-router topology, and was somewhat surprised to learn that in this particular case, the BVI interface above the ATM is actually imposing Ethernet frames into the ATM. If the IP was indeed configured directly on the ATM interface, it would be a usual IP directly over ATM. However, with the bridge-group and the BVI here, the BVI interface generates an Ethernet frame and this is passed down to the ATM. This configuration is actually using the Ethernet and ARP just as if it was an Ethernet segment, and you can see the other IP address in the show ip arp command output! Mapping the IP directly to the PVC will therefore, in my opinion, not have any effect because of the additional Ethernet encapsulation of the IP packets before they hit the ATM interface.

I have to apologize to Francisco - his ARP comment was correct in this case, as the BVI interface is responsible for creating this extra layer of encapsulation. I did not know about that. Checking the ARP cache is, in this case, a helpful suggestion. Francisco, sorry! Nevertheless, as the router is able to ping the ISP router, the basic communication seems to be established.

So far it seems that the OSPF on the local router is emitting the Hello packets but they are probably not delivered to the ISP. What we know for sure is that there are no OSPF packets coming from the ISP to the local router - absolutely none have appeared in debugs.

Best regards,

Peter

Peter Paluch Thu, 09/02/2010 - 11:28

Hi Giuseppe,

int atm 0/3/0

pvc 0/35

  protocol bridge broadcast

Agree completely! But note that it is actually possible to ping the headend (ISP) router from the spoke router which means that the ARP resolution (and the broadcast) already work. On the other hand, it does not do any harm to include this command.

This entire issue is curious - Wassim can ping the ISP but the OSPF does not come up and no OSPF packets arrive at the spoke router. This is becoming more like an ACL or some silly misconfiguration error.

Best regards,

Peter

Giuseppe Larosa Fri, 09/03/2010 - 06:41

Hello Peter,

I may be wrong but at the beginning there was a point-to-point ATM subinterface, then later we have seen the enc failed in debug ip packet detail 199.

Now, at least local node can send OSPF unicast hellos on the ATM PVC but no OSPF message is received from SP router.

if ping works there is no encapsulation mismatch, and so at this point SP router may be missing a neighbor command under OSPF process (even if this shouldn't be  strictly necessary to have on both ends or not ?)

We know also that the other branch routers sees the SP router as OSPF neighbor

Hope to help

Giuseppe

Peter Paluch Fri, 09/03/2010 - 09:00

Hello Giuseppe,

Thank you very much for your thoughts. A few comments:

I may be wrong but at the beginning there was a point-to-point ATM
subinterface, then later we have seen the enc failed in debug ip packet
detail 199.

Now, at least local node can send OSPF unicast hellos on the ATM PVC but no OSPF message is received from SP router.

Actually, at the beginning, the state was just as it is now. The spoke router was configured using BVI interface and it was able to ping the ISP but the OSPF did not come up. Only on my insistence, Wassim converted the configuration into a point-to-point ATM configuration and it, understandably, did not work at all, so Wassim reverted the configuration back to the BVI.

if ping works there is no encapsulation mismatch, and so at this point
SP router may be missing a neighbor command under OSPF process (even if
this shouldn't be  strictly necessary to have on both ends or not ?)

Quite correct. The ping works so there's no encap mismatch, and the ISP routers is not required to have this particular neighbor defined manually (it is sufficient for a spoke router to have its neighbor defined statically).

Any idea? Without knowing more from the ISP I do not see any problem on the spoke router.

Best regards,

Peter

Wassim Aouadi Fri, 09/03/2010 - 01:02

Giuseppe, I issued "protocol bridge broadcast" under atm interface but nothing seems to change.

Here's the output of the latest debug:

*Sep  3 07:35:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:35:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:37:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:37:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:39:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:39:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:41:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:41:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:43:13.772 UTC: OSPF: Build router LSA for area 2, router ID 192.168.200.19, seq 0x80000D8B, process 1
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:43:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:43:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
TNRTAGCS01008(config-if-atm-vc)#
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:45:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:45:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:47:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:47:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:49:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:49:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:51:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:51:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:53:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:53:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:55:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:55:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:57:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:57:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 07:59:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 07:59:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 08:01:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 08:01:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#
TNRTAGCS01008(config-if-atm-vc)#
*Sep  3 08:03:19.072 UTC: OSPF: Sending poll to 0.0.0.0 address 192.168.200.17 on BVI1
*Sep  3 08:03:19.072 UTC: OSPF: Send hello to 192.168.200.17 area 2 on BVI1 from 192.168.200.19
TNRTAGCS01008(config-if-atm-vc)#

and here's a "show ip arp" on the router:

TNRTAGCS01008(config)#do sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.101.4.130          223   18a9.0532.5cc3  ARPA   FastEthernet0/0.1100
Internet  10.101.4.131           51   f4ce.4605.8fb1  ARPA   FastEthernet0/0.1100
Internet  10.101.4.158            -   0023.eb79.aab8  ARPA   FastEthernet0/0.1100
Internet  10.101.4.174            -   0023.eb79.aab8  ARPA   FastEthernet0/0.1200
Internet  10.101.4.190            -   0023.eb79.aab8  ARPA   FastEthernet0/0.1300
Internet  10.101.4.248           78   0064.40ee.e741  ARPA   FastEthernet0/0.1900
Internet  10.101.4.254            -   0023.eb79.aab8  ARPA   FastEthernet0/0.1900
Internet  22.101.4.129           18   9caf.caff.5867  ARPA   FastEthernet0/0.2222
Internet  22.101.4.254            -   0023.eb79.aab8  ARPA   FastEthernet0/0.2222
Internet  192.168.100.33        235   001b.0de6.ea40  ARPA   FastEthernet0/1
Internet  192.168.100.34          -   0023.eb79.aab9  ARPA   FastEthernet0/1
Internet  192.168.200.17        104   0090.1a42.1ebc  ARPA   BVI1
Internet  192.168.200.18        145   0000.0c55.7770  ARPA   BVI1
Internet  192.168.200.19          -   0000.0ce8.2ee0  ARPA   BVI1

Peter Paluch Fri, 09/03/2010 - 01:06

Wassim,

Did your ISP agree to use these commands as I suggested earlier?

debug condition interface bvi1<br/>debug ip ospf events<br/>debug ip ospf adj<br/>

(The ISP shall substitute the "bvi1" with his own interface that provides bridging for you).

Best regards,

Peter

francisco_1 Thu, 09/02/2010 - 04:01

Have you tried using ip "ospf mtu-ignore"

Can you post show "ip ospf interface bvi1" on both sides and post the full config on both sides.

Post deb ip ospf adj also.

Francisco.

Peter Paluch Thu, 09/02/2010 - 04:11

Hello Francisco,

Thank you for your suggestions. Please read the the entire thread carefully - most of your questions are already answered or not applicable at this point.

Best regards,

Peter

Wassim Aouadi Thu, 09/02/2010 - 05:16

Francisco,

I don't think it's a matter of MTU. If it was, debugs would show me "mtu mismatch".

TNRTAGCS01008#show ip ospf int bvi1
BVI1 is up, line protocol is up
  Internet Address 192.168.200.19/28, Area 2
  Process ID 1, Router ID 192.168.200.19, Network Type NON_BROADCAST, Cost: 333
  Transmit Delay is 1 sec, State DR, Priority 100
  Designated Router (ID) 192.168.200.19, Interface address 192.168.200.19
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:22
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 7/7, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)
TNRTAGCS01008#

for OSPF debugs, note that I did a shut/no shut on the bvi interface. And I can't afford to post the ISP router config, but I guess their interface has default OSPF priority value. And it is already a DR with another branch router of the company.

TNRTAGCS01002#sh ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.200.17    1   FULL/DR         00:01:56    192.168.200.17  BVI1

Peter Paluch Thu, 09/02/2010 - 04:46

Francisco,

You are more than welcome to help! My original reply to your post here was based on the facts that:

  1. You suggested using the ip ospf mtu-ignore - there's no reason for that at this point as the OSPF routers do not even see themselves so they cannot be in the ExStart/Exchange phase which was obvious from the ongoing discussion
  2. You asked for entire configurations - Wassim indicated earlier in the discussion that the customer is not willing to display the entire configuration so we have to use only the information posted so far
  3. You asked for the show ip ospf int bvi1 - the output of this interface was given by Wassim for one router (yes, not for both), and the configuration appeared to be OK so far.

Your descripton of the "encapsulation failed" is correct but the reference to ARP is not appropriate at this point: Wassim is using IP directly over ATM AAL5 in this DSL configuration and there are no Ethernet frames involved - there is no ARP on plain ATM. Also, Wassim indicated that it is possible to ping the headend router, and because of NBMA OSPF configuration, the OSPF should be also using unicast packets only, so there seems to be something fishy in the OSPF communication itself.

Once again, I don't want to prevent you in any way from helping and I am glad you are participating - this is a collaboration forum so this is exactly what the NetPro is about - but if you decide to step in a discussion please first make sure that you are acquainted with the issue.

Looking forward to cooperating with you on this topic

Best regards,

Peter

Actions

This Discussion