Tag Archive - IOS

Toll-Fraud Prevention in IOS 15.x

Toll-fraud prevention…

I’ve seen this new IOS 15.x feature rear its “ugly head” in recent deployments.  Most often, an engineer will take a working configuration example from a router running IOS 12.x and apply it to new 2900/3900 hardware.  When that occurs, this handy little toll-fraud app will kick into high gear.

Read the following snippets from one of Cisco’s tech notes.

A new feature has been introduced in Cisco IOS® Software Release 15.1(2)T to guard against the incidence of toll-fraud on Voice GateWays (VGWs) installed with Cisco IOS. Starting with IOS 15.1(2)T and newer releases of IOS based on this version, the toll-fraud prevention settings are the default behavior of Cisco IOS-based VGWs.

For all IOS releases before 15.1(2)T, the default behavior for IOS voice gateways is to accept call setups from all sources. As long as voice services are running on the router, the default configuration will treat a call setup from any source IP address as a legitimate and trusted source to set a call up for. Also, FXO ports and inbound calls on ISDN circuits will present secondary-dial tone for inbound calls, allowing for two-stage dialing. This assumes a proper inbound dial-peer is being matched.

Starting with 15.1(2)T, the router’s default behavior is to not trust a call setup from a VoIP source. This feature adds an internal application named TOLLFRAUD_APP to the default call control stack, which checks the source IP of the call setup before routing the call. If the source IP does not match an explicit entry in the configuration as a trusted VoIP source, the call is rejected.

Continue Reading…

IOS Shell in IOS 15.1(4)M

JOY!  Cisco IOS now supports a shell environment!

IOS 15.1(4)M and later releases contains a feature called IOS.Sh that, when enabled, provides a user with a shell environment.  Here’s what Cisco says:

The IOS.sh is designed to be familiar to users. This is done by implementing a control language that is similar in many ways to various open source CLI interfaces. A system administrator with a UNIX background can easily understand and use the new IOS.sh features, and an experienced Cisco IOS CLI user can easily learn and use these features as enhancements. IOS.sh is also mostly backward compatible with the existing Cisco IOS CLI, with a few obvious exceptions. This means that CLI commands that are entered on the router will probably continue to work as before. However, users should be aware that some commands may need to be invoked differently if users want to take advantage of the IOS.sh.

Once IOS.Sh is enabled, you have some powerful abilities:

  • Defining and using environment variables
  • Using control constructs to automate repetitive tasks
  • Creating and using IOS.sh functions
  • Using a new set of ‘built-in’ function, that provide various text processing facilities.
  • Using extended pipelines to use the output of one command as input for another one.
  • Evaluating logical and arithmetic expressions for tests and variable setting.
  • Using online ‘manual’ pages describing these changes.

Here’s my question: How do you see this changing the way we work as engineers?  Thoughts?

Source: http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_ios_shell.html#wp1054158

Forwarding Range of Ports in Cisco IOS

One question that routinely comes up in a particular forum that I frequent is “How do I port forward a range of ports?”  Usually, this question is met with one of two answers:  1) you don’t, or 2) manually enter 10000 “ip nat …” statements.

The correct answer is actually number three.  It turns out that it is, indeed, possible to forward a range of ports in IOS.

One question that routinely comes up in a particular forum that I frequent is “How do I port forward a range of ports?”  Usually, this question is met with one of two answers:  1) you don’t, or 2) manually enter 10000 “ip nat …” statements.

The correct answer is actually number three.  It turns out that it is, indeed, possible to forward a range of ports in IOS.

First, set up your basic NAT configuration (“ip nat inside”, “ip nat outside”, etc.).Next, let’s create an IP NAT pool, for a single IP address (the IP address of the internal host, 192.168.0.50):

R6(config)# ip nat pool PORTFWD 192.168.0.50 192.168.0.50 netmask 255.255.255.0 type rotary

Then, create an access list (ACL) matching the ports you want forwarded. In the case of 10000-20000/UDP for VoIP, we can use the “range” keyword to simplify things for us tremendously:

R6(config)# access-list 100 permit udp any any range 10000 20000

Last, we’ll tie our access-list 100 to the PORTFWD NAT pool that we created:

R6(config)# ip nat inside destination list 100 pool PORTFWD

Now, any UDP traffic coming into our router’s public interface (FastEthernet 0/0) with a destination port between 10000 and 20000 will be forwarded to the host at 192.168.0.50. I was able to verify this by generating UDP traffic on my MacBook and having the router forward it to another laptop with a tcpdump capture up and running — it worked wonderfully. I was running 12.4(10a) on a 2621XM. Try it out and let me know if it works for you as well!

Source: Evil Routers

How it all Stacks Up

Today I was on-site in Hattiesburg, MS for a network cutover in preparation for a Cisco VoIP rollout. As part of the prep work, we replaced the customers’ failing 3COM/HP switches with a shiny new 3750 switch stack.

As I was going through the switch stack setup process I thought to myself that it’d be a good idea to have a quick reference post on switch stack setup. While I’m no R&S CCIE, I’ve learned a thing or two about stacking,

Initial Setup

  • Starting out with a console cable, connect to the switch you’ll designate as master.  Build a configuration that will apply to the entire switch stack.  If you have any “slave” switches that will be added, make sure to “write erase” and delete the VLAN information stored in “vlan.dat.”
  • Provision your switch as master using the following command: “switch 1 provision [switch-type].”  Repeat this for every switch.
  • Set the master switch priority highest using the “switch 1 priority 15” command in global configuration mode.
  • If you have switches that are numbered incorrectly, use the “switch 1 renumber [number]” command.  This is especially useful if you’re a bit obsessive like me and want to make sure the switch numbers match exactly with their racking order.
  • Connect the Cisco StackWise cables diagonally from Switch 1 to Switch 2, from Switch 2 to Switch 3, etc. Then, cable the top-most switch to the bottom master switch (if starting from bottom).
  • Verify that provisioning was successful using the command “show switch detail.”

That’s all for now. I’m exhausted and need to get some shut-eye.