Question

PacketFence and Summit switches


Userlevel 1
Sorry for the amount of detail, but we are trying to setup PacketFence with our Summit switches and I think everything looks fine on the PacketFence side, but I keep getting the following on the test switch:

07/30/2014 13:47:39.42 [i] Slot-1: Authentication failed for Network Login MAC user 3C970EADB66B Mac 3C:97:0E:AD:B6:6B port 5:13

07/30/2014 13:47:39.42 Slot-1: No response from server 172.22.0.3 trying local.

07/30/2014 13:47:39.42 Slot-1: No servers responding

07/30/2014 13:47:36.42 Slot-1: Resend request to Authentication Server address 172.22.0.3 current request count is 2

07/30/2014 13:47:33.41 Slot-1: Resend request to Authentication Server address 172.22.0.3 current request count is 1

What steps can I perform on the switch to verify connectivity? I can ping/trace to the PacketFence server from the switch.

We have PacketFence installed on a server (172.22.0.3). We have three interfaces defined in PacketFence: Management (172.22.0.3/23), Isolation (12.22.2.3/23), and Registration (172.22.38.3/23). Those interfaces are plugged into our core Extreme Networks Summit switch into matching VLANs: “Internal_Appliances” (172.22.0.1/23), “MAC_Isolation” (172.22.2.1/23), and “MAC_Registration” (172.22.38.1/23).

That switch is then uplinked to our desktop switch, where we have created a “MAC_Isolation” (172.22.2.2/23), “MAC_Registration” (172.22.38.2/23), MAC_Temp (no IP), and “Desktops” (172.22.34.2/23). We want the ports to eventually end up in the “Desktops” VLAN after authorization.

The steps below were performed on the Extreme switch to which the desktops are connected, using Port 5:13 as our test.



create vlan MAC_Registration

config vlan "MAC_Registration" tag 369

create vlan MAC_Temp

enable snmp access

configure snmp add trapreceiver 172.22.0.3 community public vr VR-DEFAULT

configure vlan MAC_Registration add ports 5:13 untagged

configure ports 5:13 vlan MAC_Registration lock-learning

disable snmp traps port-up-down ports 5:13

configure radius netlogin primary server 172.22.0.3 1812 client-ip 172.22.32.2 vr VR-Default

configure radius netlogin primary shared-secret (password)

enable radius netlogin

configure netlogin vlan MAC_Temp

enable netlogin mac

configure netlogin dynamic-vlan enable

configure netlogin dynamic-vlan uplink-ports 4:45

configure netlogin mac authentication database-order radius

enable netlogin ports 5:13 mac

configure netlogin ports 5:13 mode port-based-vlans

configure netlogin ports 5:13 no-restart

The results of “show netlogin” and “show radius” on the switch returns the following:

Slot-1 Stack.4 # show netlogin

NetLogin Authentication Mode : web-based DISABLED; 802.1x DISABLED; mac-based ENABLED

NetLogin VLAN : "MAC_Temp"

NetLogin move-fail-action : Deny

NetLogin Client Aging Time : 5 minutes

Dynamic VLAN Creation : Enabled

Dynamic VLAN Uplink Ports : 4:45



------------------------------------------------

Web-based Mode Global Configuration

------------------------------------------------

Base-URL : network-access.com

Default-Redirect-Page : ENABLED; http://www.extremenetworks.com

Logout-privilege : YES

Netlogin Session-Refresh : ENABLED; 3 minute(s) 0 second(s)

Refresh failures allowed : 0

Reauthenticate on refresh: Disabled

Authentication Database : Radius, Local-User database

Proxy Ports : 80(http),443(https)

------------------------------------------------



------------------------------------------------

802.1x Mode Global Configuration

------------------------------------------------

Quiet Period : 60

Supplicant Response Timeout : 30

Re-authentication period : 3600

Max Re-authentications : 3

RADIUS server timeout : 30

EAPOL MPDU version to transmit : v1

Authentication Database : Radius

------------------------------------------------



------------------------------------------------

MAC Mode Global Configuration

------------------------------------------------



MAC Address/Mask Password (encrypted) Port(s)

-------------------- ------------------------------ ------------------------

Default any



Re-authentication period : 0 (Re-authentication disabled)

Authentication Database : Radius

