Build the LLDP-MED Location Identification TLV (TIA-1057, RFC 4776 civic address format) for E911 dispatchable-location compliance. Type the address, get encoded bytes plus ready-to-paste Cisco IOS, Aruba / HPE, and DHCP option 99 / 144 configurations.
Everything runs in your browser. The address you enter is never sent to any server.
49 common VoIP-deployment countries. LLDP-MED itself accepts any ISO 3166-1 alpha-2 code — if your country isn't here, the encoder logic accepts any two-letter code (the dropdown is a convenience, not a hard limit).
Optional. Leave blank to omit the CA-Type 0 element.
—
Same civic address, three places it commonly lands: Cisco IOS
location civic-location block, Aruba / HPE ArubaOS-Switch
(AOS-S), and the raw civic-address bytes for DHCP option 99 (RFC 4776)
/ option 144. Reference the location ID from the LLDP-MED-emitting
interface or DHCP pool as appropriate.
Paste under configure terminal. Reference from the
access port with location civic-location-id 1.
Identifier number is arbitrary — increment per unique address.
Cisco sets WHAT = 1 (network element) automatically —
the WHAT radio above does not affect this block.
Civic address advertised via LLDP-MED on the specified ports. Adjust the port list to match the access layer. AOS-S sets WHAT = 1 (network element) automatically — the WHAT radio above does not affect this block.
The civic-address payload without the LLDP-MED TLV wrapper. Option 99 (RFC 4776) is the standard; option 144 is the Cisco phone-specific variant carrying the same encoding. ISC dhcpd and Microsoft DHCP both accept the hex string directly.
Civic is a postal address (this tool, LLDP-MED format 2, DHCP option 99 / 144). Geographic is latitude / longitude (LLDP-MED format 1, DHCP option 123, RFC 6225). For dispatchable location under RAY BAUM's Act §506, civic is what PSAPs consume — coordinates alone don't tell a first responder which floor or room.
"Sufficient to identify the location of the caller" — in practice that's street address + at least one of: floor, room, suite, or unit. A single address for a 30-story building doesn't satisfy the rule; the PSAP needs to know which floor / which suite.
LLDP-MED is best when the switch knows where each port lives (data-center cabling, structured-cabling office floors) — the location moves with the port. DHCP options 99 / 144 are best when the location is per-scope (per-VLAN or per-subnet) and the endpoint speaks DHCP but not LLDP-MED. Many deployments use both as belt-and-suspenders.
"Additional location info" is for context like "South entrance, near elevators" — useful for first responders once they have an address, but not a replacement for a building / floor / room field. If you find yourself cramming the whole location into CA-Type 22, you've lost the machine-parseable benefit.
WHAT = 2 (client) says the endpoint asserted this location itself — phones don't usually originate civic info, so this is unusual in LLDP-MED. WHAT = 1 (network element) says the switch / AP is asserting it on behalf of the port — the typical case. WHAT = 0 (DHCP server) is used inside DHCP option 99 to indicate the DHCP server authoritatively sourced the value. PSAP routing may treat these differently.
Each CA element value is one octet of length followed by the value — so the value is capped at 255 bytes (often less after UTF-8 expansion). This builder silently drops anything longer; in real configs you'll get a parser error from the switch instead.
RFC 4776 lets CA elements appear in any order; receivers parse them by CA-Type number. This builder emits them in geographic-hierarchy order (country → state → city → street → building → room) so the hex dump reads naturally, but a switch reordering them is still RFC-conformant.
Wireshark dissects all this — filter
lldp.tlv.type == 127 and look for the TIA-1057
Location ID subtype. This tool is for the case where you're
configuring before there's a phone to capture from, or
you're hand-verifying that what the switch encodes matches
what you intended.