This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

OSPF not received on RED client XG

I am having an issue with one RED tunnel and OSPF. I have a couple of sites with XG devices that I use OSPF for my subnets already, however this one device is not working and I can't figure out why it is not.

My XG acting as the RED server shows both in and out traffic using a packet capture for 'proto OSPFIGP':

My remote XG acting as the RED Client only shows outbound OSPF:

The server device doesn't show the remote device as a neighbor, but the client device does show the server device as a neighbor but never leaves the initialization state:

I've put static routes in place and can get traffic to pass over the RED tunnel, but it looks like the OSPF packets are not even getting received on the client device when I run a packet captuer. Has anyone seen this or know what things I should be checking? I've never seen this before and I am running similar configurations on other sites already.



This thread was automatically locked due to age.
Parents
  • Could you solve the issue? I have the same problem.

    I have a capture from both devices:

    One of the XG:

    SG135_XN01_SFOS 18.0.3 MR-3# tcpdump -nni reds104
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on reds104, link-type EN10MB (Ethernet), capture size 262144 bytes
    12:38:04.644404 reds104, IN: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:13.204477 reds104, OUT: IP 10.253.0.106 > 224.0.0.5: OSPFv2, Hello, length 48
    12:38:14.644545 reds104, IN: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:23.204731 reds104, OUT: IP 10.253.0.106 > 224.0.0.5: OSPFv2, Hello, length 48
    12:38:24.644406 reds104, IN: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:33.204822 reds104, OUT: IP 10.253.0.106 > 224.0.0.5: OSPFv2, Hello, length 48
    12:38:34.644575 reds104, IN: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:43.205270 reds104, OUT: IP 10.253.0.106 > 224.0.0.5: OSPFv2, Hello, length 48

    XG210_WP02_SFOS 18.0.3 MR-3# tcpdump -nni reds104
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on reds104, link-type EN10MB (Ethernet), capture size 262144 bytes
    12:38:14.642641 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:24.642707 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:34.642778 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:44.642856 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:38:54.642931 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:39:04.643238 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:39:14.644029 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44
    12:39:24.645047 reds104, OUT: IP 10.253.0.105 > 224.0.0.5: OSPFv2, Hello, length 44

    Both devices are in 18.0.3 MR3.

    reds104 are configure as POINT-TO-MULTIPOINT.

    I tried to configure a static route to the other XG throught the RED while I solve this problem and it also ignore that route randomly. I could see the static route using "ip route".

    192.168.15.0/24 via 10.253.0.102 dev reds100 proto zebra metric 210

  • So here's the fix for this, they have a hard limit set to 20 for the buffer on the interfaces on the back-end, why they have a hard limit of 20 makes no sense, no one is going to build small OSPF networks over RED tunnels! its a Quagga limitation that can be increased on the backend!

    problem: https://ideas.sophos.com/forums/330219-xg-firewall/suggestions/35535115-fix-the-ospf-interfaces-limit-about-10-20

    Solution: https://support.sophos.com/support/s/article/KB-000036757?language=en_US

    Cyber83

  • I could see that before and I needed as well. My problem is that traffic is lost within the RED tunnel. Not only OSPF traffic. In this case the hello packet is not being received.

Reply Children
No Data