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:

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

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

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.

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

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?

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

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.

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?

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

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

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

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

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