Monday, January 14, 2019

SRX and my no good, very bad "bd index" error

I'm hoping this ends up being an easy thing, but I haven't really been able to track down much in the way of what on earth this means and how I fix it. I am relatively new to JunOS and yet newer to this side of the SRX.

SRX320 w/ 15.1X49-D150.2

Want to do local DHCP serving (using jdhcp) for multiple subnets. Or have a mix of local server and relay, but I gather that's a no-go (have to do local server or all relay) and it never worked whatsoever for me when I had both configured.

I've gotten it to work for 2 of 3 irbs now. All three are configured identically apart from names and subnets. I and coworkers have been over it several times now to make sure they match up. Something is going awry with processing the client's DISCOVERY, but only for the one VLAN.

When I plug a client into an interface tied to VLAN 10 / irb.10, I see this error in the trace file:

[MSTR][NOTE] [default:default][SVR][INET][SID=0] jdhcpd_packet_handle: Failed to find L2 subunit stack or ifbd for Client on L2 ifindex 76, L3 ifindex 85

When I plug a client into any of the other two interfaces tied to VLAN/irb.20 or 31, I get this instead:

[MSTR][DEBUG][default:default][SVR][INET][SID=0] jdhcpd_packet_handle: Client on L2 ifindex 74, bd index 7, L3 ifindex 86

And yes, the zones allow DHCP. 20 and 10 are in the same zone, though they are separate vlans/irbs.

What is this "bd index" thing? I feel like the SRX has told me the answer to the ultimate question and it was... 42. What do I do with that answer? Not sure how to even show what bd index values anything has. I don't have anything setup to do with bridges that I can find, which was my first thought on what "bd" meant.

I can include config if you guys really want, but at the moment I'm more curious about the mystery of the bd index and why I have/don't have them.

Edit: Is it possibly related to the "Routing/Vlan index" under IFBD in "show ethernet-switching interface extensive"? This appears to correspond to the VLAN index #, or it's a coincidence. The extensive output for the "broken" interface does seem to show all the same info, however (with index 8, instead of 7, which corresponds to the proper VLAN). Also, the issue appears to be tied to the VLAN, not the interface.

More Edit: I think it might be a bug..... Reboot seems to fix it, but... how do I know when/if it will recur now, since I don't know what caused it? Anyone run into anything similar?



No comments:

Post a Comment