Epicep 21H Technology Site

Posts Tagged ‘tutorial’

While routers accept and generate broadcasts, they do not forward them. This can be quite a problem when a broadcast needs to get to a device such as a DHCP or TFTP server that’s on one side of a router with other subnets on the other side.

If a PC attempts to locate a DNS server with a broadcast, the broadcast will be stopped by the router and will never get to the DNS server. By configuring the ip helper-address command on the router, UDP broadcasts such as this will be translated into a unicast by the router, making the communication possible. The command should be configured on the interface that will be receiving the broadcasts.

R1(config)#int e0

R1(config-if)#ip helper-address ?

A.B.C.D IP destination address

R1(config-if)#ip helper-address 100.1.1.2

Now, you may be wondering if this command covers all UDP services. Sorry, you’re not getting off that easy! The command does forward eight common UDP service broadcasts, though.

TIME, port 37

TACACS, port 49

DNS, port 53

BOOTP/DHCP Server, port 67

BOOTP/DHCP Client, port 68

TFTP, port 69

NetBIOS name service, port 137

NetBIOS datagram service, port 138

That’s going to cover most scenarios where the ip helper-address command will be useful, but what about those situations where the broadcast you need forwarded is not on this list? You can use the ip forward-protocol command to add any UDP port number to the list.

Additionally, to remove protocols from the default list, use the no ip forward-protocol command. In the following example, we’ll add the Network Time Protocol port to the forwarding list while removing the NetBIOS ports. Remember, you can use IOS Help to get a list of commonly filtered ports!

R1(config)#ip forward-protocol udp ?

Port number

biff Biff (mail notification, comsat, 512)

bootpc Bootstrap Protocol (BOOTP) client (68)

bootps Bootstrap Protocol (BOOTP) server (67)

discard Discard (9)

dnsix DNSIX security protocol auditing (195)

domain Domain Name Service (DNS, 53)

echo Echo (7)

isakmp Internet Security Association and Key Management Protocol (500)

mobile-ip Mobile IP registration (434)

nameserver IEN116 name service (obsolete, 42)

netbios-dgm NetBios datagram service (138)

netbios-ns NetBios name service (137)

netbios-ss NetBios session service (139)

ntp Network Time Protocol (123)

pim-auto-rp PIM Auto-RP (496)

rip Routing Information Protocol (router, in.routed, 520)

snmp Simple Network Management Protocol (161)

snmptrap SNMP Traps (162)

sunrpc Sun Remote Procedure Call (111)

syslog System Logger (514)

tacacs TAC Access Control System (49)

talk Talk (517)

tftp Trivial File Transfer Protocol (69)
Read the rest of this entry »

Multicasting is a vital topic on your BCMSN, CCNP, and CCIE exams, and it can also be very confusing when you first start studying it. Multicasting uses concepts that are unlike anything you’ve run into in your routing protocol studies, and that can throw you at first. I speak from experience that multicasting is like any other Cisco technology – learn the basics, master the fundamentals, and then build your skills on that foundation.

One such fundamental is the RPF Check, or Reverse Path Forwarding Check.

A fundamental difference between unicasting and multicasting is that a unicast is routed by sending it toward the destination, while a multicast is routed by sending it away from its source.

“toward the destination” and “away from its source” sound like the same thing, but they’re not. A unicast is going to follow a single path from source to destination. The only factor the routers care about is the destination IP address – the source IP address isn’t a factor.
Read the rest of this entry »

When you’re studying to pass the BCMSN exam on the way to earning your CCNP certification, you’re going to add to your CCNA knowledgebase every step of the way. Nowhere is that more than configuring a trunk between two switches.

You know that IEEE 802.1Q (“dot1q”) and ISL are your two choices of trunking protocols, and you know the main differences between the two. What you might not have known is that there’s a third trunking protocol that’s running between your Cisco switches, and while it’s a transparent process to many, you had better know about it for your BCMSN and other CCNP exams!

The Cisco-proprietary Dynamic Trunking Protocol (DTP) actively attempts to negotiate a trunk link with the remote switch. This sounds great, but there is a cost in overhead – DTP frames are transmitted every 30 seconds. If you decide to configure a port as a non-negotiable trunk port, there’s no need for the port to send DTP frames.

DTP can be turned off at the interface level with the switchport nonegotiate command, but as you see below, you cannot turn DTP off until the port is no longer in dynamic desirable trunking mode. (Dynamic desirable is the default mode for most Cisco switch ports.)
Read the rest of this entry »

In this CCNA case study, we’ll take some basic switching and trunking theory and put it into action. We have two routers (R2 and R3) along with two switches (SW1 and SW2). R2 is connected to SW1 at fast 0/2, and R3 is connected to SW2 at fast 0/3. Both routers have IP addresses on the 172.12.23.0 /24 network.

For these routers to be able to ping each other, the switches must be able to communicate. These are two 2950 switches, and they’re connected via two crossover cables. Before we worry about the router connectivity, let’s make sure the trunk link is up between the switches with the “show interface trunk” command.

SW2#show interface trunk

Port Mode Encapsulation Status Native vlan

Fa0/11 desirable 802.1q trunking 1

Fa0/12 desirable 802.1q trunking 1

< output truncated for clarity >

The default mode of these switches is for the ports to run in dynamic desirable trunking mode, so we didn’t even need to write a configuration to have the trunk form – it’s already there!

Show vlan brief reinforces the theory that by default, all switch ports are placed into VLAN 1 (except the trunk ports).

R2 and R3’s Ethernet addresses have already been configured, the trunk line is operational, and both ports are in VLAN 1. We’ll ping R2’s Ethernet interface from R3, and then R3’s Ethernet interface from R2 to verify IP connectivity.

R2#ping 172.23.23.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.23.23.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

R3#ping 172.23.23.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.23.23.2, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

With pings, exclamation points indicate IP connectivity, and periods indicate no connectivity.

So we’ve got connectivity! Now let’s see if we still have that connectivity when the ports are placed into different VLANs. Cisco CCNA theory states that devices in different VLANs can’t communicate without the intervention of a Layer 3 device, but let’s see if that’s true by placing R2 into VLAN 23. (VTP is already running on these switches.)
Read the rest of this entry »