------------------------------------------------



Port: 5:13, Vlan: MAC_Registration, State: Enabled, Authentication: mac-based

Guest Vlan : Disabled

Authentication Failure Vlan : Disabled

Authentication Service-Unavailable Vlan : Disabled



MAC IP address Authenticated Type ReAuth-Timer User

3c:97:0e🇦🇩b6:6b 0.0.0.0 No MAC 0

-----------------------------------------------

(B) - Client entry Blackholed in FDB





Number of Clients Authenticated : 0



Slot-1 Stack.5 # show radius

Switch Management Radius: disabled

Switch Management Radius server connect time out: 3 seconds

Switch Management Radius Accounting: disabled

Switch Management Radius Accounting server connect time out: 3 seconds

Netlogin Radius: enabled

Netlogin Radius server connect time out: 3 seconds

Netlogin Radius Accounting: disabled

Netlogin Radius Accounting server connect time out: 3 seconds



Primary Netlogin Radius server:

Server name :

IP address : 172.22.0.3

Server IP Port: 1812

Client address: 172.22.38.2 (VR-Default)

Shared secret : 2\q;sJ;@F=8Bjn

Access Requests : 13752 Access Accepts : 0

Access Rejects : 0 Access Challenges : 0

Access Retransmits: 9168 Client timeouts : 4584

Bad authenticators: 0 Unknown types : 0

Round Trip Time : 0

9 replies

Userlevel 4
Stephen,

I would start by running packet capture on the interface of the PacketFence and seeing if you get a RADIUS request there from the switch. If you are not getting a request, then there is a problem network connectivity and you should try 'ping vr "VR-Default" 172.22.0.3 from 172.22.38.2'

If you are getting RADIUS requests on the Packetfence interface then most likely the packetfence server isn't set up properly to accept the RADIUS requests. I haven't used Packetfence myself, but I would check the area where you configure RADIUS clients and ensure the shared secret is correct and that the correct Switch IP is added.

Tyler
Userlevel 1
I jumped right into the ping step and the command that you gave me failed. On the switch with the 172.22.38.2 VLAN there is also a VLAN that is 172.22.0.2/23 and pinging from that worked.

How can I further troubleshoot why the communication is failing from the 172.22.38.2 address?

Slot-1 Stack.4 # ping vr "VR-Default" 172.22.0.3 from 172.22.38.2
Ping(ICMP) 172.22.0.3: 4 packets, 8 data bytes, interval 1 second(s).

--- 172.22.0.3 ping statistics ---
4 packets transmitted, 0 packets received, 100% loss
round-trip min/avg/max = 0/0/0 ms

Slot-1 Stack.5 # ping vr "VR-Default" 172.22.0.3 from 172.22.0.2
Ping(ICMP) 172.22.0.3: 4 packets, 8 data bytes, interval 1 second(s).
16 bytes from 172.22.0.3: icmp_seq=0 ttl=64 time=1.985 ms
16 bytes from 172.22.0.3: icmp_seq=1 ttl=64 time=1.832 ms
16 bytes from 172.22.0.3: icmp_seq=2 ttl=64 time=1.894 ms
16 bytes from 172.22.0.3: icmp_seq=3 ttl=64 time=14 ms

--- 172.22.0.3 ping statistics ---
4 packets transmitted, 4 packets received, 0% loss
round-trip min/avg/max = 1/5/14 ms
Userlevel 4
My initial guess would be there there is no route between the two addresses and therefore they cannot communicate. You can try the traceroute command to find out where the communication stops. Wherever it stops is most likely where the route is missing. One option that you can try would be to change your RADIUS client settings so that the RADIUS request comes from the directly connected interface. This would look like this:

configure radius netlogin primary server 172.22.0.3 1812 client-ip 172.22.0.2 vr VR-Default

That would make the RADIUS request come from the 0.2 address instead of the 38.2 address.
Userlevel 1
Route table on desktop switch is below. 172.22.32.1 is a virtual router on our core switch.

Desktop switch
Ori Destination Gateway Mtr Flags VLAN Duration
#s Default Route 172.22.32.1 1 UG---S-um--f- Appliances 1d:0h:50m:52s
#d 172.22.0.0/23 172.22.0.2 1 U------um--f- Internal_Appliances 0d:3h:45m:5s

