+ Reply to Thread
Results 1 to 20 of 20
  1. Junior Member
    Join Date
    May 2016
    Posts
    12
    #1

    Default TSHOOT: OSPF neighborship won't come UP

    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!
    Reply With Quote Quote  

  2. SS -->
  3. Went to the dark side.... Moderator networker050184's Avatar
    Join Date
    Jul 2007
    Posts
    11,680

    Certifications
    CCNA, CCNP, CCIP, JNCIA-JUNOS, JNCIS-SP, JNCIP-SP, MCA200
    #2
    First thing that comes to mind is MTU.
    An expert is a man who has made all the mistakes which can be made.
    Reply With Quote Quote  

  4. Junior Member
    Join Date
    May 2016
    Posts
    12
    #3
    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?
    Reply With Quote Quote  

  5. Went to the dark side.... Moderator networker050184's Avatar
    Join Date
    Jul 2007
    Posts
    11,680

    Certifications
    CCNA, CCNP, CCIP, JNCIA-JUNOS, JNCIS-SP, JNCIP-SP, MCA200
    #4
    How did you set the MTU exactly? An Ethernet interface with 1500 on a junos device is not the same as an IOS device.
    An expert is a man who has made all the mistakes which can be made.
    Reply With Quote Quote  

  6. Member reload@'s Avatar
    Join Date
    May 2016
    Location
    DMV
    Posts
    44

    Certifications
    CCNP, JNCIP
    #5
    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?
    Reply With Quote Quote  

  7. Junior Member
    Join Date
    May 2016
    Posts
    12
    #6
    I have tried to set MTU in this way on Juniper:

    How to change the media MTU:

    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
    Reply With Quote Quote  

  8. Junior Member
    Join Date
    May 2016
    Posts
    12
    #7
    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,
    Reply With Quote Quote  

  9. Member reload@'s Avatar
    Join Date
    May 2016
    Location
    DMV
    Posts
    44

    Certifications
    CCNP, JNCIP
    #8
    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.
    Reply With Quote Quote  

  10. Junior Member
    Join Date
    May 2016
    Posts
    12
    #9
    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?
    Reply With Quote Quote  

  11. Member reload@'s Avatar
    Join Date
    May 2016
    Location
    DMV
    Posts
    44

    Certifications
    CCNP, JNCIP
    #10
    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?
    Reply With Quote Quote  

  12. Junior Member
    Join Date
    May 2016
    Posts
    12
    #11
    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?
    Reply With Quote Quote  

  13. Member reload@'s Avatar
    Join Date
    May 2016
    Location
    DMV
    Posts
    44

    Certifications
    CCNP, JNCIP
    #12
    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.
    Last edited by reload@; 05-11-2016 at 09:38 PM.
    Reply With Quote Quote  

  14. Junior Member
    Join Date
    May 2016
    Posts
    12
    #13
    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.
    Reply With Quote Quote  

  15. Junior Member
    Join Date
    May 2016
    Posts
    12
    #14
    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.
    Reply With Quote Quote  

  16. Member reload@'s Avatar
    Join Date
    May 2016
    Location
    DMV
    Posts
    44

    Certifications
    CCNP, JNCIP
    #15
    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.
    Last edited by reload@; 05-12-2016 at 12:27 AM.
    Reply With Quote Quote  

  17. Junior Member
    Join Date
    May 2016
    Posts
    12
    #16
    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
    Last edited by Mattphew; 05-12-2016 at 06:07 AM. Reason: added information.
    Reply With Quote Quote  

  18. Junior Member
    Join Date
    May 2016
    Posts
    12
    #17
    Also uploaded new scheme:
    https://files.fm/u/m4cwcysj#/
    There is switch between those routers now.
    Reply With Quote Quote  

  19. Member reload@'s Avatar
    Join Date
    May 2016
    Location
    DMV
    Posts
    44

    Certifications
    CCNP, JNCIP
    #18
    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.
    Reply With Quote Quote  

  20. Junior Member
    Join Date
    May 2016
    Posts
    12
    #19
    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.
    Reply With Quote Quote  

  21. Padawan d4nz1g's Avatar
    Join Date
    May 2013
    Location
    Brazil
    Posts
    430

    Certifications
    CCIE RS, CCNP RS, CCNA RS, CCNA S, ITILF
    #20
    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
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks