What Ports Are Open On My Router

What Ports Are Open On My Router?

Erick N. Borgard CCNP

Here is a little trick you can use to find out what ports are open on your Cisco router.  You can use the command show control-plane host open-ports command to see what ports your Cisco router is listening on for connections.  This command will also show if there are any connections presently established.

Internet_RTR#show control-plane host open-ports 

Active internet connections (servers and established)

Prot        Local Address      Foreign Address                  Service    State

 tcp                 *:23                  *:0                   Telnet   LISTEN

 tcp                 *:23    10.10.10.31:49664                   Telnet ESTABLIS

 udp                 *:67                  *:0            DHCPD Receive   LISTEN

 udp                 *:68                  *:0             BootP client   LISTEN

 udp                *:123                  *:0                      NTP   LISTEN

The above output shows the router is listening for connections for telnet, DHCP, BootP and NTP.  We can also see that the router has an established telnet connection from a device that sourced a connection from IP address 10.10.10.31 and a source port of 49664.  The connection was established to the router on the standard telnet port 23.  Using this command could help  to harden the router to prevent attacks.

OSPF Graceful Shutdown

OSPF Graceful Shutdown

Erick N. Borgard CCNP

In this blog post, we are going to look at an OSPF feature called graceful shutdown.  Please consider the following diagram.

Presently, R1 is forwarding packets destined for the loopback of R4 towards R5.  All interfaces on all routers are running in OSPF area 0.  Because OSPF uses the formula Reference BW/Interface Bandwidth to calculate the cost of the link, it seem logical that R1 will, in fact, forward packets to R5 to reach the loopback of R4.  We can confirm this by examining the routing table of R1 for prefix 4.4.4.4.

R1#sh ip route 4.4.4.4

Routing entry for 4.4.4.4/32

  Known via "ospf 100", distance 110, metric 21, type intra area

  Last update from 10.0.15.5 on FastEthernet0/0, 00:05:15 ago

  Routing Descriptor Blocks:

  * 10.0.15.5, from 10.0.45.4, 00:05:15 ago, via FastEthernet0/0

      Route metric is 21, traffic share count is 1

The output above confirms that R1 is using R5 as the next hop to reach R4's loopback and is using route recursion to identify the interface to use when forwarding packets to 4.4.4.4.  That's R1's Fa0/0 interface in this case.

Now let's suppose this is the core of the production network and there is an issue with R5. R5 needs to be power cycled or possibly an IOS upgrade needs to be performed for new features or to bring it up to the same IOS level with the other routers in the OSPF routing domain.  If we just simply powered down R5, that would force the adjacent neighbors to wait for the OSPF dead timer to expire.  Furthermore, the OSPF SPF algorithm would need to be run on R1 to recalculate the SPF tree to reach R4s loopback and all of the other networks in the topology to which R5 is connected. What does that mean to us?  It means that there is a strong possibility that there will be dropped packets in the data plane while OSPF is re-converging.  That's not good.  A better option would be to use the OSPF graceful shutdown feature.  We can force R5 to advertise it's router LSAs with an infinite metric of 0xFFFF to it's neighbors.  This will force it's neighbors to use other LSAs in the database to reach networks that R5 is not directly connected to.

Here is the output of the show ip ospf command on R5 before any changes are made.  Some output will be removed for brevity.

R5#sh ip ospf 

 Routing Process "ospf 100" with ID 10.0.45.5

 Start time: 00:14:11.648, Time elapsed: 00:15:00.240

 Supports only single TOS(TOS0) routes

 Supports opaque LSA

 Supports Link-local Signaling (LLS)

 Supports area transit capability

 Router is not originating router-LSAs with maximum metric

    Unset reason: unconfigured

    Unset time: 00:23:00.044, Time elapsed: 00:06:11.844

 Initial SPF schedule delay 5000 msecs

Now we can use the command max-metric router-lsa on R5.  We should see that R1 will load balance the traffic over both of the serial links towards 4.4.4.4 instead of using the fast ethernet link connected to R5.  

R5(config)#router ospf 100

R5(config-router)#max-metric router-lsa

Here is the output of R1s routing table for the 4.0.0.0 prefix.

R1#sh ip route 4.0.0.0

Routing entry for 4.0.0.0/8

  Known via "ospf 100", distance 110, metric 129, type intra area

  Last update from 10.0.12.2 on Serial0/0, 00:02:33 ago

  Routing Descriptor Blocks:

  * 10.0.13.3, from 10.0.45.4, 00:02:33 ago, via Serial0/1

      Route metric is 129, traffic share count is 1

    10.0.12.2, from 10.0.45.4, 00:02:33 ago, via Serial0/0

      Route metric is 129, traffic share count is 1

Our configuration can be further clarified by examining the router LSA for the network 10.0.45.5.  This is the network between R4 & R5. 

R5#sh ip ospf database router 10.0.45.5

            OSPF Router with ID (10.0.45.5) (Process ID 100)

                Router Link States (Area 0)

  Exception Flag: Announcing maximum link costs

  LS age: 404

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 10.0.45.5

  Advertising Router: 10.0.45.5

  LS Seq Number: 80000008

  Checksum: 0xD0FA

  Length: 60

  Number of Links: 3

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.0.45.5

     (Link Data) Router Interface address: 10.0.45.5

      Number of TOS metrics: 0

       TOS 0 Metrics: 65535

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.0.15.5

     (Link Data) Router Interface address: 10.0.15.5

      Number of TOS metrics: 0

       TOS 0 Metrics: 65535

The output above does show that R5 is advertising a metric of 65535 to reach it's connected link.  We can examine the output of the show ip ospf command on R5 again to further verify the configuration.

