TSHOOT: OSPF neighborship won't come UP

Mattphew

Dear all,


I made GNS3 simulation and trying to establish OSPF between 3 routers (2 Cisco routers and one Juniper router (vSRX via Virtualbox)).
OSPF between Cisco routers is good, but between Cisco and Juniper, well it won't establish neighborship.
Scheme: https://files.fm/u/m4cwcysj#_

Neighborship statuss on Juniper: "Init".
And after debuging OSPF on R1 (cisco), i can see, that he elects itself as DR and BDR for fa0/0 interface..
Please help me to understand what is the issue here.
Configurations should be correct. If needed i can post it here.

Thank You in advance!

networker050184

First thing that comes to mind is MTU.

Mattphew

Already checked and hardcoded mtu for juniper, so that it can transmit 1500 bytes of MTU. And if it was MTU, i would see that in Cisco routers ospf debuging logs, right? Perhaps it is GNS3 bug or perhaps there is problem with timers? By default it should be 10 sec hello and 40 sec dead for ospf on both devices, right?

networker050184

How did you set the MTU exactly? An Ethernet interface with 1500 on a junos device is not the same as an IOS device.

reload@

Do you have the vSRX in flow mode or packet mode? If it's in flow mode, do you have host-inbound-traffic protocols ospf configured?

Mattphew

I have tried to set MTU in this way on Juniper:

[h=4]How to change the media MTU:[/h]

root@SRX# set interfaces ge-0/0/0 mtu 1514 <<<<this will give you Protocol MTU of 1500
root@SRX# commit

But as soon as i commit this command, there is 0 informaton when i'm checking ospf neighborship on Juniper Router.
But if i don't have this MTU command, i can see this outcome:

root# run show ospf neighbor
Address Interface State ID Pri Dead
33.1.1.3 ge-0/0/0.0 Init 1.1.1.1 1 34



As for flow mode:

root# run show security flow status
Flow forwarding mode:
Inet forwarding mode: flow based


Bassically this is my configuration on vSRX:



root# show | display set
set version 12.1X47-D15.4
set system root-authentication encrypted-password "$1$2YgvM3g1$oUfQ.I2XCRxSBlNsPph1c."
set system services ssh
set system services web-management http interface ge-0/0/0.0
set system syslog user * any emergency
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval
set interfaces ge-0/0/0 unit 0 family inet address 33.1.1.2/24
set interfaces ge-0/0/1 unit 0 family inet address 10.1.1.1/24
set routing-options router-id 2.2.2.2
set protocols ospf export OSPF_export
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.1 interface ge-0/0/1.0 passive
set policy-options policy-statement OSPF_export term term1 from protocol direct
set policy-options policy-statement OSPF_export term term1 then accept
set security screen ids-option untrust-screen icmp ping-death
set security screen ids-option untrust-screen ip source-route-option
set security screen ids-option untrust-screen ip tear-drop
set security screen ids-option untrust-screen tcp syn-flood alarm-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood attack-threshold 200
set security screen ids-option untrust-screen tcp syn-flood source-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood destination-threshold 2048
set security screen ids-option untrust-screen tcp syn-flood queue-size 2000
set security screen ids-option untrust-screen tcp syn-flood timeout 20
set security screen ids-option untrust-screen tcp land
set security policies from-zone trust to-zone trust policy default-permit match source-address any
set security policies from-zone trust to-zone trust policy default-permit match destination-address any
set security policies from-zone trust to-zone trust policy default-permit match application any
set security policies from-zone trust to-zone trust policy default-permit then permit
set security policies from-zone trust to-zone untrust policy default-permit match source-address any
set security policies from-zone trust to-zone untrust policy default-permit match destination-address any
set security policies from-zone trust to-zone untrust policy default-permit match application any
set security policies from-zone trust to-zone untrust policy default-permit then permit
set security policies from-zone untrust to-zone trust policy default-deny match source-address any
set security policies from-zone untrust to-zone trust policy default-deny match destination-address any
set security policies from-zone untrust to-zone trust policy default-deny match application any
set security policies from-zone untrust to-zone trust policy default-deny then deny
set security zones security-zone trust tcp-rst
set security zones security-zone trust host-inbound-traffic system-services ping
set security zones security-zone trust interfaces ge-0/0/1.0
set security zones security-zone untrust screen untrust-screen
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services http
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services https
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ssh
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services telnet
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services dhcp
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ping
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic protocols ospf

Mattphew

This shouldn't be MTU issue:

root> show interfaces ge-0/0/0 detail | match MTU
Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed: 1000mbps,
Protocol inet, MTU: 1500, Generation: 148, Route table: 0


R1#show interfaces fa0/0 | i MTU
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reload@

I've had some weird issues before due to auto-negotiation especially when one side is a gig interface and the other side is FastEthernet. Have you tried just hard setting the speed and duplex settings:

Juniper:
set interfaces ge-0/0/0 speed 100m
set interfaces ge-0/0/0 link-mode full-duplex
set interfaces ge-0/0/0 gigether-options no-auto-negotiation

Cisco:
interface Fa0/0
speed 100
duplex full

If that doesn't work, you can always try traceoptions on the vSRX. That usually pinpoints any issues for me.

Mattphew

Hard settings didn't help.

Debuging on Cisco show that Hello packets are being sent to fa0/0 OSPF multicast address:

OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 33.1.1.3

But no Hellos are received through this interface.

Results from traceoptions in Juniper:

May 11 16:24:38 trace_on: Tracing to "/var/log/ospf-log" started
May 11 16:24:38.839685 OSPF sent Hello 33.1.1.2 -> 224.0.0.5 (ge-0/0/0.0 IFL 69 area 0.0.0.0)
May 11 16:24:38.840253 Version 2, length 48, ID 2.2.2.2, area 0.0.0.0
May 11 16:24:38.840262 mask 255.255.255.0, hello_ivl 10, opts 0x12, prio 128
May 11 16:24:38.840269 dead_ivl 40, DR 33.1.1.2, BDR 0.0.0.0
May 11 16:24:38.842666 OSPF sent Hello 33.1.1.2 -> 224.0.0.5 (ge-0/0/0.0 IFL 69 area 0.0.0.0)
May 11 16:24:38.842682 Version 2, length 48, ID 2.2.2.2, area 0.0.0.0
May 11 16:24:38.842695 mask 255.255.255.0, hello_ivl 10, opts 0x12, prio 128
May 11 16:24:38.842706 dead_ivl 40, DR 33.1.1.2, BDR 0.0.0.0
May 11 16:24:38.865651 OSPF built router LSA, area 0.0.0.0, link count 1
May 11 16:24:38.865702 OSPF built router LSA, area 0.0.0.1, link count 1
May 11 16:24:40.749483 OSPF rcvd Hello 33.1.1.3 -> 224.0.0.5 (ge-0/0/0.0 IFL 69 area 0.0.0.0)
May 11 16:24:40.749564 Version 2, length 44, ID 1.1.1.1, area 0.0.0.0
May 11 16:24:40.749579 checksum 0x0, authtype 0
May 11 16:24:40.749589 mask 255.255.255.0, hello_ivl 10, opts 0x12, prio 1
May 11 16:24:40.749597 dead_ivl 40, DR 33.1.1.3, BDR 0.0.0.0
May 11 16:24:48.200988 OSPF periodic xmit from 33.1.1.2 to 224.0.0.5 (IFL 69 area 0.0.0.0)
May 11 16:24:50.631296 OSPF hello from 33.1.1.3 (IFL 69, area 0.0.0.0) absorbed
May 11 16:24:57.240992 OSPF periodic xmit from 33.1.1.2 to 224.0.0.5 (IFL 69 area 0.0.0.0)
May 11 16:25:00.471500 OSPF hello from 33.1.1.3 (IFL 69, area 0.0.0.0) absorbed
May 11 16:25:05.142258 OSPF periodic xmit from 33.1.1.2 to 224.0.0.5 (IFL 69 area 0.0.0.0)
May 11 16:25:09.583736 OSPF hello from 33.1.1.3 (IFL 69, area 0.0.0.0) absorbed


It seems, that Hello packets are being sent and received, but absorbed.. What could cause this issue?

reload@

I see you have another thread on this and you mentioned that ping doesn't work. You should probably look into that first since ping is configured under host-inbound-traffic. Are the routers directly connected? Can you run "monitor traffic interface ge-0/0/0" on the vSRX and then ping the vSRX interface from R1. What's the output of monitor traffic?

Mattphew

Yes, i did not know under which section to post this thread, Cisco or Juniper, so i posted it in both.

So, Routers now are connected through Switch (basic switch (no configurable)).

I ran "monitor traffic interface ge-0/0/0".
Also made Ping:

R1#ping 33.1.1.2


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

22:54:01.832510 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, length 56
22:54:03.901237 Out IP truncated-ip - 20 bytes missing! 33.1.1.2 > 224.0.0.5: OSPFv2, Hello, length 60
22:54:10.401408 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:10.401478 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:11.512196 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, length 56
22:54:11.761425 Out IP truncated-ip - 20 bytes missing! 33.1.1.2 > 224.0.0.5: OSPFv2, Hello, length 60
22:54:12.391513 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:12.391540 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:13.871496 In ca:01:23:6c:00:08 > 01:00:0c:cc:cc:cc SNAP Unnumbered, ui, Flags [Command], length 60
22:54:14.391919 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:14.391946 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:16.397322 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:16.397361 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:18.396576 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:18.396611 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:20.537434 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, length 56
22:54:21.557312 Out IP truncated-ip - 20 bytes missing! 33.1.1.2 > 224.0.0.5: OSPFv2, Hello, length 60
22:54:30.177604 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, length 56
22:54:31.066517 Out IP truncated-ip - 20 bytes missing! 33.1.1.2 > 224.0.0.5: OSPFv2, Hello, length 60
22:54:31.533178 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:31.533262 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:33.531717 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:33.531756 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:35.531756 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:35.531787 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:37.531671 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:37.531708 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:39.532709 In arp who-has 33.1.1.2 tell 33.1.1.3
22:54:39.532738 Out arp reply 33.1.1.2 is-at 08:00:27:f9:fd:29
22:54:39.722909 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, length 56
22:54:40.196666 Out IP truncated-ip - 20 bytes missing! 33.1.1.2 > 224.0.0.5: OSPFv2, Hello, length 60
22:54:49.173429 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, length 56
22:54:50.181778 Out IP truncated-ip - 20 bytes missing! 33.1.1.2 > 224.0.0.5: OSPFv2, Hello, length 60
22:54:57.781851 Out IP truncated-ip - 20 bytes missing! 33.1.1.2 > 224.0.0.5: OSPFv2, Hello, length 60
22:54:59.047014 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, length 56
22:55:07.767076 Out IP truncated-ip - 20 bytes missing! 33.1.1
22:55:08.382934 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, le
22:55:13.877177 In ca:01:23:6c:00:08 > 01:00:0c:cc:cc:cc SNAP
22:55:17.587861 Out IP truncated-ip - 20 bytes missing! 33.1.1
22:55:18.122296 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, le
22:55:27.203199 Out IP truncated-ip - 20 bytes missing! 33.1.1
22:55:27.752380 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, le
22:55:35.613294 Out IP truncated-ip - 20 bytes missing! 33.1.1
22:55:36.877566 In IP 33.1.1.3 > 224.0.0.5: OSPFv2, Hello, le
22:55:44.657493 Out IP truncated-ip - 20 bytes missing! 33.1.1


It seems like there is problem with byte compatibility?

reload@

Disregard the thing that says 20 bytes missing. What I notice is here is that R1 is sending an ARP request, and the vSRX is sending an ARP reply but it's not making it back to R1. If the ARP reply made it back to R1, then you wouldn't see multiple ARP request for the same IP address. Bi-directional communication doesn't appear to be working.

Do a packet capture on R1 (right-click on the link and click Start capture, then choose the R1 Fa0/0 interface) and do another ping. Is the ARP reply being received on the interface of R1?

Edit: can you also post the output of "show interfaces fa0/0" on R1.

Mattphew

Yes, i've done Packet capture via Wireshark:

https://files.fm/u/m4cwcysj (there is the screenshot)

It seems that OSPF hello packets are with different byte size. (R1 - 90 bytes, but vSRX - 98 bytes). And also it seems that ARP request comes back.
And also in this case, there is still switch between two routers.

Mattphew

You can see screenshot with link, i provided, where You saw my network topology. There is still switch between two routers.
And also ARP request comes back to R1 but there is different Byte size for OSFP Hello packets - 90 bytes for R1 and 98 bytes for vSRX, they should be the same.

reload@

Your network topology doesn't have a switch between the vSRX and R1. Can you post the output of "show int fa0/0" and "show arp int f0/0".

Edit: I believe the initial Hello packets do not have to match in size. Once peering is established, the periodic Hellos do match. I'm watching a packet capture of a successful OSPF adjacency between an XRv and IOS, and it's showing this behavior.

Mattphew

R1#show interfaces fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is ca01.236c.0008 (bia ca01.236c.000
Internet address is 33.1.1.3/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
29 packets output, 3269 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out


R1#show arp interface fastEthernet 0/0
Protocol Address Age (min) Hardware Addr Type Interface
Internet 33.1.1.3 - ca01.236c.0008 ARPA FastEthernet0/0


R1#sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 33.1.1.3 - ca01.236c.0008 ARPA FastEthernet0/0
Internet 43.1.1.2 12 ca02.20e0.0008 ARPA FastEthernet0/1
Internet 43.1.1.3 - ca01.236c.0006 ARPA FastEthernet0/1

Mattphew

Also uploaded new scheme:
https://files.fm/u/m4cwcysj#/
There is switch between those routers now.

reload@

Notice how you don't have an ARP entry for 33.1.1.2 and your input says 0 packets even though the vSRX is sending ARP replies and OSPF Hellos.

Do you have OSPF adjacency between the vSRX and R2? I would try removing the switches and connecting the routers directly, or try using a different IOS.

Mattphew

I had no switch between R1 and vSRX in the first place, also removed it now, but nothing changed. I have been using Cisco 7200 chasis routers. Now i tried 2600 and 3600 chasis routers. Nothing changed all the same issue.

There is no OSPF adjacency between vSRX and R2, because interfaces are set to passive mode. But There was the same problem.

d4nz1g

Stick to the basics: no arp, no deal.

Are you running the Juniper device on a virtualization software? Your issue might be related to drivers and interaction between GNS and the software.
Had the same issue with IOS XRv