Adding another class C to my 2620

[Soybomb]

I've got a cisco 2620 with 2 t1's bonded in a multilink configuration. I've been running it with 1 class C of IP's for the time being (lets call it 123.456.789.0/24). I just got my provider to asssign me another class c (lets call it (987.654.321.0/24) and route it to my multilink addres ip (555.555.555.555/255.255.255.252) just as they did with my other class c. I'm not sure what changes to make on my end though.

I presume that ethernet interface should have another IP address assigned to it from that class C, but I'm not sure how to add another IP to the ethernet interface without overwriting its current IP address. Am I right? What should I need to do on my end to get this up? Thanks guys!

Here's my current config:
router1#sho run
Building configuration...

Current configuration : 2979 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname router
!
boot-start-marker
boot-end-marker
!
enable secret 5 $hash
enable password itsasecrat
!
no network-clock-participate slot 1
no network-clock-participate wic 0
no aaa new-model
ip subnet-zero
ip cef
!
!
!
no ip bootp server
no ftp-server write-enable
!
!
!
!
interface Multilink1
ip address 555.555.555.555 255.255.255.252
no peer neighbor-route
no cdp enable
ppp multilink
ppp multilink fragment disable
ppp multilink group 1
!
interface FastEthernet0/0
ip address 123.456.789.1 255.255.255.0
no ip unreachables
speed auto
full-duplex
no cdp enable
no mop enabled
!
interface Serial0/0
no ip address
encapsulation ppp
no ip mroute-cache
no peer neighbor-route
no fair-queue
no cdp enable
ppp multilink
ppp multilink group 1
!
interface Serial0/1
no ip address
encapsulation ppp
no ip mroute-cache
no peer neighbor-route
no fair-queue
no cdp enable
ppp multilink
ppp multilink group 1
!
ip classless
ip route 0.0.0.0 0.0.0.0 Multilink1
no ip http server
!
access-list 1 permit myauthorizednetworkips's here
no cdp run
snmp-server community mysnmpsecret RO
snmp-server enable traps tty
banner login ^C
This sytem is for use by authorized users only. Any user not authorized for this system is required to disconncet now. By continuing you agree to the logging of your keystrokes. Unauthorized access is prosecuted.^C
banner motd ^C
This system is for use by authorized users only. Any user not authorized for this system is required to disconncet now. By continuing you agree that you are an authorized user and consent to logging of your keystrokes.^C
!
line con 0
line aux 0
line vty 0 4
access-class 1 in
password mysecrat
login
!
!
!
end

 

[randal]

Either get another ethernet port or

(not a real good option)

conf t
int fa0/0
ip address 987.654.321.1 255.255.255.0 secondary
ctrl+z


edit: the `secondary` tag will make that interface answer for multiple IP addresses. I've seen upwards of 40 IP addresses on a single interface; the idea of multiple IPs on a single interface is generally not a good network design.

 

[Soybomb]

May not be the ideal solution but it'll get me through today with the equipment I have available, thanks! Does this look like a good ACL?

access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip 0.0.0.0 0.255.255.255 any
access-list 101 deny ip 169.254.0.0 0.0.255.255 any
access-list 101 deny ip 224.0.0.0 31.255.255.255 any
access-list 101 deny udp any any eq netbios-ns
access-list 101 deny udp any any eq netbios-dgm
access-list 101 deny tcp any any eq 139
access-list 101 deny tcp any any eq 445
access-list 101 deny udp any any eq 445
access-list 101 permit ip 888.888.888 0.0.0.63 any
access-list 101 permit ip any 987.654.321.0 0.0.0.255
access-list 101 deny udp any any eq snmp
access-list 101 deny tcp any any eq telnet
access-list 101 permit ip any any

access-list 102 deny udp any eq netbios-ns any
access-list 102 deny udp any eq netbios-dgm any
access-list 102 deny tcp any eq 139 any
access-list 102 deny tcp any eq 445 any
access-list 102 deny udp any eq 445 any
access-list 102 permit ip 123.456.789.0 0.0.0.255 any
access-list 102 permit ip 987.654.321.0 0.0.0.255 any


--------------
The goal here is to block nonrouted IPs, incoming netbios, snmp, and telnet to my 123.456.789.0/24 block, allow acccess to everyone in that block from my trusted range of 888.888.888. and allow all incoming traffic to my new class C (987.654.321.0/24).

For egress filtering I only intend to drop outbound netbios and traffic claiming to be from an IP other than one of my 2 blocks.
-------------

Apply 101 to multilink1 in, apply 102 to multilink1 out. I think i've tried one like that in the past before though and it failed to block the nonrouted IP's, but did block the telnet so I bet I've done something wrong.

 

[spidey07]

for egress, block any address that is not yours.

In otherwords, just a permit statement for whatever address should be sourced from your net.

 

[Soybomb]

Originally posted by: spidey07
for egress, block any address that is not yours.

In otherwords, just a permit statement for whatever address should be sourced from your net.

Isn't that what I'm doing with the following applied out on multilink1:
access-list 102 deny udp any eq netbios-ns any
access-list 102 deny udp any eq netbios-dgm any
access-list 102 deny tcp any eq 139 any
access-list 102 deny tcp any eq 445 any
access-list 102 deny udp any eq 445 any
access-list 102 permit ip 123.456.789.0 0.0.0.255 any
access-list 102 permit ip 987.654.321.0 0.0.0.255 any

the last 2 lines are my 2 class c's. Except I'm also blocking some other outbound stuff I don't want my users putting out.

 

[spidey07]

yeah, i wasn't paying attention. As long as that is applied on egress.

also, block smtp outbound except from your gateways.

 

[Soybomb]

Cool, I thought it was implicit deny, but wanted to be sure. Not a bad point on outbound smtp either.

I seem to recall having this applied in the past and traffic from addresses like 192.168.0.0/16 making it through, although it did block inbound telnet, etc. Any reason why? Is multilink1 the proper interface to apply it to?

 

[spidey07]

yep, there is always an implicit deny at the end of an ACL.

I'm pretty sure you apply it to the multilink bundle, but it's been a while.