cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
732
Views
0
Helpful
8
Replies

Possible to route separate Serial to Ethernet Ports?

jboudreau73
Level 1
Level 1

I have a 2611XM and have 2 Serial T1 interfaces, each with a T1 line connected. Is it possible to route each T1 line to a separate Ethernet port within the router.

So Serial 0/0 traffic only routes to Ethernet 0/0 and Serial 0/1 traffic only routes to Ethernet 0/1.

Currently the T1 lines are multilink together.

8 Replies 8

mohammedmahmoud
Level 11
Level 11

Hi,

Yes you can use PBR Policy Based Routing, if you can tell us more about your scenario we can help you out more (especially the multilink part):

Policy-Based Routing

http://www.cisco.com/warp/public/732/Tech/plicy_wp.htm

Configuring Policy-Based Routing

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt1/qcfpbr.htm

HTH,

Mohammed Mahmoud.

Thanks for the reply. I am using 1 of the Ethernet ports for my internal network. The other is used for a live video conferencing system. When the video conference is connected and any type of heavy network activity, downloads, uploads, it interrupts the video conference. I want to separate them to each use a separate T1. This will hopefully avoid the interruptions.

This is my current configuration... i have xxx the ip addresses for privacy.

----

Current configuration : 1925 bytes

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname myhostname1

!

boot-start-marker

boot-end-marker

!

no network-clock-participate slot 1

no network-clock-participate wic 0

no aaa new-model

ip subnet-zero

no ip source-route

ip cef

!

!

!

ip name-server xxx.xxx.xxx.xxx

ip name-server xxx.xxx.xxx.xxx

no ftp-server write-enable

!

!

!

class-map match-all myhostname1-class

match access-group 199

!

!

policy-map 2-class-short-pipe-egress-myhostname1

class myhostname1-class

priority 640

class class-default

fair-queue

!

interface Multilink3

description Multilink PPP

ip address xxx.xxx.xxx.xxx 255.255.255.252

service-policy output 2-class-short-pipe-egress-myhostname1

ppp multilink

ppp multilink group 3

!

interface FastEthernet0/0

ip address xxx.xxx.xxx.xxx 255.255.255.224

duplex auto

speed auto

!

interface Serial0/0

description T1-1

ip address xxx.xxx.xxx.xxx 255.255.255.252

encapsulation ppp

load-interval 30

no fair-queue

ppp multilink

ppp multilink group 3

!

interface FastEthernet0/1

ip address xxx.xxx.xxx.xxx 255.255.255.252

speed 100

full-duplex

!

interface Serial0/1

description T1-2

ip address xxx.xxx.xxx.xxx 255.255.255.252

encapsulation ppp

load-interval 30

no fair-queue

ppp multilink

ppp multilink group 3

!

ip classless

ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx

no ip http server

!

!

end

Although not related to your initial question about dedicating specific T-1s to specific Ethernet port, you note the underlying issue is video conferencing is being disturbed by other traffic. This is something that QoS should be able to handle. Admittedly, dedicating a link for your vidconf should avoid the issue, it also precludes that bandwidth from your other apps when vidconf isn't using it. You might want to look deeper into your QoS operation and see if it's behaving as it's expected.

I see you have a two class policy that has both LLQ and a default FQ. I see the class map uses ACL 199 but that's not shown in the config? Have you seen all vidconf traffic being placed in the LLQ? What about the far side router?

I am not too concerned about precluding the bandwidth. I do have access lists. QoS seemed to be functioning, but still had interruptions.

Is this what policy based routing would look like:

interface FastEthernet0/1

ip address xxx.xxx.xxx.xxx 255.255.255.252

ip route-cache policy

ip policy route-map FaEtoSerial

speed 100

full-duplex

!

interface Serial0/1

description T1-2

ip address xxx.xxx.xxx.xxx 255.255.255.252

encapsulation ppp

ip route-cache policy

ip policy route-map SerialtoFaE

load-interval 30

no fair-queue

!

ip classless

ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx

no ip http server

!

route-map FaEtoSerial permit 10

set interface Serial0/1

!

route-map SerialtoFaE permit 10

set interface FastEthernet0/1

If the QoS is placing all your video traffic in a CBWFQ LLQ and there are no drops, on both sides, I'm surprised.

One issue I bumped into was this one:

http://www.cisco.com/en/US/tech/tk39/tk824/technologies_tech_note09186a00800fbafc.shtml#topic8

hardware FIFO buffer, and ATM. Don't think it applies for your multilink, but you could try a minimal tx-ring-limit and see if there's any difference in behavior.

PS:

The PBR pros can confirm, think you have something that should work after you split the multilink. However, don't forget the other Ethernet/serial, needs to be isolated from the first pair. Also, to quote Cisco "Note The ip route-cache policy command is strictly for fast-switched PBR and, therefore, not required for CEF-switched PBR."

Another alternative to PBR is to utilize VRF lite. In many cases this can be easier to configure and troubleshoot. You would create a vrf and put one of the serial ports and one of the ethernet ports into the vrf. this would maintain seperate routing tables for each pair of interfaces.

bjw
Level 4
Level 4

I bet if you did a little research related to policy based routing you could find something that works.

http://www.cisco.com/en/US/customer/tech/tk364/technologies_configuration_example09186a0080211f5c.shtml

Richard Burts
Hall of Fame
Hall of Fame

Joey

If the serial lines are multilinked then it is not possible to route data from them separately. If the serial lines are separated and each is treated independently then it should be possible to route them separately.

There are a couple of options to consider which might achieve what you want. You could configure Policy Based Routing. In policy based routing you can make decisions about how to route based on where traffic comes from or other criteria rather than route just on the basis of how to get to the destination address.

The second alternative to consider would be to configure vrf lite. With vrf lite you are logically separating the box into several logical parts. With vrf lite you can link one serial with its Ethernet and link the other serial with its Ethernet.

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco