Bjørn Mork <bjorn@mork.no> writes:
Also adding a note about JUNOS (M/MX) usage of this dictionary.
I'm wondering if this is the best way to deal with this. Comments are appreciated. Some background: Juniper currently have two (well, they have more but we can simplify it to two for this discussion) platforms using RADIUS: JUNOS (T/M/MX routers) JUNOSe ("E-series", aka ERX, previously Unisphere ERX) Both have their own set of vendor specific attributes, using two different vendorid's. In FreeRADIUS, these VSAs are defined in dictionary.juniper (vendor=2636) and dictionary.erx (vendor=4874). Until recently, JUNOS has been used for "core" routers and JUNOSe has been used for "access" routers (i.e. the traditional NAS role). But now Juniper are adding more and more access services to JUNOS. For this they have added a separate "access" RADIUS service, using the ERX VSAs. So you now have JUNOS routers using both 2636 VSAs and 4874 VSAs. They have also added a few new JUNOS specific (AFAIK) VSAs to the 4874 dictionary, and some of the existing attributes have got new names in JUNOS (although their meaning are identical/similar to the meaning in JUNOSe). The JUNOS usage of 4874 VSAs is documented on http://www.juniper.net/techpubs/en_US/junos10.3/topics/reference/general/aaa... Well, for backwards compatibility I guess there is no question about the existing attributes. They should keep their "ERX-" name. But for consistency, I have suggested using the "ERX-" prefix for the new attributes as well. That's what's least confusing to my mind. But YMMV. So run discussion. I assume we are not the only ISP looking to replace our ERXes with MXes over the next few years. So keeping this dictionary compatible with both platforms is essential. Separate dictionaries will not work, as we need to configure accounts working on both JUNOS and JUNOSe. Bjørn