I recently ran into an issue on ISE 2.3 Patch 5 when trying to modify a Hotspot Guest Portal that had been created in the ISE Portal Builder.
The support people with the ISEPB team gave me the answer, so I thought I'd save someone an email and write this up.
I created a Hotspot portal in ISE Portal Builder and uploaded it. Once uploaded into ISE, I need to change the port and interface it was using, but any time I would click on Save, I would get a pop-up error that said "Invalid input format detected. HTML tags, scripts or % characters are not supported."
First, created a nice Hotspot Guest Portal in ISE PB:
Uploaded it, went into ISE to change something, hit save... and...
This only seems to happen with Hotspot portals. Sponsored Guest and Sponsor portals seem to work just fine.
It turns out that ISE PB inserts some HTML into a field that shouldn't have HTML in it.
That's what's causing the error. It also puts some gibberish into some other fields, but that seems to be a cosmetic problem.
So go into Work Centers > Guest Access > Portals & Components > Guest Portals - and find your Hotspot portal.
Click on Portal Page Customization.
First thing, you'll probably see HTML in the Banner Title field.
<p><span style="color:#000000;">Guest Wi-Fi Portal</span></p>
Remove all the HTML so you just have text left.
Guest Wi-Fi Portal
That's enough to get rid of the error, but a few fields have gibberish in them. That annoyed me so I removed it all.
Next, go through each pages looking for any HTML that snuck in anywhere.
Click through each of these pages:
Thanks for reading, and good luck!
... View more
Hi everyone, I have an interesting QoS issue, and while I've found a solution, I wonder if there's a better way.
This is for a radio station that is sending audio from the station to the transmitter on a mountain via a T1. Historically they've used a device that will divide the T1's time-slots up to deliver digital audio (not IP audio), and use the remaining time-slots to extend a LAN to the other side.
They're now switching over to use IP audio codec appliances to deliver a one-way UDP stream from the station to the mountain top. I have now been given all 24 time-slots (1.544 mbps) for IP traffic, and need to ensure as close to 0% packet loss on the UDP stream as possible. The catch being that I need to use the existing LAN extender equipment, whereas normally I'd want to put in a pair of routers with serial cards in place.
The IP audio codec tags its UDP packets with a DSCP value of "ef". I tried several policy-maps based on that, giving priority to "ef", but I was still able to create a massive packet loss rate by doing things like FTPing files up. In this case, packet loss means dead air on the radio station.
Eventually I came up with the following policy-map that polices "ef" traffic, giving a hard 700 kbps. All other traffic gets 715 kbps, with anything exceeding that getting dropped. It works. It's solid. I've flooded that link with non-DSCP "ef" traffic, and I'm getting no packet loss.
The question is, could this be done better? Right now if the station wanted to add another IP Audio Codec, I'd need to adjust the policing on my policy-map. Is there a way to make prioritization more dynamic?
Policy map and interface config on CoreSW01:
class-map match-any AUDIO match ip dscp ef ! policy-map MNT-UPLINK class AUDIO bandwidth 700 police 700000 conform-action transmit exceed-action transmit class class-default bandwidth 715 police 715000 conform-action transmit exceed-action drop ! interface GigabitEthernet2/48 description LAN extender to mountaintop switchport access vlan 200 switchport mode access bandwidth 1415 service-policy output MNT-UPLINK
Show policy-map int output from CoreSW01, taken during a traffic flood test:
CoreSW01#show policy-map interface gigabitEthernet 3/19 GigabitEthernet3/19 Service-policy output: MNT-UPLINK Class-map: AUDIO (match-any) 18027176 packets Match: ip dscp ef (46) 18027176 packets Queueing queue limit 264 packets (queue depth/total drops) 0/196 (bytes output) 3877438140 bandwidth 700 kbps police: cir 700000 bps, bc 21875 bytes conformed 3869345110 bytes; actions: transmit exceeded 0 bytes; actions: transmit conformed 671000 bps, exceeded 0000 bps Class-map: class-default (match-any) 4114839 packets Match: any Queueing queue limit 1848 packets (queue depth/total drops) 0/34 (bytes output) 1074097063 bandwidth 715 kbps police: cir 715000 bps, bc 22343 bytes conformed 987031146 bytes; actions: transmit exceeded 222510411 bytes; actions: drop conformed 227000 bps, exceeded 2000 bps CoreSW01#
... View more