Unconditional trunking port on a Catalyst 3560

Rob van Ooijen has sent me a really interesting question:

I've configured a switch port to be unconditionally a trunk with the switchport mode trunk configuration command. However, when the interface was enabled, I've got a dynamic trap indicating the trunking was still dynamic (and the show commands also showed negotiation of trunking is enabled).

In fact, adjacent layer-2 devices can negotiate a number of things these days, among them:

read more add comment

Reduce IP addressing errors in lab environment

One of the most tedious tasks in the initial lab setup (at least for me) is the IP address configuration, which usually includes a number of typos and mixups on the WAN links. You can simplify then WAN address configuration if you configure only one end of the WAN link and let PPP do the rest. For example, you could use the following configuration to configure WAN link on your core router …

read more see 1 comments

Time-based BGP policy routing

Petr Lapukhov describes an interesting scenarion in his post BGP Time-Based Policy Routing: a multi-homed customer that uses one upstream link (for example, more reliable but slower one) during the work hours, switching to the other upstream link (faster, less reliable) after that.

He uses BGP communities to achieve the switch (perfect solution if your ISP supports them) and time-based ACL in a route-map to set the community based on time-of-day. As Cisco changed the way BGP imports local routes in IOS release 12.3T, he then devises an ingenious solution based on reliable static routing to trigger a change in the IP routing table.

The optimum solution is way simpler: you just configure two EEM applets to perform clear ip route network command at appropriate times.

read more see 2 comments

Use all the tools you have

BGP implementation on Cisco IOS gives you a number of filtering options, including prefix filters, AS path filters and route maps. While it might be tempting to learn just the most versatile tool available (route maps) and discard all the others, judicious use of all available tools can simplify your router configurations.

For example, an Internet Service Provider might want to filter incoming updates received from the customers to ensure they’re not advertising transit routes and advertise only IP prefixes they actually own. Inbound route maps might also be needed to attach BGP communities to inbound routes or set BGP attributes (for example, local preference) based on communities attached to incoming routing updates.

read more see 2 comments

Differentiating between port scanners and legitimate users

One of my readers asked a very interesting question:

“Is there a way to have a port on a router open for legitimate use while closed to port scanning software and the such. For example. I have SSL VPN configured on my IOS router. Is it possible to have the port seem stealthed to port scanners while still allowing legitimate access to the service? An example being, allowing a web browser to connect using the port but making sure that a port scanner doesn't detect it as open.”

The short answer is no, unless you can differentiate legitimate users by their IP addresses. The port scanners (when using SYN scan) simply open and close a TCP session, and there is no way for a router to differentiate between the legitimate users (who would send valid HTTP GET requests) and port scanners (that would close the session as soon as it's established).

read more add comment

Remove unwanted PPP peer route

When IOS started supporting dynamic allocation of IPCP (IP over PPP) addresses, it also got the mechanism to insert a dynamic host route toward the neighbor's IP address once the IP addresses were negotiated. This mechanism makes perfect sense in dynamic address allocation environments, as the subnet mask is not negotiated with IPCP. Without a host route toward the other end of the PPP link, there would be no easy way to reach the IP prefixes reachable via the PPP link.

read more see 1 comments

Common Sense Prevails Over RFC 2328

When trying to extract the OSPF route selection rules from RFC 2328, I've stumbled across a very weird rule (section 16.4.1): if an ASBR within a non-backbone area advertises an external route (or if the forwarding address is within the non-backbone area), it's preferred over external routes advertised by ASBRs in other areas regardless of its metric. I simply had to test this on Cisco IOS … and found out that Cisco engineers prefer common sense to OSPF RFC.

read more see 11 comments
Sidebar