0

I am trying to setup a OSPF area between a Juniper MX80 and a Quagga router. The Quagga router has OSPF configured and network 199.192.100.0/28 advertised in the hello packet. But the Juniper MX80 is rejecting it with the following error:

Jan 22 04:14:38.371296 OSPF packet ignored: subnet mismatch from 199.192.100.2 on intf ae0.0 area 0.0.0.0
Jan 22 04:14:38.371515 OSPF rcvd Hello 199.192.100.2 -> 224.0.0.5 (ae0.0 IFL 336 area 0.0.0.0)
Jan 22 04:14:38.371538   Version 2, length 44, ID 10.10.90.4, area 0.0.0.0
Jan 22 04:14:38.371559   checksum 0x0, authtype 0
Jan 22 04:14:38.371581   mask 255.255.255.240, hello_ivl 10, opts 0x2, prio 1
Jan 22 04:14:38.371602   dead_ivl 40, DR 199.192.100.2, BDR 0.0.0.0

The relevant parts of the config are:

Juniper MX80:

ashinn@mx2# show interfaces ae0 
aggregated-ether-options {
    lacp {
        active;
    }
}
unit 0 {
    family inet {
        address 199.192.100.253/30;
    }
}

ashinn@mx2# show protocols ospf   
export redistributeconnected;
area 0.0.0.0 {
    area-range 199.192.100.0/28;
    interface xe-0/0/1.0;
    interface ae0.0 {
        interface-type p2p;
    }
}

Interface ae0.0 is the interface which faces the Quagga router bond0 interface:

!
interface bond0
 ip ospf cost 50
 ipv6 nd suppress-ra
!
router ospf
 log-adjacency-changes
 redistribute kernel
 redistribute connected
 network 199.192.100.0/28 area 0.0.0.0
 neighbor 199.192.100.253
!

And the Quagga interface for bond0:

[ashinn@lb2 ~]$ ip addr show dev bond0
8: bond0:  mtu 1500 qdisc noqueue state UP 
    link/ether 00:25:90:27:8a:be brd ff:ff:ff:ff:ff:ff
    inet 199.192.100.254/30 brd 199.192.100.255 scope global bond0
    inet 199.192.100.2/28 scope global bond0
    inet6 fe80::225:90ff:fe27:8abe/64 scope link 
       valid_lft forever preferred_lft forever

I have tried without the neighbor statement in Quagga and also tried setting ip ospf network point-to-point in Quagga also. Neither seem to make any difference.

I found this article http://kb.juniper.net/InfoCenter/index?page=content&id=KB23533&cat=T1600_1&actp=LIST&showDraft=false which seems to explain the same issue. But it only suggests to correct the subnet mask mismatch. Where might this mismatch be? If it is conflicting with the /30 point to point interface subnet, then why?

2
  • 1
    Your subnetting is terribly confusing here... why are there both /30's and /28s? I guess I'm asking why the bond0 interface has both the /30 point to point network and the /28 on the same interface? Jan 23, 2013 at 5:04
  • The bond0 interface is public facing the router. The /30 are point to point links to establish routing protocol connections. The /28 is what clients will actually connect to. The idea is that the /28 will eventually float between 2 Quagga hosts (lb2 and lb1) so the /30 is the permanent part of this equation.
    – Andy Shinn
    Jan 23, 2013 at 16:09

3 Answers 3

1

The problem is that you have the wrong subnet configured in OSPF in Quagga. You need the /30 as network statement:

network 199.192.100.252/30 area 0.0.0.0

The network statement tells Quagga on which interface to enable OSPF. Every interface that has an IP from that subnet will have OSPF enabled.

Likewise the 199.192.100.2/28 should probably not be on that bond0 device. Try putting it on the lo interface and tell that interface to be a passive interface.

Like this:

!
interface bond0
 ip ospf cost 50
 ipv6 nd suppress-ra
!
router ospf
 log-adjacency-changes
 redistribute kernel
 redistribute connected
 network 199.192.100.252/30 area 0.0.0.0
 network 199.192.100.0/28 area 0.0.0.0
 passive-interface lo
 neighbor 199.192.100.253
!

Also I would recommend setting the OSPF interface mode between MX80 and Quagga to point-to-point. This will speed up convergence time.

1
  • I will try this in my next maintenance window. Thanks for the suggestions!
    – Andy Shinn
    Apr 22, 2013 at 18:47
0

Your /30 range that the OSPF neighbors are partially trying to form an adjacency on falls outside the /28 that is enabled for OSPF... which is where the subnet mask mismatch is coming from. The debug output tells you everything you need to know to fix it. OSPF rcvd Hello should match the other side. IF the masks don't match, an adjacency will never form.

You would be much better off having distinct connections between the MX80 + Quagga routers, or at least a network segment dedicated to OSPF between the three (although in this case, you'd need to have interface-type p2p turned off, because you'd want a DR election. The reason you had this issue in the first place was that Quagga was trying to establish an OSPF adjacency with Hello packets from the wrong subnet/configured IP.

It's difficult to know what else is wrong without full configs, but I would be really careful, considering the current config, and what can happen with those redistribution commands ;)

2
  • May be I am misunderstanding the network statement in terms of OSPF. In theory, if I set network 199.192.100.0/24 area 0.0.0.0 instead (so that the /30's fall inside the area) would this allow the adjacency to form? I was trying to make the OSPF network analogy to BGP, in that it would "announce" that network to the other routers.
    – Andy Shinn
    Feb 12, 2013 at 19:02
  • 1
    Yes. I think there's a lot more that goes outside the scope of a quick discussion here, but I highly recommend Juniper's course materials for the JNCIA and JNCIP-Ent. You can get free PDFs from the Fast Track program, which is on their site under education, and if you choose to buy the actual course materials, some come with test vouchers. The certifications are great for your career, but also for filling in the gaps. To properly answer your original question, I'd need to see the whole configs, as there are other concerns about what's going on... Feb 21, 2013 at 9:37
0

I know this is a little late, but for clarification, several things must match for OSPF to form neighbor relationships. These include area number, interface type (point to point or broadcast) hello timers, dead timers and subnet mask of the interfaces that are forming neighbors. The MX is looking for it's neighbor to be on the exact same subnet mask as the local MX interface.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .