Continued from the previous post…
- “no service dhcp” will disable the DHCP server and relay functions of an IOS device.
- IOS devices do not, by default, track to see whether the other end of a TCP connection still thinks the socket is up. That makes IOS ripe for a DoS attack, where the attacker would try to eat up router resources by orphaning TCP connections and adding new ones (more likely to succeed than a SYN flood). To mitigate this IOS default behavior, enable TCP keepalives with “service tcp-keepalives-in” and “service tcp-keepalives-out“.
- Don’t forget that an IOS device has HTTP & HTTPS servers sitting there listening. You may be instructed to shut them down, which you can do with “no ip http server” or “no ip http secure-server“. Note that there is no “ip https server” command.
- When configuring BGP, a common issue is how to deal with the next-hop well-known mandatory attribute. What’s in the next-hop field? Can the router you’re advertising to reach that next-hop? Is the next-hop directly connected, or only reachable via a recursive lookup? If only reachable recursively, does the intermediate-hop router know how to forward the traffic? (Remember that you can have BGP neighbor adjacencies form across several hops that know nothing of BGP.) If the intermediate-hop router is a blackhole, how will you solve this problem? Will you use “next-hop-self” to change the BGP advertisement? Will you build a tunnel through the intermediate router? Is there enough flexibility in the BGP task list that you should perhaps consider a redesign of your BGP peers? Do you need to advertise specific routes in the IGP underlying your BGP design so that recursive forwarding gets the packet where it needs to go?
- When instructed to limit traffic to only specific protocols, say telnet and ICMP, you need to also consider whether applying that ACL would break an IGP link. Never break a routing protocol by applying an ACL. Make sure that your ACL has ACEs that will allow the IGP to continue functioning.
- The Cisco 3550 allows you to apply a port ACL – essentially a layer 3 ACL on a layer 2 port, physical ports only supported (sorry, etherchannel). That’s a handy feature to be aware of, as it’s powerful and easy-to-use, but could really stymie you if you didn’t know it was available.
- When configuring multicast, a “shared root” implies a rendezvous point. Rendezvous points are the multicast routers that will forward multicast streams to sparse-mode PIM routers that request to join into the shared tree. As the sparse-mode routers become aware of the multicast source, they will leave the shared tree and move to the source tree. Again, when you think “shared root”, think “rendezvous point” and “sparse mode” PIM (possibly sparse-dense mode, depending on scenario restrictions). Then you must decide what method you’ll use to let your multicast routers know who the rendezvous point is for certain multicast groups: static, Auto-RP, or BSR. If you know what’s unique about each of these, then the scenario should clue you into which is the appropriate way to configure the rendezvous point.
- Remember that when configure IP SLA for measurements such as UDP jitter, NTP is a important component (see the “Prerequisites” section). The 2 routers that are participating in the SLA measurement have to have very, very close times to accurately perform the measurements.