Private WAN Work Around?

[jfklives]

Long story short, I'm testing out the HWIC-1ADSL on a Cisco 1841 using a /29 public block provided by Covad. It took me a few but I was able to get the circuit online with the following:

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
no aaa new-model
memory-size iomem 5
ip cef
!
no ip dhcp use vrf connected
!
ip dhcp pool lan
network 192.168.13.0 255.255.255.0
default-router 192.168.13.1
!
ip name-server 64.105.172.27
ip name-server 67.100.88.27
!
multilink bundle-name authenticated
vpdn enable
!
vpdn-group 1
request-dialin
protocol pppoe
l2tp tunnel receive-window 1024
!
archive
log config
hidekeys
!
bba-group pppoe global
!
!
interface FastEthernet0/0
ip address 192.168.13.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address x.x.x.1 255.255.255.248
duplex auto
speed auto
!
interface ATM0/0/0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
dsl enable-training-log
pvc 0/35
encapsulation aal5snap
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated
ip mtu 1492
encapsulation ppp
no ip mroute-cache
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname "YourNameHere@bz8"
ppp chap password 0 "YourPassWord"
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip http server
no ip http secure-server
ip dns server
!
access-list 1 permit any
dialer-list 1 protocol ip permit
!
control-plane
!
line con 0
password cisco
login
line aux 0
line vty 0 4
password cisco
login
!
scheduler allocate 20000 1000
!
webvpn cef
end

The easy part is out of the way but onto my problem. Covad assigns private IP's for the egress interface for blocks larger than a /32. The following is what my circuit looks like after authentication:

Router#sho ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.13.1 YES manual up down
FastEthernet0/1 1.1.1.1 YES manual up up
ATM0/0/0 unassigned YES manual up up
Virtual-Access1 unassigned YES unset up up
Virtual-Access2 unassigned YES unset up up
Dialer1 172.22.134.246 YES IPCP up up

I'm sure this all seems straight forward so, here's the question. The goal of my test was to find away to keep both fast ethernet interfaces private and somehow pat off the egress. Is it possible to assign the /29 block to an interface other than fa0/0 or fa0/1? I had visions in my head of a sub or loopback interface off ATM0/0/0 but any attempt to remove the /29 from one of the fa interfaces proved to be unsuccessful.

 

[burtsbees]

Why do you even need the public IP addresses in the first place?

Burt

 

[jfklives]

The public IP addresses would be forwarded through FA0/0, FA/01, & the remaining HWIC for services/protocols that cannot be changed.

 

[burtsbees]

But why do you even need public IP addresses vs private? No nat is needed then...routes will be directly connected.

Burt

 

[jfklives]

The private IP's are dynamically assigned by the ISP to route through their ATM core in order to conserve IPv4 space. Once authentication occurs, the public IP's are then routed to that private /30 and can be routed to/fro. Again, these private are not assigned by me but by Covad, as I mentioned above.

 

[burtsbees]

You are showing a private IP address on the adsl interface (ATM). Are fa0/0 and fa0/1 pointing toward your LAN? Do you have control over the router? If so, you don't need the public IP's no matter who assigned them!

 

[jfklives]

You are showing a private IP address on the adsl interface (ATM). Are fa0/0 and fa0/1 pointing toward your LAN"

ummm...no ..... ip route 0.0.0.0 0.0.0.0 Dialer1

As I mentioned already, the device "is" online and working as it was designed to by the provider.

"Do you have control over the router?"

Yes, as mentioned already, I configured this device. It works as the ISP designed their static ip solution's to be. The account includes a public /29 routed to the DSL circuit. In order for the "ISP", not the solution I'm discussing but the ISP's, "product" to profitable and conserve IPv4 addresses at the same time, they route a /30 (RFC 1918 burtsbees ...)to the external WAN/egress interface of the CPE. This is accomplished via PPPoE through their network that services are provided upon me to work with by the provider. All information going towards the CPE would come in through their edge router on the public IP address and then routed to the private /30 you mentioned earlier. From then, the /29 is passed down a layer and is switched via ATM until it hits interface ATM0/0/0. The egress, which should be authenticated with the /30 by this time, passes the /29 off to a LAN port. I hope that clear it up.

"If so, you don't need the public IP's no matter who assigned them!"

In order for external locations to access the CPE, I must have publicly routable IP addresses. This is not a private network.

 

[burtsbees]

What you have configured is a private (RFC1918) on the dialer. That is the WAN interface. I don't understand where the public IP's come in---it looks like from your post that you want the public IP addresses on the LAN. If the dialer can ping

http://www.google.com

as it stands (extended ping, extended commands so you can choose the source interface), then that means the ISP is doing the NAT on their end. You therefor do NOT need public IP addresses! If you have, for example, an FTP server on your LAN, then the ISP must statically NAT (port forward) this address to their other /30 connecting to your dialer as an inside static NAT. Your setup seems totally backwards, and I cannot see how that could possibly work, unless I just don't understand the setup. It all seems goofy to me...
Does anyone else understand this? Brian? Andy? Tad? Viper???

Burt

 

[jfklives]

Covad routes public customer IP's similar to Verizon and a few other ISP's I've worked with in the past. The configurations for DSL are almost identical. You do not understand but I'll try to clear it up once again. The private 172.x.x.x block is not configured statically, as you'll notice from the following interfaces, which are essentially one:

!
interface ATM0/0/0
no ip address <----- There is no IP on the ATM
no atm ilmi-keepalive
dsl operating-mode auto
dsl enable-training-log
pvc 0/35
encapsulation aal5snap
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated <---- negotiated = assigned
ip mtu 1492
encapsulation ppp
no ip mroute-cache
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname "YourNameHere@bz8"
ppp chap password 0 "YourPassWord"

Once layer 2 sync has been achieved, the PPPoE session is initiated to Covad's radius server. Their radius dynamically assigns the CPE with a RFC1918 address to be used on the egress port. The private IP is only used internally on Covad's core to route the public block to/from the DSL loop, which should be configured on the ethernet interface. There is absolutely no nat happening. The private egress IP's do not route outside of Covad's internal network. ICMP requests, or any other traffic, sent from that interface to the Internet will fail. The only way traffic can leave is if the source address is coming from the public block, with exception to being assigned "one" static/dynamic IP, but that is a different type of Covad account (/32 public vs /29 or greater).

Trust me, I really do know what I'm talking about here.

 

[jfklives]

My testing of the Cisco 1841 with a HWIC-1ADSL is complete. The solution works great using my configuration on the top. You may need to tweak some of the layer 3 settings to suit your ISP, but if you're running PPP, this config should save you a lot of headaches.

As for the original question I posed, that portion of testing has also been concluded. All of the network gods I've spoke with think that it should work, as do I, but are unable to provide me with a working solution. If I pick it up down the road, I'll be sure to post on it but I've spent enough time on it to last me a while.