R5#sh ip ospf

 Routing Process "ospf 100" with ID 10.0.45.5

 Start time: 00:14:11.648, Time elapsed: 00:34:40.828

 Supports only single TOS(TOS0) routes

 Supports opaque LSA

 Supports Link-local Signaling (LLS)

 Supports area transit capability

 Originating router-LSAs with maximum metric

    Condition: always, State: active

 Initial SPF schedule delay 5000 msecs

There are a few other options available to the engineer concerning OSPF graceful shutdown.

1. Override the summary LSA metric
2. Override the external LSA metric
3. Set the infinite metric for stub area link
4. Set the infinite metric after a reboot for a specific amount of time.

Multicast Helper Maps

IP Multicast Helper Maps

Erick N Borgard CCNP

Can you remember back when you were studying for your CCNA? One of the concepts you read or heard from an instructor was that routers do not forward broadcast messages.  While that is true, what you  probably didn't read was engineers can use multicast helper maps to translate that broadcast traffic to a multicast address and route those packets via multicast to another broadcast only network.  This lab will demonstrate the use of ip multicast helper maps to carry RIP broadcast routing information over and ip multicast-enabled IP network.  Please see the diagram for more details.

Setup:

Multicast routing is enabled on R2 & R3

OSPF is enabled between R2 & R3

RIPv2 is enabled on R1 & R4 with the loopback and fa0/0 interfaces participating in the protocol

RIPv2 is configured to send version 2 updates as broadcasts on R1 & R4

Note: It should not be implied that RIP is or needs to operate and provide connectivity.  This lab is only to show how broadcast packets destined for UDP port 520 can be translated, routed via multicast, and translated again on another broadcast only network.  RIP is the tool being used in this example because it's easy to see it work with RIP, but the engineer can use whatever port he/she wants to use or use the one outlined in your task and use the response time reporter to test.

Steps to configure multicast helper maps are:

• Configure an ACL to identify the traffic the multicast helper map will use on first and last hop routers
• Configure the routers to forward broadcast traffic destined for specified port number
• Configure the first-hop router to translate broadcast packets to a multicast address
• Configure the last hop router to translate received multicast traffic to the IP directed broadcast address of the link on which traffic needs to be forwarded
• Configure the router to forward directed broadcast on the interface on which the broadcast needs to be forwarded

One thing that tends to confuse people is on which interface the ip multicast helper-map command should be applied.  The ip multicast helper-map command should be applied to upstream facing interfaces. Or more specific, the commandis applied to interfaces facing towards the source of the broadcast traffic that needs to be translated.  In this example, R1 is sending the traffic to be translated to multicast.  So on the first hop router (R2), the command is applied to the LAN interface(fa0/0).  On the last hop router, the command is applied to the S0/0 interface. The best way to remember this is to think about it from the perspective of the router and the direction in which traffic is flowing.  Just keep in mind while looking at this lab that the commands are applied to interfaces pointing towards R1.

In this example, R1 is sending updates as broadcast.  R2 will rewrite the destination address of the packet to the configured multicastaddress 229.0.0.1.  R2 will route that traffic via PIM to R3.  When R3 receives that packet, it will rewrite the destination address ofthe IP packet to the directed broadcast address configured in the multicast helper-map command.  It will then use the ip directed-broadcast command to forward that traffic onto the destination link.

Here are the relevant configurations.

R1

router rip

 version 2

 network 1.0.0.0

 network 10.0.0.0

 no auto-summary

interface FastEthernet0/0

 ip address 10.1.12.1 255.255.255.0

 ip rip v2-broadcast

R2

ip forward-protocol udp rip

access-list 101 permit udp any any eq rip

interface FastEthernet0/0

 ip address 10.1.12.2 255.255.255.0

 ip pim dense-mode

 ip multicast helper-map broadcast 229.0.0.1 101 ttl 5

R3

                                                                                                                                                   

ip forward-protocol udp rip

access-list 101 permit udp any any eq rip

interface Serial0/0

 ip address 10.1.23.2 255.255.255.252

 ip pim dense-mode

 ip multicast helper-map 229.0.0.1 10.1.34.255 101

 ip igmp join-group 229.0.0.1

interface FastEthernet0/0

 ip address 10.1.34.3 255.255.255.0

 ip directed-broadcast

R4

router rip

 version 2

 no validate-update-source

 network 4.0.0.0

 network 10.0.0.0

 no auto-summary

There is one other thing that needs to be addressed.  By default, RIP will perform a sanity check on the source address of the RIP update to ensure that it is part of it's directly connected interfaces.   The packet originated on the 10.1.12.x subnet.  When R4 performs the sanity check, it will not accept/install the route into the routing table.  Note that the above configuration disables these sanity checks with the no validate-update-source command under the RIP routing process.  Once this command is entered, R4 will accept and install the route learned from R1 into the IP routing table.

R4#sh ip route | beg Gate

Gatewayof last resort is not set

     1.0.0.0/32is subnetted, 1 subnets

R       1.1.1.1 [120/1]via 10.1.12.1, 00:00:15

     4.0.0.0/32is subnetted, 1 subnets

C      4.4.4.4 is directly connected, Loopback4

     10.0.0.0/24is subnetted, 1 subnets

C      10.1.34.0 is directly connected, FastEthernet0/0

Here we see that R4 did receive the RIP route from R1 as expected. Obviously we will not have IP connectivity because the nexthop(10.1.12.1) is not reachable from R4.  RIP was only used to show how broadcast traffic is handled with the ip multicasthelper-map command.