Configuration of a drop-in bridged CISCO Router / Firewall

Overview

Often, you have a given network layout which cannot be changed. For example, you own only a few routable IP-Addresses and therefore must use the same Network-ID for the DMZ (Demilitarized Zone) and your Internet connection. Some modern Firewalls / Routers allows to "drop-in" in such a network configuration. That means, no network changes have to be made and only one IP-Address is used for the router / firewall. If you use a Cisco Router, this can be difficult, because usually each interface on a Cisco Router must have one IP-Address assigned to it. But there is a trick - so called bridging - using this feature you can overcome these difficulties.

The following features can be used with Cisco's IOS and an 2621 Router

Integrated Bridging (IRB)
Context Based Access Control (CBAC)
Network Address Translation (NAT)
Access Lists (ACL)
ICMP Redirects

Integrated Bridging between Internet and DMZ

The main features of this configuration is, that we can use the same network (194.246.125.192/28) for the Internet and the DMZ. No routing is necessary between the DMZ and Internet, only one IP-Address is used for the Firewall.

The following figure shows the configuration of the Cisco 2621 firewall. The firewall is setup with three interfaces for the External, Optional and Trusted Interface.

External Interface: Ethernet1/0 (Internet)
Optional Interface: FastEthernet0/0 (DMZ)
Trusted Interface: FastEthernet0/1 (HSZ)

The external and optional Interface are bridged. For the trusted interface an access-list for IN (102) and OUT (103) is setup and maintained. For the bridged intrerface only the IN (150) access-list is setup.

To configure a router interface in the Cisco IOS software, use the following commands, starting in global configuration mode.

interface FastEthernet0/0
description DMZ
no ip address
duplex auto
speed auto
bridge-group 32
!
interface Ethernet1/0
description Internet
no ip address
bridge-group 32
!

After you have set up the interfaces in the router, you can enable integrated routing and bridging. To enable integrated routing and bridging in the Cisco IOS software, use the following command in global configuration mode.

bridge irb

Use the show interfaces irb privileged EXEC command to display the protocols that a given bridged interface can route to the other routed interface when the packet is routable, and to display the protocols that a given bridged interface bridges.

show interfaces irb

FastEthernet0/0 DMZ
Routed protocols on FastEthernet0/0:
ip
Bridged protocols on FastEthernet0/0:
ip
Software MAC address filter on FastEthernet0/0
Hash Len    Address      Matches Act      Type
0x00: 0 ffff.ffff.ffff     43016 RCV Physical broadcast
0x2A: 0 0900.2b01.0001         0 RCV DEC spanning tree
0xB9: 0 0002.b91d.2700   2115670 RCV Interface MAC address
0xB9: 1 0002.b91d.2700         0 RCV Bridge-group Virtual Inter
0xC0: 0 0100.0ccc.cccc         0 RCV CDP
0xC2: 0 0180.c200.0000         0 RCV IEEE spanning tree
0xC2: 1 0180.c200.0000         0 RCV IBM spanning tree
0xC2: 2 0100.0ccd.cdce         0 RCV VLAN Bridge STP
FastEthernet0/1 HSZ
Routed protocols on FastEthernet0/1:
ip
Ethernet1/0 Internet
Routed protocols on Ethernet1/0:
ip
Bridged protocols on Ethernet1/0:
ip
Software MAC address filter on Ethernet1/0
Hash Len    Address      Matches Act      Type
0x00: 0 ffff.ffff.ffff      9669 RCV Physical broadcast
0x2A: 0 0900.2b01.0001         0 RCV DEC spanning tree
0xA9: 0 0002.b91d.2710         0 RCV Interface MAC address
0xB9: 0 0002.b91d.2700   1916977 RCV Bridge-group Virtual Inter
0xC0: 0 0100.0ccc.cccc         0 RCV CDP
0xC2: 0 0180.c200.0000         0 RCV IEEE spanning tree
0xC2: 1 0180.c200.0000         0 RCV IBM spanning tree
0xC2: 2 0100.0ccd.cdce         0 RCV VLAN Bridge STP
BVI32
Routed protocols on BVI32:
ip

