Hi, I'm seeing quite a few Mon Sep 18 15:02:40 2017 : Warning: EAP packets are arriving from two different upstream servers. Has there been a proxy fail-over? messages on my ORPS servers and I'm trying to find out where they come from. In normal log file they appear as shown. Mon Sep 18 15:02:34 2017 : Auth: (46576) Login OK: [sa1043@york.ac.uk] (from client roaming1.ja.net port 0 cli 48-74-6E-A3-67-2D via TLS tunnel) Mon Sep 18 15:02:36 2017 : Auth: (46591) Login OK: [hi555@york.ac.uk] (from client roaming0.ja.net6 port 8 cli 0C-D7-46-D9-46-66 via TLS tunnel) Mon Sep 18 15:02:36 2017 : Auth: (46592) Login OK: [hi555@york.ac.uk] (from client roaming0.ja.net6 port 8 cli 0C-D7-46-D9-46-66) Mon Sep 18 15:02:40 2017 : Warning: EAP packets are arriving from two different upstream servers. Has there been a proxy fail-over? Mon Sep 18 15:02:40 2017 : Auth: (46608) Login OK: [jr1236@york.ac.uk] (from client roaming1.ja.net port 0 cli CC-3A-61-EC-61-7A) Mon Sep 18 15:02:41 2017 : Auth: (46612) Login incorrect (eap: rlm_eap (EAP): No EAP session matching state 0x8cdc674b8cdd7eac): [gdv504@york.ac.uk] (from client roaming2.ja.net6 port 53 cli 38-0F-4A-30-B2-9C) Mon Sep 18 15:02:43 2017 : Auth: (46619) Login OK: [hbna500@york.ac.uk] (from client roaming0.ja.net port 8 cli 60-92-17-A5-51-75) Mon Sep 18 15:02:44 2017 : Info: Need 1 more connections to reach 10 spares However, when I try running FR in degug mode I never see the above errors. Have also tried running raddebug to dump output into another file ... and the normal file still has the aforementioned Warnings but the raddebug doesn't How am I supposed to get more info about the what the message relates to? BTW running 3.0.15 Rgds Alex
On Sep 18, 2017, at 10:11 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
I'm seeing quite a few Mon Sep 18 15:02:40 2017 : Warning: EAP packets are arriving from two different upstream servers. Has there been a proxy fail-over?
messages on my ORPS servers and I'm trying to find out where they come from.
They come because the packets for one EAP session are arriving from two different upstream home servers. i.e. packet 1 comes from upstream A, and packet 2 comes from upstream B. This usually indicates that the upstreams are broken, and failover over in stupid ways. Or, a server C is doing load-balancing across upstream server A and B, but isn't paying attention to the EAP state. They SHOULD be load-balancing based on something common to all of the EAP packets, like Calling-Station-ID. Or... maybe there are networking issues between your server and upstream server C. So server C thinks your site is down, and tries to fail-over to another path.
However, when I try running FR in degug mode I never see the above errors.
Running in debug mode shouldn't change the behaviour of the upstream servers. Alan DeKok.
They come because the packets for one EAP session are arriving from two different upstream home servers. Yup, know that, just want some info as to which upstream boxes they're coming from 1). These boxes are our ORPS boxes and primary upstream boxes are the JISC NRPS servers. 2). Or our Council has 1 RADIUS server that handles eduroam in York City Centre 3). Our our clearpass cluster that handles internal auths and does its own load balancing between our ORPS boxes. Was hoping that debug mode would tell me a bit about what was happening .. unless I need super debug mode !
Running in debug mode shouldn't change the behaviour of the upstream servers.
Granted ... but when I look in the normal radius.log and see the warning message and run raddebug at the same time and in the same time interval using raddebug -d /etc/freeradius -t 900 > ./alex.log & andthe radius log shows the message and the raddebug output doesn't ... not sure how I'm supposed to see what is going on. A On 18 September 2017 at 15:31, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 18, 2017, at 10:11 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
I'm seeing quite a few Mon Sep 18 15:02:40 2017 : Warning: EAP packets are arriving from two different upstream servers. Has there been a proxy fail-over?
messages on my ORPS servers and I'm trying to find out where they come from.
They come because the packets for one EAP session are arriving from two different upstream home servers.
i.e. packet 1 comes from upstream A, and packet 2 comes from upstream B.
This usually indicates that the upstreams are broken, and failover over in stupid ways. Or, a server C is doing load-balancing across upstream server A and B, but isn't paying attention to the EAP state.
They SHOULD be load-balancing based on something common to all of the EAP packets, like Calling-Station-ID.
Or... maybe there are networking issues between your server and upstream server C. So server C thinks your site is down, and tries to fail-over to another path.
However, when I try running FR in degug mode I never see the above errors.
Running in debug mode shouldn't change the behaviour of the upstream servers.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Sep 18, 2017, at 10:53 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Yup, know that, just want some info as to which upstream boxes they're coming from
Ah... edit the message and recompile. :(
1). These boxes are our ORPS boxes and primary upstream boxes are the JISC NRPS servers. 2). Or our Council has 1 RADIUS server that handles eduroam in York City Centre 3). Our our clearpass cluster that handles internal auths and does its own load balancing between our ORPS boxes.
Was hoping that debug mode would tell me a bit about what was happening .. unless I need super debug mode !
No. The message just doesn't print the IPs.
Granted ... but when I look in the normal radius.log and see the warning message and run raddebug at the same time and in the same time interval using
raddebug -d /etc/freeradius -t 900 > ./alex.log &
andthe radius log shows the message and the raddebug output doesn't ...
not sure how I'm supposed to see what is going on.
Those messages go to the log file, and not to the raddebug output. At the point they're produced, the code can't print to the request debug output. Alan DeKok.
hi, IIRC the UK national eduroam proxies will ensure that an EAP session isnt sprayed to different servers but if the next hop up is throwing them to different boxes then they cant do anything about that....would suggest that you ran a full tcpdump (capture packets in entirety) and view them with a RADIUS-capable reader to see what the packets are showing you - hopefully the contents will have some attributes to help find the source of the issues (either from Europe or from a UK site with poorly configured RADIUS server... i'd go for NPS box with basic loadbalance values that mean it sprays but it could equally be a FreeRADIUS < 2.2.6 box with load-balance enabled for EAP :( (thats if the source IS from the eduroam side....) alan
There's not many clients our ORPS boxes talk to Clearpass on campus a couple of Fr 3.0.15 boxdes on campus NRPS boxes City Centre (rukus) wifi Yorkshire district hospitals Cisco :-( All I need is a pointer .. o.k. tcdump it is A On 18 September 2017 at 20:08, Alan Buxey <alan.buxey@gmail.com> wrote:
hi, IIRC the UK national eduroam proxies will ensure that an EAP session isnt sprayed to different servers but if the next hop up is throwing them to different boxes then they cant do anything about that....would suggest that you ran a full tcpdump (capture packets in entirety) and view them with a RADIUS-capable reader to see what the packets are showing you - hopefully the contents will have some attributes to help find the source of the issues (either from Europe or from a UK site with poorly configured RADIUS server... i'd go for NPS box with basic loadbalance values that mean it sprays but it could equally be a FreeRADIUS < 2.2.6 box with load-balance enabled for EAP :( (thats if the source IS from the eduroam side....)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Sep 19, 2017, at 4:44 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
There's not many clients our ORPS boxes talk to
Clearpass on campus a couple of Fr 3.0.15 boxdes on campus NRPS boxes City Centre (rukus) wifi Yorkshire district hospitals Cisco :-(
All I need is a pointer ..
I pushed some patches to the v3.0.x branch. The warning message should now include IP addresses. Alan DeKok.
many thanks A On 19 September 2017 at 12:52, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 19, 2017, at 4:44 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
There's not many clients our ORPS boxes talk to
Clearpass on campus a couple of Fr 3.0.15 boxdes on campus NRPS boxes City Centre (rukus) wifi Yorkshire district hospitals Cisco :-(
All I need is a pointer ..
I pushed some patches to the v3.0.x branch. The warning message should now include IP addresses.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
....the UK national eduroam proxies will ensure that an EAP session isnt sprayed to different servers but if the next hop up is throwing them to different boxes then they cant do anything about that....would suggest that you ran a full tcpdump (capture packets in entirety) and view them with a RADIUS-capable reader to see what the packets are showing you - hopefully the contents will have some attributes to help find the source of the issues (either from Europe or from a UK site with poorly configured RADIUS server... i'd go for NPS box with basic loadbalance values that mean it sprays but it could equally be a FreeRADIUS < 2.2.6 box with load-balance enabled for EAP :( (thats if the source IS from the eduroam side....)
O.K. I just configured one of my ORPS boxes to be "client only" as far as the NRPS kit is concerned (eduroam4), and all my EAP error messages have gone away. Tomorrow I'll install the latest FR 3.0 code so I can see where the requests coming from... guess it'll verify that they're via the NRPS servers. ... and then go down the tcpdump route for detailed stuff A On 18 September 2017 at 20:08, Alan Buxey <alan.buxey@gmail.com> wrote:
hi, IIRC the UK national eduroam proxies will ensure that an EAP session isnt sprayed to different servers but if the next hop up is throwing them to different boxes then they cant do anything about that....would suggest that you ran a full tcpdump (capture packets in entirety) and view them with a RADIUS-capable reader to see what the packets are showing you - hopefully the contents will have some attributes to help find the source of the issues (either from Europe or from a UK site with poorly configured RADIUS server... i'd go for NPS box with basic loadbalance values that mean it sprays but it could equally be a FreeRADIUS < 2.2.6 box with load-balance enabled for EAP :( (thats if the source IS from the eduroam side....)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
participants (3)
-
Alan Buxey -
Alan DeKok -
Alex Sharaz