Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 879
  • Last Modified:

Getting EIGRP to work on a Cisco 2811

I have recently brought a remote office onto my network, and installed a 2811 at the new site.

S0/0/0 - T1 DSU that terminates a T1/frame-relay connection to the corporate head-end ATM bundle.
FA0/0 - to the office's existing DSL connectivity by way of a PIX 506e.  The PIX is 172.16.0.1/30, FA0/0 is .1 with a slash 30, this interface's IP is 172.16.0.2/30.
FA0/1 - 192.168.0.1/25, and attaches to a Cisco 2950 switch.  This is the default gateway for everyone now and their LAN IP's are on the 192.168.0.0/25 subnet.

As far as routing - I need any requests for 192.168.1.x, 192.168.2.x, and 192.168.3.x (all are /24) to go out the Serial interface to our corporate network.  Anything else (i.e. default route) is static'd to go to the next hop of 172.16.0.1 (PIX) and on out to the Internet.

The 192.168.1, 2, & 3 networks I would have expected to be learned via EIGRP just like all the other branch offices, but I was not getting any EIGRP routes across the frame-relay at all.  If I do a 'sh ip eigrp nei' on the 2811, I see no neighbors, and I should be seeing the corporate head-end router.  There is nothing stopping EIGRP at the head-end.  Is there a line in the 2811 config that is new and needs to be there to get EIGRP up and running to not only learn routes, but send the route for 192.168.0.0 back to the head-end at corporate?  For now I just have them static routed which is ok, but doesn't follow the usual model.

Also, and maybe related - I can't get traffic from FA0/1 to route and go out on FA0/0.  As you already know, any traffic not destined for a corporate 192.168 network, I want to default route to the PIX and on out to the Internet.  I need traffic from the workstations, hanging off of FA0/1 to default route to the PIX attached to FA0/0.  My default route is:

ip route 0.0.0.0 0.0.0.0 172.16.0.1

From the router, I can ping external addresses just fine.  From the switches or workstations, I cannot.  Any ideas what I am missing?

Thanks in advance.
0
RyanSmith_NetMD
Asked:
RyanSmith_NetMD
  • 5
  • 5
1 Solution
 
mikebernhardtCommented:
The PIX may need it's config modified to permit the other subnets going out. Are they listed as Inside networks?

As far as EIGRP, it's impossible to help you thoroughly without seeing configs from both ends of the frame relay. But do keep in mind that if there's any sort of access lists they will affect it. EIGRP uses it's own IP type and can be permitted with
access-list 100 permit eigrp any any
0
 
mikebernhardtCommented:
Oh also, forEIGRP, you need to have both the serial IP and the LAN IP in the EIGRP configuration. Both ends need the serial IP of course. And they need to be the same EIGRP AS #.
0
 
lrmooreCommented:
Can you post result of "sho ip int brief" and "sho ip route" from this 2811 ?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
RyanSmith_NetMDAuthor Commented:
Thanks Mike - EIGRP is now working, I left out of the Serial IP's subnet in the EIGRP network list.

Let me better explain what I am trying to accomplish here (albeit a long post...):

I have a small company network that I need to join to our corporate network.  I luck out in a couple ways, one being that I do not need to re-IP anything, as they use a subnet that we have not used yet.

Their existing network is comprised of a PIX 506e and a couple unmanaged Linksys switches.  The PIX's inside interface is 192.168.0.1 with a /25 mask, and is their default gateway for all machines.

I am moving them over to our network via a frame-relay connection, a Cisco 2811 router, and 3 Cisco 2950 switches.  Normally, our branch offices traverse the frame-relay back into corporate for everything, including Internet connectivity.  Here however, I want to preserve their existing business DSL connection and let any internet traffic they generate hit their existing PIX and DSL.

My plan is to have the 2811's FA0/1 interface be IP'd to 192.168.0.1/25.  All switches would attach to this interface and it would be the new default gateway, so no changes to the workstations and servers would be necessary.

FA0/0 would attach to the existing PIX.  It would be IP'd as 172.16.0.2/30 and the PIX's inside interface would be changed to 172.16.0.1/30.

S0/0/0 is the frame-relay to corporate.

For routing - the routes to corporate would be learned via EIGRP and this part works just fine.  My plan was to set a default route that directs any non-192.168 traffic to 172.16.0.1, which is the PIX and would send Internet traffic out that way.

When this was all put in place, the following occured:

Their LAN (on FA0/1) can ping back and forth to our corporate office, all the routes are coming in from EIGRP and that part is taken care of.

Their LAN CANNOT connect to the internet.  From a workstation on their LAN, I can ping 192.168.0.1, and can ping across the frame-relay, but I cannot ping FA0/0 or the PIX.  Routing shouldn't be an issue because these are directly connected networks, correct?

From the router, I CAN ping external, internet addresses through the PIX and DSL connection.  I can also ping out on every other router interface just fine.  It literally feels like the 2811 has some default command in it that says don't let traffic from one FA to crossover to the other FA interface.  Is there some sort of security enabled by default on these routers that keeps FA0/1 from talking to FA0/2?

Thanks for your help.
0
 
RyanSmith_NetMDAuthor Commented:
Also - I forgot to say how I plan to accomplish sending internet traffic out to the PIX.  This will be done via default route:  ip route 0.0.0.0 0.0.0.0 172.16.0.1

For simplicities sake, I have stripped my config of EIGRP and just did static's for everything...

ip route 192.168.1.0 255.255.255.0 192.168.254.26 (sending it out the serial interface)
ip route 192.168.2.0 255.255.255.0 192.168.254.26 (sending it out the serial interface)
ip route 192.168.3.0 255.255.255.0 192.168.254.26 (sending it out the serial interface)
ip route 0.0.0.0 0.0.0.0 172.16.0.1 (defaulting everything else out to the PIX via FA0/0)

What is stopping traffic from going out the other FA int?
0
 
mikebernhardtCommented:
>Is there some sort of security enabled by default on these routers that keeps FA0/1 from talking to FA0/2?
 I assume you mean it can't talk to FA0/0, not FA0/2.

Have you tried using extended ping on the router? On the router, try just pinging FA0/0 using a source address of FA0/1.

Post your config without passwords and that might help too.
0
 
RyanSmith_NetMDAuthor Commented:
Sorry about this - I meant FA0/0 and 0/1.  FA0/1 cannot talk to FA0/0.

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname router
!
boot-start-marker
boot-end-marker
!
enable secret <enable password>
!
aaa new-model
!
!
!
aaa session-id common
!        
resource policy
!
clock timezone est -5
clock summer-time edt recurring
ip subnet-zero
!
!
ip cef
!
!
ip flow-cache timeout active 1
!
username user password userspassword
!
!
!
interface Loopback0
 ip address 192.168.200.39 255.255.255.255
!
interface FastEthernet0/0
 description To PIX 506e Firewall
 ip address 172.16.0.2 255.255.255.252
 ip route-cache flow
 duplex full
 speed 100
!
interface FastEthernet0/1
 description To Switches/User Community
 ip address 192.168.0.1 255.255.255.128
 ip route-cache flow
 duplex full
 speed 100
!
interface Serial0/0/0
 description AT&T Frame-Relay T1
 no ip address
 encapsulation frame-relay IETF
 ip route-cache flow
 no ip mroute-cache
 no fair-queue
 service-module t1 timeslots 1-12
 service-module t1 remote-alarm-enable
 frame-relay lmi-type cisco
!
interface Serial0/0/0.1 point-to-point
 bandwidth 768
 ip address 192.168.254.26 255.255.255.252
 frame-relay interface-dlci 45  
!
interface BRI0/1/0
 no ip address
 ip route-cache flow
 shutdown
!
ip classless
ip route 192.168.1.0 255.255.255.0 192.168.254.25
ip route 192.168.2.0 255.255.255.0 192.168.254.25
ip route 192.168.3.0 255.255.255.0 192.168.254.25
ip route 0.0.0.0 0.0.0.0 172.16.0.1
ip flow-export source Loopback0
ip flow-export version 5
ip flow-export destination 192.168.2.28 2055
!        
no ip http server
!
logging trap debugging
logging 192.168.2.28
access-list 70 remark ACL to restrict SNMP to 192.168.2.28 Only
access-list 70 permit 192.168.2.28
access-list 70 deny   any log
snmp-server community public@BAHS_SNMP RO 70
snmp-server community private@BAHS_SNMP RW 70
snmp-server ifindex persist
!
control-plane
!
line con 0
 password 7 111A4A13121C
line aux 0
line vty 0 4
 exec-timeout 60 0
 password 7 105D5A0F0019
line vty 5 15
!        
scheduler allocate 20000 1000
ntp clock-period 17180201
ntp server 192.168.2.1
!
end
0
 
mikebernhardtCommented:
There's nothing in that config that should cause any problems. Try the extended ping I suggested. also verify the PIX config- is it configured to know that 192.168.0.0/22 is inside addressing? You readdressed the inside interface, but did you modify rules as needed so that it will still work?
0
 
RyanSmith_NetMDAuthor Commented:
Thanks Mike - I guess I am confused.  Why would the PIX need anything other than an address change - if their current network is 192.168.0.x/25, and I am keeping that the same - the PIX will see all of the same [source/internal] addresses it has always been seeing, correct?

If I was changing to a whole new IP scheme, I can understand changes being needed, but why in this case?
0
 
mikebernhardtCommented:
Well, because before, the PIX was inside the LAN and the inside hosts were directly connected to the PIX. Now, the hosts are on a different network. By default, the PIX will allow traffic out from hosts on the inside interface. But subnets beyond that have to be trusted- and NAT'd too.
0
 
RyanSmith_NetMDAuthor Commented:
Thanks Mike.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now