cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

2415
Views
62
Helpful
24
Replies
Highlighted
Enthusiast

OSPF neighborship can't form on ADSL

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.

Everyone's tags (5)
24 REPLIES 24
Hall of Fame Cisco Employee

Re: OSPF neighborship can't form on ADSL

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

Enthusiast

Re: OSPF neighborship can't form on ADSL

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

Hall of Fame Cisco Employee

Re: OSPF neighborship can't form on ADSL

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

Enthusiast

Re: OSPF neighborship can't form on ADSL

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.

Hall of Fame Cisco Employee

Re: OSPF neighborship can't form on ADSL

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

Enthusiast

Re: OSPF neighborship can't form on ADSL

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?

Hall of Fame Cisco Employee

Re: OSPF neighborship can't form on ADSL

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

Enthusiast

Re: OSPF neighborship can't form on ADSL

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.

Enthusiast

Re: OSPF neighborship can't form on ADSL

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?

Hall of Fame Cisco Employee

Re: OSPF neighborship can't form on ADSL

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

Hall of Fame Expert

Re: OSPF neighborship can't form on ADSL

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

Hall of Fame Cisco Employee

Re: OSPF neighborship can't form on ADSL

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

Hall of Fame Expert

Re: OSPF neighborship can't form on ADSL

Hello Peter,

ok we are in RFC 1483 bridged,  but with atm0/3/0 main interface being not point to point we need a protocol command under pvc

something like:

int atm 0/3/0

pvc 0/35

protocol bridge broadcast

see

http://www.cisco.com/en/US/docs/ios/atm/command/reference/atm_m1.html#wp1014484

Hope to help

Giuseppe

Hall of Fame Cisco Employee

Re: OSPF neighborship can't form on ADSL

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

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards