Ethan Banks On productivity.

GroupStudy.com CCIE-LAB List – Best of 1/15/2008 – Prefix Lists + PAgP “non-silent” + OSPF Flood Wars + Duplicate EIGRP RIDs

G

Gleanings from the GroupStudy.com CCIE-LAB mailing list over the last few days…

  • An interesting practice page for prefix-lists.
  • Although nothing definitive was unearthed, there was some talk about what the PAgP keyword “non-silent” accomplishes. Related links on this topic follow.
    • http://www.groupstudy.com/archives/ccielab/200311/msg00633.html
    • http://www.groupstudy.com/archives/ccielab/200306/msg01526.html
    • http://www.groupstudy.com/archives/ccielab/200403/msg01452.html
    • Finally, I read this in the Doc CD about 5 times before it made sense. It’s worded a little awkwardly. It almost makes it sound like you should use “non-silent” for interswitch links – which I’ve never done. It’s a rabbit trail to go down at some point, although I don’t think it’s a critical feature to understand when it comes to passing the lab. Still interesting.

      If your switch is connected to a partner that is PAgP-capable, you can configure the switch port for nonsilent operation by using the non-silent keyword. If you do not specify non-silent with the auto or desirable mode, silent mode is assumed.

      Use the silent mode when the switch is connected to a device that is not PAgP-capable and seldom, if ever, sends packets. An example of a silent partner is a file server or a packet analyzer that is not generating traffic. In this case, running PAgP on a physical port connected to a silent partner prevents that switch port from ever becoming operational. However, the silent setting allows PAgP to operate, to attach the port to a channel group, and to use the port for transmission.

  • I’d been meaning to play with prefix-lists to find the best way to replicate a “permit any” ACE. That appears to be “ip prefix-list name seq 10 permit 0.0.0.0/0 le 32“, and that makes sense. I had been using “ip prefix-list name seq 10 permit 0.0.0.0/0 ge 1” which I knew wasn’t right, but for whatever reason I hadn’t yet taken the cycles needed to figure it out.
  • An OSPF “flood war” (about which I can find nothing on cisco.com, and almost nothing via Google) probably indicates that you have a duplicate router ID in the OSPF domain. You may see errors starting with “%OSPF-4-FLOOD_WAR” describing an LSA being flushed and then reoriginated.
  • Duplicate router IDs in the EIGRP domain can cause external routes to be rejected by the router with the duplicated RID. Read more about this here.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

2 comments

  • Another reason for the OSPF flood-war that I just ran into (IE Vol2, lab 16) is simple Cisco funkyness. R4 and R5 have an ethernet connection to each other. They are also hubs to R3 in a FR hub and spoke triangle. OSPF is everywhere, same area.

    R5 kept getting this flood-war message. After having wasted hours troubleshooting weird crap like this, only to have it resolved via a reboot, that’s exactly what I did right up front. It fixed it.

  • I should add that there was never a duplicate router-id, or even a duplicate IP, anywhere. I verified this, and changed nothing before rebooting.

Ethan Banks On productivity.

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.