Routing on our core switch is then:
Core switch (where 172.22.0.3 is connected)
Ori Destination Gateway Mtr Flags VLAN Duration
#s Default Route 172.22.32.5 1 UG---S-um--f- Appliances 670d:15h:2m:3s
#d 172.22.0.0/23 172.22.0.1 1 U------um--f- Internal_Appliances 408d:14h:31m:53s

Yet, a trace from the desktop switch dies immediately.

Slot-1 Stack.10 # trace 172.22.0.3
traceroute to 172.22.0.3, 30 hops max
1 * * *
2 * * *
3 * ^C

Even adding a static route still dies.
Slot-1 Stack.11 # config iproute add 172.22.0.3 255.255.255.255 172.22.0.1
* Slot-1 Stack.12 # trace 172.22.0.3
traceroute to 172.22.0.3, 30 hops max
1 172.22.0.1 11 ms 16 ms 13 ms
2 * * *
3 * * ^C *
Userlevel 1
This is getting weirder and weirder. With a VLAN on the desktop switch that is 172.22.0.2/23, I can then ping the PacketFence host on the core switch (172.22.0.1) but I cannot trace to it. If I delete the VLAN from the desktop switch, I can no longer ping the PacketFence server from the desktop switch but I can trace it to one hop and then it dies. I am able to ping/trace to the PacketFence server from my desktop PC which is connected to the desktop switch and I can load the web interface on that server, just not sure why the actual communication is falling apart from switch to switch when it works from my PC to the server which are plugged into the switches.

Oddly, the trace dies at the very first hop.

IP Route on Desktop Switch:
Ori Destination Gateway Mtr Flags VLAN Duration
#s Default Route 172.22.32.1 1 UG---S-um--f- Appliances 1d:4h:40m:19s

IP Route on Core switch where PacketFence (172.22.0.3) server is located
Ori Destination Gateway Mtr Flags VLAN Duration
#s Default Route 172.22.32.5 1 UG---S-um--f- Appliances 670d:18h:46m:32s
#d 172.22.0.0/23 172.22.0.1 1 U------um--f- Internal_Appliances 408d:18h:16m:22s
#d 172.22.32.0/24 172.22.32.1 1 U------um--f- Appliances 670d:19h:2m:6s

Here is the trace with no 172.22.0.2/23 VLAN on the switch:
traceroute to 172.22.0.3, 30 hops max
1 172.22.32.1 14 ms 9 ms 15 ms
2 * * *
3 * ^C

And the ping with no 172.22.0.2/23 VLAN:
* Slot-1 Stack.26 # ping 172.22.0.3
Ping(ICMP) 172.22.0.3: 4 packets, 8 data bytes, interval 1 second(s).

--- 172.22.0.3 ping statistics ---
4 packets transmitted, 0 packets received, 100% loss
round-trip min/avg/max = 0/0/0 ms

The trace with the 172.22.0.2/23 VLAN on the switch:
traceroute to 172.22.0.3, 30 hops max
1 * * *
2 * * ^C

And the ping with the 172.22.0/2/23 VLAN:
* Slot-1 Stack.17 # ping 172.22.0.3
Ping(ICMP) 172.22.0.3: 4 packets, 8 data bytes, interval 1 second(s).
16 bytes from 172.22.0.3: icmp_seq=0 ttl=64 time=17 ms
16 bytes from 172.22.0.3: icmp_seq=1 ttl=64 time=4.082 ms
Userlevel 1
We got this working finally, but now we realized that this method won't allow us to Wake On LAN unless someone has another solution.

Basically, devices are put int the "MAC_Temp" VLAN when powered off which appears to be a L2 VLAN that we can't forward anything to. Does anyone have any solutions on how to work around that?

Also, it looks like 802.1x instead of mac based authentication might allow WOL to work?
Userlevel 4
Try using 'configure netlogin ports allow egress-traffic all_cast'. This will allow all traffic to egress a port while in the unauthenticated state.
Userlevel 1
That allows traffic out of the port, but it doesn't help with routing the WOL packet to the device on the port.
Userlevel 4
Sorry, I'm not familiar with the way that packet fence operates, however, if it's not routable, then there most likely wouldn't be a way to get a WOL packet to that device unless it's on the same VLAN.

Reply