2

I am having a problem setting up OSPF between a Juniper Netscreen SSG5's "Untrust" zone and a Cisco router in a lab environment. The state does not transition past EXSTART until the Netscreen device's interface is placed into the "Trust" zone. The below configuration is exactly as entered after clearing all configuration on both devices.

GNS3 emulated Cisco 3640 with IOS 12.4(23)

configure terminal
interface fastethernet0/0
ip address 172.16.1.1 255.255.255.252
no shutdown
router ospf 1
network 172.16.1.1 0.0.0.0 area 1
default-info originate always

Juniper SSG5 with ScreenOS 6.2.0r5.0

set interface ethernet0/0 ip 172.16.1.2 255.255.255.252
set vrouter trust-vr protocol ospf
set vrouter trust-vr protocol ospf enable
set vrouter trust-vr protocol ospf area 1
set interface ethernet0/0 protocol ospf area 1
set interface ethernet0/0 protocol ospf enable

Once these commands are entered, issuing this command on the Netscreen

 get vrouter trust-vr protocol ospf neighbor

results in

            Neighbor(s) on interface ethernet0/0 (Area 0.0.0.1)
IpAddr/IfIndex  RouterId        Pri State    Opt  Up           StateChg
------------------------------------------------------------------------------
172.16.1.1      172.16.1.1        1 ExStart  E    00:01:26     (+4 -0)

On the Cisco

show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.1.2        1   EXCHANGE/BDR    00:00:38    172.16.1.2      FastEthernet0/0

As soon as I enter the following command on the Netscreen, the state transitions to FULL

set interface ethernet0/0 zone Trust

Here's the debug output on the Cisco

debug ip ospf adj

*Mar  1 00:02:18.971: OSPF: 2 Way Communication to 172.16.1.2 on FastEthernet0/0, state 2WAY
*Mar  1 00:02:18.971: OSPF: Backup seen Event before WAIT timer on FastEthernet0/0
*Mar  1 00:02:18.971: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:02:18.971: OSPF: Elect BDR 172.16.1.1
*Mar  1 00:02:18.971: OSPF: Elect DR 172.16.1.2
*Mar  1 00:02:18.971: OSPF: Elect BDR 172.16.1.1
*Mar  1 00:02:18.971: OSPF: Elect DR 172.16.1.2
                             DR: 172.16.1.2 (Id)   BDR: 172.16.1.1 (Id)
*Mar  1 00:02:18.971: OSPF: Send DBD to 172.16.1.2 on FastEthernet0/0 seq 0x2212 opt 0x52 flag 0x7 len 32
*Mar  1 00:02:23.971: OSPF: Send DBD to 172.16.1.2 on FastEthernet0/0 seq 0x2212 opt 0x52 flag 0x7 len 32
*Mar  1 00:02:23.971: OSPF: Retransmitting DBD to 172.16.1.2 on FastEthernet0/0 [1]
*Mar  1 00:02:24.003: OSPF: Rcv DBD from 172.16.1.2 on FastEthernet0/0 seq 0x436 opt 0x2 flag 0x7 len 32  mtu 1500 state EXSTART
*Mar  1 00:02:24.003: OSPF: NBR Negotiation Done. We are the SLAVE
*Mar  1 00:02:24.003: OSPF: Send DBD to 172.16.1.2 on FastEthernet0/0 seq 0x436 opt 0x52 flag 0x2 len 72
*Mar  1 00:02:24.003: OSPF: Rcv DBD from 172.16.1.2 on FastEthernet0/0 seq 0x436 opt 0x2 flag 0x7 len 32  mtu 1500 state EXCHANGE
(last two lines repeat indefinitely)

I don't think it is an MTU mismatch, both devices are set to 1500. And, like I said, it works once the Netscreen interface is placed into the "Trust" zone.

Entering the following on the Netscreen doesn't appear to change anything.

set policy default-permit-all 
unset policy 1

A Wireshark capture shows a flurry of ICMP TTL exceeded packets from the Netscreen to the Cisco when the Netscreen interface is in the "Untrust" zone.

For what it's worth, iBGP works in the "Untrust" zone.

3
  • What is the output from the "get envar" command? Also, just to be sure its not MTU-related, try: set interface <interface> protocol ospf ignore-mtu
    – Ron Trunk
    Jan 6, 2014 at 0:16
  • get envar last_reset=2014-01-05 19:13:42 by netscreen Jan 6, 2014 at 0:39
  • set int e0/0 proto ospf ignore doesn't seem to have an effect, nor does the equivalent Cisco command Jan 6, 2014 at 0:41

1 Answer 1

1

This issue has been resolved. It appears to have been a transient problem at layer 1. I can no longer reproduce it after recabling.

1
  • You should accept your answer so that the question doesn't keep popping up forever, looking for an answer.
    – Ron Maupin
    May 6, 2019 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.