The bridge-group virtual interface resides in the router. It acts like a normal routed interface that does not support bridging, but represents the entire corresponding bridge group to routed interfaces within the router. The bridge-group virtual interface is assigned the number of the bridge group that it represents. The bridge-group virtual interface number is the link between the bridge-group virtual interface and its bridge group. Because the bridge-group virtual interface is a virtual routed interface, it has all the network layer attributes, such as a network address and the ability to perform filtering. Only one bridge-group virtual interface is supported for each bridge group.

When you enable routing for a given protocol on the bridge-group virtual interface, packets coming from a routed interface but destined for a host in a bridged domain are routed to the bridge-group virtual interface, and are forwarded to the corresponding bridged interface. All traffic routed to the bridge-group virtual interface is forwarded to the corresponding bridge group as bridged traffic. All routable traffic received on a bridged interface is routed to other routed interfaces as if it is coming directly from the bridge-group virtual interface.

To create a bridge-group virtual interface, use the following command in interface configuration mode:

interface BVI32
ip address 194.246.125.195 255.255.255.240
ip access-group 150 in
no ip redirects
ip nat outside
ip inspect Ethernet_BVI in

When you intend to bridge and route a given protocol in the same bridge group, you must configure the network-layer attributes of the protocol on the bridge-group virtual interface. Do not configure protocol attributes on the bridged interfaces. No bridging attributes can be configured on the bridge-group virtual interface.

When integrated routing and bridging is enabled, the default route/bridge behavior in a bridge group is to bridge all packets.

You could then explicitly configure the bridge group to route a particular protocol, so that routable packets of this protocol are routed, while nonroutable packets of this protocol or packets for protocols for which the bridge group is not explicitly configured to route will be bridged.

You could also explicitly configure the bridge group so that it does not bridge a particular protocol, so that routable packets of this protocol are routed when the bridge is explicitly configured to route this protocol, and nonroutable packets are dropped because bridging is disabled for this protocol.

Specify a protocol to be routed in a bridge group use the following command:

bridge 32 route ip

Context Based Access Control

Context Based Access Control (CBAC) is able to manage multichannel applications such as FTP, CU-SeeMe, H.323, etc. Multichannel applications are those that use one connection for the commands that are sent between the client and server and another, possibly multiple, connections for the data sent between the client and server. Often, the connection for the data channel may be initiated from the server to the client. Without understanding the behaviour of these applications, the router would not know whether these data channels from the server to the client should be permitted or denied access.

The process CBAC follows to monitor outbound traffic sessions and create appropriate inbound access-list entries as follows:

An outgoing packet reaches a router interface. The packet is evaluated against an access list applied to the interface. The access list should allow all traffic to be inspected by CBAC. (Traffic denied by the access list will be dropped.)
CBAC will examine the packet and record information about it in the state table (this table is viewable with the command show ip inspect session detail). The information in the state table includes the source and destination IP addresses and TCP or UDP port numbers.
CBAC creates a temporary opening in an access list for the return traffic; these openings will vary depending on the application used. The temporary entries will be placed on the interface that will receive the return traffic.
A return packet reaches a router interface. The return packet is permitted by the temporary access-list entries and inspected by CBAC. CBAC will update the state table and modify the temporary access-list entries if necessary. All future packets that are part of this network conversation are inspected similarly to update tables and access-list entries as needed.
When the connection is completed, the entries in the state table and the inbound access list are removed. For TCP these entries are removed after a normal FIN exchange between the client and server. For UDP there are configurable inactivity timeouts.

CBAC inspects only TCP and UDP packets. Other IP traffic (such as Internet Control Message Protocol, or ICMP) must be filtered with traditional IP access lists. Packets with the router as the source or destination address are not inspected by CBAC. If both Cisco encryption technology (CET) and CBAC are configured, CBAC will not be able to accurately inspect the contents of the CET-encrypted packets.

If both IPSec and CBAC are configured, CBAC can inspect the traffic correctly as long as the CBAC router is the end point of the IPSec tunnel. If the router is not the end point of the tunnel, CBAC cannot inspect the packets because the packets will not have a TCP or UDP header.
CBAC uses approximately 600 bytes of memory per connection to maintain each entry in the state table. In addition, a small amount of additional processing occurs during the inspection process.

Network Address Translation NAT

NAT is a feature that dynamically modifies the contents of IP packets flowing through the router so that the source and/or destination IP addresses are altered. Packets leaving the router will have the source or destination address translated to a different IP address so an administrator can hide the IP addresses in use on an internal network behind a router performing NAT. This technique is a requirement for organizations using addresses from the RFC 1918 unregistered address space or using IP addresses that are registered to other organizations.

