Getting better answers from Iris config analysis
Iris’s config analysis is the quickest way to understand an unfamiliar config: open it in rConfig, ask, and get an answer in plain language. How you ask makes a large difference to what you get back. This page explains what Iris actually reads and how to use that.
What Iris reads
When you start a conversation, rConfig gives the model:
- The config itself. Whole up to about 100,000 characters; larger configs are reduced to their most relevant sections (interfaces, routing, ACLs and similar).
- A short profile of the config that rConfig works out: line count, likely device type, and whether it contains interfaces, routing, VLANs, ACLs, BGP or OSPF.
- Instructions to reference exact lines, explain impact, and put commands in code blocks.
Follow-up messages send only your new question; the model keeps the config from the first message. Secrets are obfuscated before anything leaves rConfig.
Choose the right entry point
| You want | Use | Why |
|---|---|---|
| To understand the whole device, or a conversation | Ask AI | Full config, full-length answers, follow-ups |
| One standard action on a block | Lightbulb (explain, find issues, improve, security) | One click, and the full config is still there for context |
| A quick answer next to the lines | Inline prompt (Ctrl/Cmd+K) | Short answers, two or three paragraphs, in the editor |
The lightbulb’s security analysis on an ACL is a good example of context at work: the answer can tell you which interface the ACL is applied to, from elsewhere in the file.
Questions that work
| Instead of | Ask |
|---|---|
| “Check BGP” | “Is the BGP session to 192.0.2.1 authenticated, and what does it filter on import?” |
| “Is this secure?” | “List management-plane exposures in this config: which services listen, on which interfaces, with what access control. Quote the lines.” |
| “Explain this” | “Explain this config for an engineer who knows Cisco but not Juniper, section by section, in under 300 words.” |
| “Any problems?” | “Find interfaces that are up with no description, and trunks that allow all VLANs. Table: interface, issue, line.” |
Three habits make answers checkable:
- Ask for evidence. “Quote the lines that support that” makes mistakes visible.
- Ask for a format. A table or a fixed list is easier to verify than prose.
- One topic per conversation. Start a new chat when you change subject; long mixed chats dilute the context.
When answers are weak
- Shallow or generic answers on long configs: select the relevant block, or move to a more capable model. On self-hosted models, check the context window: see Sizing a local model.
- Answer cut off: the model hit its output cap. Ask for a shorter format, or raise Max Output Tokens (config analysis is capped at 4,096 tokens either way).
- Answer about an old version: if the config changed since the chat began, rConfig shows a warning. Start a fresh conversation.
Related reference
Frequently asked questions
Does Iris read the whole config when I ask about selected lines?
From the lightbulb menu and Ask AI, yes: the selected lines are the focus, and the full config is there for context. The inline prompt includes the full config only if it's under 50,000 characters.
Why does Iris give a vague answer about a large config?
Configs over about 100,000 characters are trimmed to their most relevant sections, and small models struggle with long input. Select the block you care about, ask a specific question, or use a more capable model.
Does Iris remember earlier conversations?
Conversations are saved per user and per config. Reopening Ask AI on the same config resumes the latest one. Start a new chat when you change topic.