routing problems with multiple T1s - I know whats wrong but dont know how to fix it
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||
|
Posted by Jason on March 9, 2006, 3:44 am
Please log in for more thread options 3 T1's are point to point and are running fine, all their data gets router to ethernet0 and to the route of last resort which is a sonicwall at 172.25.5.4 or to other routers on the local LAN, so no problems there...... the other two T1s are internet T1s, and want them to use ethernet1 however because of the route of last resort sending all packets to ethernet0 and then to an internal sonicwall, I cannot ping either of the serial interfaces of the internet T1s from the internet But if I change the route of last resort to one of the serial interfaces for the internet T1s, I get no problems whatsoever..... example ip route 0.0.0.0 0.0.0.0 serial0/1/0:0 So basically I am wondering if there is any way to get those two internet t1s to behave like "their own separate routers" - and not to use the route of last resort - and instead to have their own. For example if traffic comes in on the serial0/1/0:0 interface, that it has its OWN route of last resort, and doesnt try to respond by routing packets out of 172.25.5.4..... for example one of the internet t1s is currently: qwest serial 67.135.122.121/30 cust serial 67.135.122.122/30 Lan block, 67.135.120.224/27 - is it possible to get this t1 to act as its "own separate router" using gigabitethernet0/1? like as if it was a cookie cutter 1720 config with just a single T1 and a single ethernet setup Hope I made sense, please ask anything if I need to clarify, thanks for any help Current configuration : 4458 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname 2851 ! boot-start-marker boot-end-marker ! logging buffered 51200 warnings enable secret 5 $1$L3cS$F4P4pH5bc55snATw8GBPd. ! no aaa new-model ! resource policy ! network-clock-participate wic 0 network-clock-participate wic 1 no network-clock-participate wic 2 ip subnet-zero ! ! no ip cef ! ! ip domain name yourdomain.com ! username ! ! controller T1 0/0/0 framing esf clock source internal linecode b8zs channel-group 0 timeslots 1-24 description Verizon Hawaii T1 ! controller T1 0/0/1 framing esf clock source internal linecode b8zs channel-group 0 timeslots 1-24 description Verizon ! controller T1 0/1/0 framing esf clock source internal linecode b8zs channel-group 0 timeslots 1-24 description circuit ! controller T1 0/1/1 framing esf linecode b8zs channel-group 0 timeslots 1-24 description circuit 1 ! controller T1 0/2/0 framing esf clock source internal linecode b8zs channel-group 0 timeslots 1-24 description NY PTP T1 ! controller T1 0/2/1 framing esf linecode b8zs ! ! interface Tunnel1 no ip address ! interface GigabitEthernet0/0 description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$ ip address 172.25.5.1 255.255.255.0 duplex auto speed auto ! interface GigabitEthernet0/1 ip address 67.135.120.225 255.255.255.224 secondary ip address 65.125.161.193 255.255.255.224 duplex auto speed auto ! interface FastEthernet0/3/0 ! interface FastEthernet0/3/1 ! interface FastEthernet0/3/2 ! interface FastEthernet0/3/3 ! interface Serial0/0/0:0 ip address 10.2.10.1 255.255.255.252 no ip route-cache ! interface Serial0/0/1:0 ip address 10.1.10.1 255.255.255.252 encapsulation ppp no ip route-cache ! interface Serial0/1/0:0 ip address 67.135.122.122 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp ip route-cache flow no fair-queue ! interface Serial0/1/1:0 ip address 67.135.122.126 255.255.255.252 no ip route-cache no fair-queue ! interface Serial0/2/0:0 ip address 10.10.10.2 255.255.255.252 encapsulation ppp no ip route-cache ! interface Vlan1 no ip address ! ip classless ip route 0.0.0.0 0.0.0.0 172.25.5.4 ip route 10.0.0.0 255.255.255.0 172.25.5.4 ip route 10.0.7.0 255.255.255.0 172.25.5.4 ip route 10.10.15.0 255.255.255.0 172.25.5.4 ip route 164.55.2.0 255.255.255.0 172.25.5.19 ip route 164.55.3.0 255.255.255.0 172.25.5.19 ip route 169.141.1.44 255.255.255.255 172.25.5.22 ip route 172.25.6.0 255.255.255.0 172.25.5.4 ip route 172.25.7.0 255.255.255.0 10.2.10.2 ip route 172.25.7.0 255.255.255.0 Serial0/0/0:0 ip route 172.25.10.0 255.255.255.0 10.1.10.2 250 ip route 172.25.10.0 255.255.255.0 172.25.5.4 252 ip route 199.105.176.0 255.255.248.0 172.25.5.7 ip route 199.105.178.136 255.255.255.255 172.25.5.7 ip route 199.105.178.138 255.255.255.255 172.25.5.7 | |||||||||||||
|
Posted by Charlie Root on March 9, 2006, 4:03 am
Please log in for more thread options or it might be VRF-Lite. Sorry, your description is a bit unclear. Can you post an ASCII diagram of your setup and try to re-phrase what do you want to achieve? Kind regards, iLya | |||||||||||||
|
Posted by Merv on March 9, 2006, 6:29 am
Please log in for more thread options a few comments about the config:
1. Why has CEF been disabled ( no ip cef) ??? 2. The following two static routes are duplicate, remove the one pointing to interface ip route 172.25.7.0 255.255.255.0 Serial0/0/0:0 ip route 172.25.7.0 255.255.255.0 10.2.10.2 | |||||||||||||
|
Posted by Barry Margolin on March 9, 2006, 8:27 am
Please log in for more thread options
> I have 5 separate t1's going into a single cisco 2851 router
> > 3 T1's are point to point and are running fine, all their data gets router > to ethernet0 and to the route of last resort which is a sonicwall at > 172.25.5.4 or to other routers on the local LAN, so no problems there...... > > the other two T1s are internet T1s, and want them to use ethernet1 > however because of the route of last resort sending all packets to ethernet0 > and then to an internal sonicwall, I cannot ping either of the serial > interfaces of the internet T1s from the internet > But if I change the route of last resort to one of the serial interfaces for > the internet T1s, I get no problems whatsoever..... example ip route > 0.0.0.0 0.0.0.0 serial0/1/0:0 > > So basically I am wondering if there is any way to get those two internet > t1s to behave like "their own separate routers" - and not to use the route > of last resort - and instead to have their own. For example if traffic > comes in on the serial0/1/0:0 interface, that it has its OWN route of last > resort, and doesnt try to respond by routing packets out of 172.25.5.4..... The problem is that when a packet goes out, there's no way for the router to know that it was in reply to something that came in on a particular T1. So you can't link inbound and outbound this way. All the router can do is get the destination address of the outgoing packet, and look it up in the routing table. If you configure policy routing it can also look at the source address, protocol, and port numbers -- but it's still just based on the attributes of the outgoing packet, not the incoming packet that it was in reply to. >
> for example one of the internet t1s is currently: qwest serial > 67.135.122.121/30 cust serial 67.135.122.122/30 Lan block, > 67.135.120.224/27 - is it possible to get this t1 to act as its "own > separate router" using gigabitethernet0/1? like as if it was a cookie cutter > 1720 config with just a single T1 and a single ethernet setup You could use policy routing to make traffic coming from ethernet1 use the T1 as its default gateway: interface gigabitethernet0/1 ip policy force_qwest route-map force_qwest set default next-hop 67.135.122.121 >
> Hope I made sense, please ask anything if I need to clarify, thanks for any > help > > > > > > > > > Current configuration : 4458 bytes > ! > version 12.4 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname 2851 > ! > boot-start-marker > boot-end-marker > ! > logging buffered 51200 warnings > enable secret 5 $1$L3cS$F4P4pH5bc55snATw8GBPd. > ! > no aaa new-model > ! > resource policy > ! > network-clock-participate wic 0 > network-clock-participate wic 1 > no network-clock-participate wic 2 > ip subnet-zero > ! > ! > no ip cef > ! > ! > ip domain name yourdomain.com > ! > username > ! > ! > controller T1 0/0/0 > framing esf > clock source internal > linecode b8zs > channel-group 0 timeslots 1-24 > description Verizon Hawaii T1 > ! > controller T1 0/0/1 > framing esf > clock source internal > linecode b8zs > channel-group 0 timeslots 1-24 > description Verizon > ! > controller T1 0/1/0 > framing esf > clock source internal > linecode b8zs > channel-group 0 timeslots 1-24 > description circuit > ! > controller T1 0/1/1 > framing esf > linecode b8zs > channel-group 0 timeslots 1-24 > description circuit 1 > ! > controller T1 0/2/0 > framing esf > clock source internal > linecode b8zs > channel-group 0 timeslots 1-24 > description NY PTP T1 > ! > controller T1 0/2/1 > framing esf > linecode b8zs > ! > ! > interface Tunnel1 > no ip address > ! > interface GigabitEthernet0/0 > description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$ > ip address 172.25.5.1 255.255.255.0 > duplex auto > speed auto > ! > interface GigabitEthernet0/1 > ip address 67.135.120.225 255.255.255.224 secondary > ip address 65.125.161.193 255.255.255.224 > duplex auto > speed auto > ! > interface FastEthernet0/3/0 > ! > interface FastEthernet0/3/1 > ! > interface FastEthernet0/3/2 > ! > interface FastEthernet0/3/3 > ! > interface Serial0/0/0:0 > ip address 10.2.10.1 255.255.255.252 > no ip route-cache > ! > interface Serial0/0/1:0 > ip address 10.1.10.1 255.255.255.252 > encapsulation ppp > no ip route-cache > ! > interface Serial0/1/0:0 > ip address 67.135.122.122 255.255.255.252 > no ip redirects > no ip unreachables > no ip proxy-arp > ip route-cache flow > no fair-queue > ! > interface Serial0/1/1:0 > ip address 67.135.122.126 255.255.255.252 > no ip route-cache > no fair-queue > ! > interface Serial0/2/0:0 > ip address 10.10.10.2 255.255.255.252 > encapsulation ppp > no ip route-cache > ! > interface Vlan1 > no ip address > ! > ip classless > ip route 0.0.0.0 0.0.0.0 172.25.5.4 > ip route 10.0.0.0 255.255.255.0 172.25.5.4 > ip route 10.0.7.0 255.255.255.0 172.25.5.4 > ip route 10.10.15.0 255.255.255.0 172.25.5.4 > ip route 164.55.2.0 255.255.255.0 172.25.5.19 > ip route 164.55.3.0 255.255.255.0 172.25.5.19 > ip route 169.141.1.44 255.255.255.255 172.25.5.22 > ip route 172.25.6.0 255.255.255.0 172.25.5.4 > ip route 172.25.7.0 255.255.255.0 10.2.10.2 > ip route 172.25.7.0 255.255.255.0 Serial0/0/0:0 > ip route 172.25.10.0 255.255.255.0 10.1.10.2 250 > ip route 172.25.10.0 255.255.255.0 172.25.5.4 252 > ip route 199.105.176.0 255.255.248.0 172.25.5.7 > ip route 199.105.178.136 255.255.255.255 172.25.5.7 > ip route 199.105.178.138 255.255.255.255 172.25.5.7 -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** | |||||||||||||
|
Posted by Jason on March 9, 2006, 11:27 am
Please log in for more thread options thanks for the replies all
I tried to get the policy routing to work, this is what the router finally accepted from me: route-map force_qwest permit 10 set ip next-hop 67.135.122.121 interface GigabitEthernet0/1 ip policy route-map force_qwest hope that is correct? does this mean all packets that leave interface gigabitethernet0/1 will be forced out the serial interface of the T1 at 67.135.122.122, serial0/1/0:0 ? also, what if a packet comes in from serial0/1/0:0 ?I assume because it will be heading for one of the LAN IP's on gigabitethernet0/1, it will be forced right back out serial0/1/0, so that should work no problems? for example lets say I put a windows server at 67.135.120.226 on a switch connected to gigabitethernet0/1 someone on the internet decides to ping 67.135.120.226 obviously the packet comes in on serial0/1/0:0 at 67.135.122.122, I guess the trick is how to force the router to send that packet to gigabitethernet0/1 to 67.135.120.226, and then obviously force the response to the ping (from the windows server) out the same interface (serial0/1/0:0) I am going to bond those 2 internet T1s to simplify things I think, I also removed no ip cef thanks again for help all >
>> I have 5 separate t1's going into a single cisco 2851 router
>> >> 3 T1's are point to point and are running fine, all their data gets >> router >> to ethernet0 and to the route of last resort which is a sonicwall at >> 172.25.5.4 or to other routers on the local LAN, so no problems >> there...... >> >> the other two T1s are internet T1s, and want them to use ethernet1 >> however because of the route of last resort sending all packets to >> ethernet0 >> and then to an internal sonicwall, I cannot ping either of the serial >> interfaces of the internet T1s from the internet >> But if I change the route of last resort to one of the serial interfaces >> for >> the internet T1s, I get no problems whatsoever..... example ip route >> 0.0.0.0 0.0.0.0 serial0/1/0:0 >> >> So basically I am wondering if there is any way to get those two internet >> t1s to behave like "their own separate routers" - and not to use the >> route >> of last resort - and instead to have their own. For example if traffic >> comes in on the serial0/1/0:0 interface, that it has its OWN route of >> last >> resort, and doesnt try to respond by routing packets out of >> 172.25.5.4..... >
> The problem is that when a packet goes out, there's no way for the > router to know that it was in reply to something that came in on a > particular T1. So you can't link inbound and outbound this way. All > the router can do is get the destination address of the outgoing packet, > and look it up in the routing table. If you configure policy routing it > can also look at the source address, protocol, and port numbers -- but > it's still just based on the attributes of the outgoing packet, not the > incoming packet that it was in reply to. > >>
>> for example one of the internet t1s is currently: qwest serial >> 67.135.122.121/30 cust serial 67.135.122.122/30 Lan block, >> 67.135.120.224/27 - is it possible to get this t1 to act as its "own >> separate router" using gigabitethernet0/1? like as if it was a cookie >> cutter >> 1720 config with just a single T1 and a single ethernet setup >
> You could use policy routing to make traffic coming from ethernet1 use > the T1 as its default gateway: > > interface gigabitethernet0/1 > ip policy force_qwest > > route-map force_qwest > set default next-hop 67.135.122.121 > > >>
>> Hope I made sense, please ask anything if I need to clarify, thanks for >> any >> help >> >> >> >> >> >> >> >> >> Current configuration : 4458 bytes >> ! >> version 12.4 >> service timestamps debug datetime msec >> service timestamps log datetime msec >> no service password-encryption >> ! >> hostname 2851 >> ! >> boot-start-marker >> boot-end-marker >> ! >> logging buffered 51200 warnings >> enable secret 5 $1$L3cS$F4P4pH5bc55snATw8GBPd. >> ! >> no aaa new-model >> ! >> resource policy >> ! >> network-clock-participate wic 0 >> network-clock-participate wic 1 >> no network-clock-participate wic 2 >> ip subnet-zero >> ! >> ! >> no ip cef >> ! >> ! >> ip domain name yourdomain.com >> ! >> username >> ! >> ! >> controller T1 0/0/0 >> framing esf >> clock source internal >> linecode b8zs >> channel-group 0 timeslots 1-24 >> description Verizon Hawaii T1 >> ! >> controller T1 0/0/1 >> framing esf >> clock source internal >> linecode b8zs >> channel-group 0 timeslots 1-24 >> description Verizon >> ! >> controller T1 0/1/0 >> framing esf >> clock source internal >> linecode b8zs >> channel-group 0 timeslots 1-24 >> description circuit >> ! >> controller T1 0/1/1 >> framing esf >> linecode b8zs >> channel-group 0 timeslots 1-24 >> description circuit 1 >> ! >> controller T1 0/2/0 >> framing esf >> clock source internal >> linecode b8zs >> channel-group 0 timeslots 1-24 >> description NY PTP T1 >> ! >> controller T1 0/2/1 >> framing esf >> linecode b8zs >> ! >> ! >> interface Tunnel1 >> no ip address >> ! >> interface GigabitEthernet0/0 >> description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$ >> ip address 172.25.5.1 255.255.255.0 >> duplex auto >> speed auto >> ! >> interface GigabitEthernet0/1 >> ip address 67.135.120.225 255.255.255.224 secondary >> ip address 65.125.161.193 255.255.255.224 >> duplex auto >> speed auto >> ! >> interface FastEthernet0/3/0 >> ! >> interface FastEthernet0/3/1 >> ! >> interface FastEthernet0/3/2 >> ! >> interface FastEthernet0/3/3 >> ! >> interface Serial0/0/0:0 >> ip address 10.2.10.1 255.255.255.252 >> no ip route-cache >> ! >> interface Serial0/0/1:0 >> ip address 10.1.10.1 255.255.255.252 >> encapsulation ppp >> no ip route-cache >> ! >> interface Serial0/1/0:0 >> ip address 67.135.122.122 255.255.255.252 >> no ip redirects >> no ip unreachables >> no ip proxy-arp >> ip route-cache flow >> no fair-queue >> ! >> interface Serial0/1/1:0 >> ip address 67.135.122.126 255.255.255.252 >> no ip route-cache >> no fair-queue >> ! >> interface Serial0/2/0:0 >> ip address 10.10.10.2 255.255.255.252 >> encapsulation ppp >> no ip route-cache >> ! >> interface Vlan1 >> no ip address >> ! >> ip classless >> ip route 0.0.0.0 0.0.0.0 172.25.5.4 >> ip route 10.0.0.0 255.255.255.0 172.25.5.4 >> ip route 10.0.7.0 255.255.255.0 172.25.5.4 >> ip route 10.10.15.0 255.255.255.0 172.25.5.4 >> ip route 164.55.2.0 255.255.255.0 172.25.5.19 >> ip route 164.55.3.0 255.255.255.0 172.25.5.19 >> ip route 169.141.1.44 255.255.255.255 172.25.5.22 >> ip route 172.25.6.0 255.255.255.0 172.25.5.4 >> ip route 172.25.7.0 255.255.255.0 10.2.10.2 >> ip route 172.25.7.0 255.255.255.0 Serial0/0/0:0 >> ip route 172.25.10.0 255.255.255.0 10.1.10.2 250 >> ip route 172.25.10.0 255.255.255.0 172.25.5.4 252 >> ip route 199.105.176.0 255.255.248.0 172.25.5.7 >> ip route 199.105.178.136 255.255.255.255 172.25.5.7 >> ip route 199.105.178.138 255.255.255.255 172.25.5.7 >
> -- > Barry Margolin, barmar@alum.mit.edu > Arlington, MA > *** PLEASE post questions in newsgroups, not directly to me *** > *** PLEASE don't copy me on replies, I'll read them in the group *** | |||||||||||||
> t1s to behave like "their own separate routers" - and not to use the route
> of last resort - and instead to have their own. For example if traffic
> comes in on the serial0/1/0:0 interface, that it has its OWN route of last
> resort, and doesnt try to respond by routing packets out of
> 172.25.5.4.....
>