NAT can be used to alter both the source and destination IP addresses in IP headers and the IP checksum is updated automatically by the NAT process. Some applications imbed the source IP address of hosts in the data portion of the IP packet, so additional modification of the packet is required. For these applications, the NAT process must also modify the data portion of the packet to match the modified source IP address in the IP header. Cisco's version of NAT can handle many applications that place the IP address in the data portion of the packet. Cisco's version also allows load-sharing TCP traffic by permitting TCP requests to a single IP address to be serviced by multiple hosts.

NAT is most often used at administrative domain boundaries such as the Internet or connections between different organizations. NAT is useful not only for organizations that do not have registered IP addresses, but also for organizations that have a registered IP address range but have more hosts than can be accommodated by the number of addresses. Unregistered addresses may be used internally and registered addresses used only when packets communicate with external networks. The NAT process is transparent to both source and destination hosts for most applications.

Although NAT is a very useful tool, it does have some drawbacks. The central difficulty with NAT is that, as mentioned earlier, some applications imbed the original source IP address in the data portion of the IP packet. Therefore, after undergoing NAT, the source IP address of the packet does not match the IP address imbedded in the data portion of the packet. Applications which imbed the IP address in the data portion of the packet function improperly if the source IP address in the IP header does not match the source IP address imbedded in the data portion of the packet. The Cisco implementation can handle most popular applications that include the IP address in the data portion of the packet. One notable exception is NetBios session services. NetBios services are used by Windows NT, so it is very prevalent in many data networks.

Several terms used when discussing Cisco NAT are helpful:

Inside local address. IP addresses assigned to hosts on the internal network. These addresses are normally only known by internal hosts.
Inside global address. IP addresses assigned to internal hosts by the NAT process; the addresses of internal hosts as seen by external hosts.
Outside local address. IP addresses assigned to external hosts by the NAT process; the addresses of external hosts as seen by internal hosts.
Outside global address. IP addresses assigned to hosts on the external network. These addresses are known by external hosts but may not be known by internal hosts.

Inside addresses are used by the internal network and may or may not be translated. Outside addresses are used by external networks and also may or may not be translated. The term local refers to addresses as seen by internal hosts.

The term global refers to addresses as seen by external hosts. Note that outside local and outside global addresses may be the same if outside addresses are not being translated by NAT, that is, the addresses of external hosts may be the same on external networks as on the internal network.

The easiest way to remember this terminology is that the first word, inside or outside, reflects the origination of the packet. The terms inside local and inside global address both indicate that the packet originated from the inside network. The second word, local or global, indicates where the addresses are seen. Local addresses are seen locally on the inside network. Global addresses are seen globally on the outside network.

Familiarity with several commands is required to enable NAT functionality on the router. First, you need to determine the interfaces on which you will enable NAT and whether they will be an inside or outside interface.

Normally, the interface that connects to your internal network will be the NAT inside and any interfaces that connects to external networks, such as the Internet, will be the NAT outside interface. You can show the translated IP adresses with show ip nat trans

IP Access-Lists

An access list is an ordered set of statements that permits or denies the flow of packets across an interface based on matching criteria of access list parameters and information contained in packets.

Since the flow of data across an interface is bidirectional, an access list can be applied to a specific direction an interface, either inbound or outbound. Here the term inbound refers to the flow of data toward a router, while outbound refers to the flow of data in a direction away from a router.

Two types of access lists are supported by Cisco routers, standard and extended. A standard access list is limited in functionality because it only allows filtering based upon source address. In comparison, an extended access list, as its name implies, extends packet filtering, enabling you to filter packets based upon both source and destination address and upperlayer application data.
The following number ranges are used for standard and extended lists.

Standard access lists: 1-99
Extended access lists: 100 - 199

The format of a standard access list is shown next:

access-list[list-number][permit|deny][source address][wildcard-mask][log]

Permit / Deny

Use of the keyword permit or deny is what specifies whether or not packets that match an access-list entry are allowed to flow through an interface or are filtered.

Source Address

For a standard IP access list the source address is the IP address of a host or group of hosts specified using dotted decimal notation. In reality, the specification of a group of hosts is based upon the use of the wildcard-mask explained next.

Wildcard-mask

The wildcard-mask supported by Cisco access lists functions in a reverse manner to a subnet mask. That is, the access-list mask uses a binary 0 to represent a match and a binary 1 to represent a ?don't care? condition. To illustrate the operation of a wildcard-mask, let's assume your organization has the class C network address 198.78.46.0. Assuming you did not employ subnets, when you configure each station on that network you would enter a subnet mask of 255.255.255.0. In this situation a 1 bit represents a match, while a 0 bit represents a ?don't care? condition. Since the Cisco wildcard-mask is the opposite of a subnet mask, the following standard IP access-list statement is for all packets with a source network address of 198.78.46.0:

access-list 1 permit 198.78.46.0 0.0.0.255

In the preceding access-list statement note that the wildcard-mask of 0.0.0.255 is the compliment of the subnet mask. Thus, another technique to specify an access-list wildcard-mask is to determine the subnet mask and take its inverse.

Host

Host signifies an exact match and represents the wildcard-mask of 0.0.0.0. For example, assume you want to permit packets from source address 198.78.46.8. You could code the following access-list statement:

access-list 1 permit 198.78.46.8 0.0.0.0

Since the keyword host signifies an exact match, the previous access-list statement can be recorded as follows:

access-list 1 permit host 198.78.46.8

Thus, host is an abbreviation for a wildcard-mask of 0.0.0.0

Any

In a standard access list the keyword any is used as an abbreviation for a source address and wildcard-mask of 0.0.0.0 255.255.255.255. For example, assume you wish to deny packets from source address 198.78.46.8 and permit packets from all other addresses. The standard access-list statements to accomplish this would be as follows:

access-list 1 deny host 198.78.46.8
access-list 1 permit any

Note the order of the two statements!

Access-list statements are processed in a top-down order. If we reversed the order and placed the permit statement before the deny statement, we would not be able to bar or filter packets from host address 198.78.46.8 because the permit statement would allow all packets.

Log

When included log in an access list, this keyword results in the logging of packets that match permit and deny statements in the access list. Logging can be done to the console or to another host using the syslog daemon.

An extended IP access list, as its name implies, extends the ability to filter packets. An extended IP access list allows you to filter packets based upon source and destination address, protocol, source and destination port, and a variety of options that permit comparison of specific bits in certain packet fields.

The general format of an extended IP access list is shown below:

access-list[list number][permit|deny][protocol|protocol keyword][source
address source-wildcard][source port][destination address][destination-
wildcard][destination port][log][options]

List Number

Similar to a standard IP access list, the list number identifies an extended IP access list. Numbers 100-199 can be used to define 100 unique extended IP access lists.

Protocol (!)

The protocol entry defines the protocol to be filtered, such as IP, TCP, UDP, ICMP, and so on. The entry of a protocol is important because of the relationship of protocols within the TCP/IP protocol suite that forms datagrams.

That is, an IP header is used to transport ICMP, TCP, UDP, and various routing protocols so that if you specify IP as the protocol to be filtered, all matches against other fields will cause the packet to be permitted or denied regardless of whether the packet represents an application transported by TCP, UDP, or an ICMP message. Thus, if you wish to filter based on a specific protocol, you should specify that protocol. In addition, you should place more specific entries ahead of less specific entries.

For example, if you code a statement permitting IP for a specific address, followed by denying TCP for that address, the second statement would never take effect. However, by reversing the order you could bar TCP to the address, while permitting all other protocols to that address.

Port Number

The source port number can be specified in several ways. It can be
specified explicitly, either as a numeric or as a recognized mnemonic. For example, you could use either 80 or http to specify the Web's hypertext transmission protocol. For TCP and UDP you can use the keyword opertors < (less than), > (greater than), = (equal) and <> (not equal).

Options

A wide range of options is supported by an extended IP access list. One commonly used option is Iog, which was described earlier when we discussed standard IP access lists. A second commonly used option is established. This option is only applicable to the TCP protocol and is employed to restrict TCP traffic in one direction as a response to sessions initiated in the opposite direction. To accomplish this, an access list statement with the established option examines each TCP packet to determine if its ACK or RST bit is set. If it is set, the packet is part of a previously established conversation.

The following rules are important for success. These rules are a mixture of fact and suggestion. The factual portion of a rule is based upon the manner in which access-list processing occurs.

Top-Down Processing

Access-list entries are evaluated from the top down sequentially, commencing with the first entry in the list. This means you must carefully consider the order in which you place statements in an access list.

Adding Entries

New entries are added to the bottom of an access list, which means it may not be possible to change the functionality of an existing access list, requiring you to create a new list, delete the existing list, and apply the new list to an interface.

Standard List Filtering

Standard IP access lists are limited to filtering on source address only, so you may need to use an extended IP access list to satisfy specific organizational requirements.

Access-List Placement

Consider placing extended access lists as close as possible to the source being filtered so that you can create filters that do not adversely affect the data flow on other interfaces. Also, consider placing standard access lists as close as possible to the destination. Since a standard access list only uses source addresses, placing the list too close to the source can block the flow of packets to other ports.

Statement Placement

Since IP includes ICMP, TCP, and UDP, you should place more specific entries in an access list before less specific entries to ensure that one statement ahead of another does not negate the effect of a statement appearing later in the list. access list is applied to an interface, no filtering will occur.

Filtering Direction

The filtering direction defines whether inbound or outbound packets are examined. Always double-check the filtering direction because it defines which packets are examined.

ICMP Redirects

All DMZ Hosts have the BVI32 virtual Interface as their Gateway. If one of this DMZ hosts communicate with a client in the Internet, the Router sends an ICMP Redirect with the address of the Internet client. From now on, the DMZ host sends the IP pakets directly to the Internet client, instead of the Gateway and the Access-List 150 is bypasswd. This not desired effect can be disabled on the BVI32 Interface with the command

no ip redirects

Routes sometimes can become less than optimal. For example, it is possible for the router to be forced to resend a packet through the same interface on which it was received. If this happens, the router sends an ICMP Redirect message to the packet's originator telling it that it is on a subnet directly connected to the router, and that it must forward the packet to another system on the same subnet. It does so because the originating host presumably could have sent that packet to the next hop without involving the router at all. The Redirect message instructs the sender to remove the router from the route and substitute a specified device representing a more direct path. This feature is enabled by default.

Complete Configuration File

Here is the complete configuration file:

!
version 12.1
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname c2621
!
logging buffered 4096 debugging
no logging console
enable secret 5 $1$elmZ$4.EfdgcLJz7MNUffP4HHA0
enable password 7 045C05030632
!
ip subnet-zero
no ip finger
no ip domain-lookup
!
ip inspect max-incomplete high 1100
ip inspect max-incomplete low 900
ip inspect one-minute high 1100
ip inspect one-minute low 900
ip inspect name Ethernet_HSZ ftp timeout 3600
ip inspect name Ethernet_HSZ tcp timeout 3600
ip inspect name Ethernet_HSZ http java-list 51 timeout 3600
ip inspect name Ethernet_HSZ smtp timeout 3600
ip inspect name Ethernet_HSZ udp timeout 15
ip inspect name Ethernet_HSZ cuseeme timeout 3600
ip inspect name Ethernet_HSZ h323 timeout 3600
ip inspect name Ethernet_HSZ rcmd timeout 3600
ip inspect name Ethernet_HSZ realaudio timeout 3600
ip inspect name Ethernet_HSZ streamworks timeout 3600
ip inspect name Ethernet_HSZ vdolive timeout 3600
ip inspect name Ethernet_HSZ sqlnet timeout 3600
ip inspect name Ethernet_HSZ tftp timeout 30
ip inspect name Ethernet_BVI smtp timeout 3600
ip inspect name Ethernet_BVI tcp timeout 3600
ip inspect name Ethernet_BVI udp timeout 15
ip audit notify log
ip audit po max-events 100
bridge irb
!
interface FastEthernet0/0
description DMZ
no ip address
duplex auto
speed auto
bridge-group 32
!
interface FastEthernet0/1
description HSZ
ip address 192.168.138.1 255.255.255.0
ip access-group 102 in
ip access-group 103 out
ip nat inside
ip inspect Ethernet_HSZ in
duplex auto
speed auto
!
interface Ethernet1/0
description Internet
no ip address
bridge-group 32
!
interface BVI32
ip address 194.246.125.195 255.255.255.240
ip access-group 150 in
no ip redirects
ip nat outside
ip inspect Ethernet_BVI in
!
ip nat inside source list 101 interface BVI32 overload
ip classless
ip route 0.0.0.0 0.0.0.0 194.246.125.193
no ip http server
!
logging trap debugging
logging facility user
logging 192.168.138.21
!
! Disabling NAT between HSZ and DMZ for some hosts
!
access-list 101 deny   tcp host 192.168.138.28 194.246.125.192 0.0.0.15
access-list 101 deny   tcp host 192.168.138.21 194.246.125.192 0.0.0.15
access-list 101 deny   tcp host 192.168.138.15 194.246.125.192 0.0.0.15
access-list 101 deny   udp host 192.168.138.28 194.246.125.192 0.0.0.15
access-list 101 deny   udp host 192.168.138.21 194.246.125.192 0.0.0.15
access-list 101 deny   udp host 192.168.138.15 194.246.125.192 0.0.0.15
access-list 101 permit ip 192.168.138.0 0.0.0.255 any
!
! Extended Access-Lists
!
access-list 102 permit ip 192.168.138.0 0.0.0.255 any
access-list 102 deny   ip any any log
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.28 eq domain
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.15 eq domain
access-list 103 permit udp 194.246.125.192 0.0.0.15 host 192.168.138.28 eq domain
access-list 103 permit udp 194.246.125.192 0.0.0.15 host 192.168.138.15 eq domain
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.28 eq smtp
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.15 eq smtp
access-list 103 permit tcp host 194.246.125.196 host 192.168.138.21 eq 22
access-list 103 permit tcp host 194.246.125.196 host 192.168.138.28 eq 143
access-list 103 permit tcp host 194.246.125.196 host 192.168.138.15 eq www
access-list 103 deny   icmp any any log
access-list 103 deny   ip any any log
access-list 150 permit udp any any eq domain
access-list 150 permit udp any eq domain any range 1000 65000
access-list 150 permit tcp any any eq domain
access-list 150 permit tcp any eq domain any range 1000 65000
access-list 150 permit tcp 194.246.125.192 0.0.0.15 eq www any
access-list 150 permit tcp 194.246.125.192 0.0.0.15 eq smtp any
access-list 150 permit tcp 194.246.125.192 0.0.0.15 range 1000 65000 any eq smtp
access-list 150 permit tcp any 194.246.125.192 0.0.0.15 eq smtp
access-list 150 permit udp 194.246.125.192 0.0.0.15 range 1000 65000 any eq ntp
access-list 150 permit udp any 194.246.125.192 0.0.0.15 eq ntp
access-list 150 permit tcp host 194.246.125.196 eq 22 any
access-list 150 permit tcp host 194.246.125.196 host 192.168.138.21 eq 22
access-list 150 permit tcp host 194.246.125.196 host 192.168.138.28 eq 143
access-list 150 permit tcp host 194.246.125.196 host 192.168.138.15 eq www
access-list 150 permit tcp host 194.246.125.196 eq 443 any
access-list 150 permit tcp host 194.246.125.196 eq 3970 any
access-list 150 permit tcp host 194.246.125.196 eq 7777 any
access-list 150 permit tcp host 194.246.125.196 eq 7778 any
access-list 150 deny   icmp any any log
access-list 150 deny   ip any any log
bridge 32 protocol ieee
bridge 32 route ip
!
line con 0
transport input none
line aux 0
line vty 0 4
password 7 030F5A070D
login
!
end

Configuration

The CISCO Router is configured with TELNET or a serial line connection.

telnet 192.168.138.1

Trying 192.168.138.1...
Connected to 192.168.138.1.
Escape character is '^]'.

User Access Verification
Password: ........

c2621>enable
Password: .........

c2621# show config

Start the TFTP Server on your Windows 2000 Workstation and download the Configurationfile.

c2621# copy running-config tftp

Address or name of remote host []? 192.168.138.23
Destination filename [c2621-confg]? c2621-confg-2001.06.15

Upload the configurationfile

c2621# copy tftp running-config

Address or name of remote host []? 192.168.138.23
Source filename [c2621-confg]? c2621-confg-2001.06.15

Activate the configurationfile

c2621# write mem

You can also edit the configuration directly on the router

c2621# conf t
c2621(config)# .......
c2621(config)# <CTRL>-Z
c2621# write mem