×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

PBR 3560 12.2(53) ipservice

Answered Question
Aug 13th, 2010
User Badges:

Hope someone can spread some light here please..

Trying to setup PBR for traffic from one server to another to go over a direct link between site A and B.

But it looks like PBR is not going over the P2P but over the VPN tunnel.

Is there any way I can check activ connections maybe?

Is the config incorrect?

Config as follow :


Site A

Site B


Riverbeds DG pointing to Switch (Site A and B)

Connected via a VPN tunnel on Cisco ASA 5510.

Also have a P2P connection between 2 sites connected on a 3560 8 Port Poe with ver 12.2(53) ipservice image loaded.


ip routing (enable on both switches)


Switch (Site A)


Interface Fa0/1

descripotion (Connected ASA 5510)

speed 100

duplex full


Interface Fa0/8

description (direct connection to site B)

no switchport

ip address 10.0.0.1 255.255.255.252

speed 100

duplex full


Interface Gi0/1

description (Connected to riverbed)


Interface Vlan1

ip address 192.168.100.1 255.255.255.0

ip route-cache policy

ip policy route-map P2P


ip local policy route-map P2P

ip default-gatway 192.168.100.254 (ASA inside)

ip classless

ip route 0.0.0.0 0.0.0.0 192.168.0.254


ip access-list extended P2P-ACL

permit ip host 192.168.0.25 host 192.168.1.12


ip sla enable reaction-alerts (not sure where from?)

route-map P2P permit 10

match ip address P2P-ACL

set ip next-hop 10.0.0.2 10.0.0.1

Correct Answer by Peter Paluch about 7 years 4 days ago

Hello Cillie,


Yes, you can try to remove that default route and let's see what happens. Just pay attention to be in a network that is known to that switch, otherwise you could lock yourself out.


Best regards,

Peter

Correct Answer by Peter Paluch about 7 years 4 days ago

Cillie,


Thanks for the additional information.


I see some problems in the current configuration. What I will post now is a complete sequence of commands you can directly paste into the respective switch configuration to get them into the form I would configure them. Understandably, back up your configuration before making these changes.


Switch at the Site A:


no ip local policy route-map P2P

no ip default-gateway 192.168.0.254


ip route 0.0.0.0 0.0.0.0 192.168.0.254


ip access-list extended P2P

no permit ip host 192.168.0.25 11.0.0.1 0.0.0.252

permit ip host 192.168.0.25 11.0.0.0 0.0.0.255


interface Vlan1

no ip policy route-map VPN

ip policy route-map P2P


interface Vlan101

no ip policy route-map P2P


Switch at the Site B:


no ip local policy route-map P2P

no ip default-gateway 192.168.1.254


ip route 0.0.0.0 0.0.0.0 192.168.1.254


interface Vlan100

no ip policy route-map P2P


Please make the indicated changes to the switch configuration and test the results. If that does not work, please post again the resulting configurations of both switches on Site A and B, and also include the output of the command show route-map


Best regards,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Peter Paluch Fri, 08/13/2010 - 09:29
User Badges:
  • Cisco Employee,

Hello,


1) Do you have sdm prefer routing configured on both your Cat3560 switches? If not or if you are not sure if you have configured this then enter this command in the global configuration mode, save the configuration and reload the switch. For PBR to work, the TCAM (the switching hardware) must be partitioned in such a way that there is a space allocated for PBR entries. If you have the default SDM setting which is the "default" (use the show sdm prefer command to see the current SDM template) then there is no space for PBR entries in the TCAM which may be the cause why your PBR is not working.


2) If the ip routing command is entered then the ip default-gateway command is superfluous in your configuration and can be removed.


3) The set ip next-hop in your route-map contains two IP addresses, one of them being your own IP address, I believe. That is incorrect in itself - you cannot forward a packet back to yourself. The set ip next-hop command should, in your case, contain a single IP address 10.0.0.2.


4) When you enter the show route-map command does it display any non-zero counter in the line "Policy routing matches"?


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 01:21
User Badges:

1) The current template is "desktop routing" template.

    The selected template optimizes the resources in
    the switch to support this level of features for
   8 routed interfaces and 1024 VLANs.


   number of unicast mac addresses:                  3K
   number of IPv4 IGMP groups + multicast routes:    1K
   number of IPv4 unicast routes:                    11K
   number of directly-connected IPv4 hosts:        3K
   number of indirect IPv4 routes:                 8K
   number of IPv4 policy based routing aces:         0.5K
   number of IPv4/MAC qos aces:                      0.5K
   number of IPv4/MAC security aces:                 1K


2)removed the ip default-gateway now.


3)removed the local ip out of the set-ip next hop.


4)not sure what you mean by non-zero's?


route-map P2P-LONDON, permit, sequence 10
  Match clauses:
    ip address (access-lists): P2P-ACL
  Set clauses:
    ip next-hop 11.0.0.2
  Policy routing matches: 1488 packets, 155712 bytes

cillie.truter Mon, 08/16/2010 - 01:26
User Badges:

How I know its not working.


On the Terminal monitor its displaying a message :

redirect sent to 192.168.100.25 for dest (external ip of SiteB), use gw 192.168.100.254

Peter Paluch Mon, 08/16/2010 - 01:45
User Badges:
  • Cisco Employee,

Hello Cillie,


According to your first post, your P2P-ACL used in the route-map is as follows:


ip access-list extended P2P-ACL

permit ip host 192.168.0.25 host 192.168.1.12


Note that you have just now indicated a different IP address: 192.168.100.25, and you have hidden the external IP address of the site B - is it 192.168.1.12 or a different address? In any case, it seems as if the IP addresses in the ACL did not align with your real traffic you want to perform policy routing upon.


Can you please double check the addressing used in your network and perhaps correct the information you have posted here? It is difficult to help you if the information posted here is not accurate.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 01:58
User Badges:

Hi Peter



Just checked. The IP address ranges are the same.

I was probably just thinking of another range.


The External IP address I hidden is a different ip address. The exteranl Internet address of SiteB.

Peter Paluch Mon, 08/16/2010 - 02:12
User Badges:
  • Cisco Employee,

Cillie,


Okay but shouldn't the P2P-ACL in this case contain the correct external IP address of the site B?


Is the debugging message about the "redirect" relevant to our case? Is it not just a different message, unrelated to the PBR? In any case, the output of the show route-map indicates that there are packets being policy routed - there are counters containing both the number of packets and the amount of data, and both are greater than zero (and hopefully increasing).


To verify that the PBR is working, use the traceroute from the source IP address towards the destination. Using debugging on the switch may produce several messages unrelated to the issue we are trying to solve here.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 02:23
User Badges:

Everytime I make a connection from the 2 servers that is in the access list.

The above redirect comes up.

Looks like only icmp traffic is going over the P2P.


Here is a tracert from the win 2008 server :


Tracing route to machinename [192.168.1.12]
over a maximum of 30 hops:


  1     4 ms     1 ms     1 ms  192.168.0.240
  2     *        *        *     Request timed out.
  3    70 ms    70 ms    70 ms machinename [192.168.1.12]

Peter Paluch Mon, 08/16/2010 - 02:36
User Badges:
  • Cisco Employee,

Cillie,


Is it by any means possible that the Win2008 server is using a different address for either the source or destination IP address than the addresses indicated in the P2P-ACL when you make a connection from one to another?


Obviously, the Win2008 server is using the Cat3560 as its default gateway. The reason that the Cat3560 sends a redirect to the Win2008 server is that it needs to send the packet out the same IP interface through which the packet came in. That in turn means that the PBR was not applied to the packet. The only reason I can see right now is that the traffic does not match the P2P-ACL.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 02:59
User Badges:

Getting the same feeling.

But what else must be in the access-list.

Just disabled IPv6, but still not working I think.

Peter Paluch Mon, 08/16/2010 - 03:09
User Badges:
  • Cisco Employee,

Cillie,


Are you able to install the Wireshark software on at least one of those Win2008 servers and have a close look on the packets leaving one Win2008 server and heading towards the other? The Wireshark - I'm sure you know it - is a packet sniffer. Give it a try!


Also, is it absolutely certain that there is no device that could be overwriting IP addresses, placed between your Win2008 server and the 3560?


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 03:51
User Badges:

How do you route traffice from one subnet 192.168.0.0/24 to subnet

192.168.1.0/24 over 2 cisco 3560's that is connected with a network cabl

e on port Fa0/8?

Peter Paluch Mon, 08/16/2010 - 04:34
User Badges:
  • Cisco Employee,

Cillie,


I am sorry but I do not understand this question.


In case you are replying to my question about "devices between the Win2008 server and the 3560 switch", I had a different issue on my mind: is it possible that some device between the WIn2008 server and the first 3560 is translating the IP addresses in such a way that the fail to match the P2P-ACL?


Please take into account that my knowledge of your network is limited, and is based only on the information you have provided yourself. I had to guess and assume some details.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 05:57
User Badges:

Hi Peter


I know the information is limited. Sorry.


How it is suppose to work is that there is a direct line From SiteA to SiteB.

This is connected on port Fa0/8 on both the switches. (So you could say this is connected as direct Cat 5 cable.)

Site A is subnet 192.168.0.0/24

Site B is subnet 192.168.1.0/24


What I want to accomplish is to send some traffic over the VPN but through the dedicated P2P network.

Peter Paluch Mon, 08/16/2010 - 06:14
User Badges:
  • Cisco Employee,

Cillie,


I have just noticed: in one of the previous outputs, your route-map contained a different next hop than the one in your first post. It seems that currently, your route-map uses the command set ip next-hop 11.0.0.2. Is that so? Shouldn't it be 10.0.0.2?


I understand what you want to achieve, and I believe we are very close to solving this. Just please bear with me a little more.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 06:39
User Badges:

Hi Peter


It was set to 10.0.0.2 then changed it to 11.0.0.2.

But this still did not help me.

So currently there is no ip set for this Vlan (took it out) as I am not sure if this is the correct why to do the routing.


I could ping 11.0.0.2 from the SiteB. But could not ping 11.0.0.1 From SiteB.


Did the following and its working over the VPN.


interface Vlan1
ip address 192.168.0.240 255.255.255.0
ip route-cache policy
ip policy route-map VPN


route-map VPN permit 20
match ip address VPN-LONDON
set ip next-hop 192.168.0.254 (Firewall)


ip access-list extended VPN-LONDON
permit ip 192.168.0.0 0.0.0.255 192.168.5.0 0.0.0.255 (know this is a different site again. But was just a test to see if the route-map policy is working)


But can't get the routing to happen on the Fa0/8 network.

Getting the feeling it is because the servers can't see the remote 11.0.0.x network range.

Peter Paluch Mon, 08/16/2010 - 07:16
User Badges:
  • Cisco Employee,

Hello Cillie,


I am getting increasingly confused by the number of different IP addresses and next hops you are naming here with some of them coming completely out of blue with no possibility to pair them with the configuration you have posted. We have to stick with a particular source/destination and not change it arbitrarily "just to see if something gets changed". So let put some things to a particular state and hold to them until explicitely asked to do a change, otherwise we are both wasting our time.


A picture of your network would be most helpful. Can you provide a simplified graphical depiction of the topology and the preferred route together with consistent addressing?


Please be so kind as to answer or correct the following statements:


  • The Win2008 servers are on subnets 192.168.0.0/24 (site A) and 192.168.1.0/24 (site B). Is this correct? If not please let me know the correct addressing information.
  • Is there an appropriate "interface Vlan X" created on the 3560 on the site A that belongs to the IP network 192.168.0.0/24 or to the correct subnet in which the server on site A is placed? The "X" must match the VLAN in which the servers are placed. Are there any intermediary routers present between the Win2008 and the 3560 on the Site A?
  • The 3560 on the site A on its Fa0/8 interface is configured with 10.0.0.1/30 and the opposite device connected to that interface is 10.0.0.2/30. Is this correct?
  • Is it possible to ping 10.0.0.2 from the 3560 on the site A?


The configuration of the PBR you were using is basically correct. I am quite certain that we are just facing addressing problems.


About servers being unable to see the 11.0.0.0/8 network - this has nothing to do with PBR. Note that the servers are completely oblivious to the 11.0.0.0/8 network because they communicate using their 192.168.x.0/24 addresses. How routers deliver their packets, that is not the servers' business.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 08:33
User Badges:

Hope the image is what you looking for.


Current config as follow.


Site A


interface FastEthernet0/8
description P2P
switchport access vlan 101
speed 100
duplex full
!
interface GigabitEthernet0/1
description RIVERBED
!
interface Vlan1
ip address 192.168.0.240 255.255.255.0
ip route-cache policy
ip policy route-map VPN
!
interface Vlan101
ip address 11.0.0.1 255.255.255.0
ip route-cache policy
ip policy route-map P2P
!
ip local policy route-map P2P
ip default-gateway 192.168.0.254
ip classless
ip route 192.168.2.0 255.255.255.0 192.168.0.254
ip route 192.168.5.0 255.255.255.0 192.168.0.254
ip http server
ip http secure-server
!
!
ip access-list extended P2P
permit ip host 192.168.0.25 host 192.168.1.12
permit ip host 192.168.0.25 11.0.0.1 0.0.0.252
permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255
ip access-list extended VPN
permit ip 192.168.0.0 0.0.0.255 192.168.5.0 0.0.0.255
permit ip 192.168.0.0 0.0.0.255 192.168.2.0 0.0.0.255
!
ip sla enable reaction-alerts
access-list 101 permit ip host 192.168.0.25 host 192.168.1.12
route-map P2P permit 10
match ip address P2P
set ip next-hop 11.0.0.2
!
route-map VPN permit 20
match ip address VPN
set ip next-hop 192.168.0.254


Site B


!
interface FastEthernet0/8
description P2P
switchport access vlan 100
speed 100
duplex full
!
interface GigabitEthernet0/1
description RIVERBED
!
interface Vlan1
ip address 192.168.1.240 255.255.255.0
ip route-cache policy
ip policy route-map P2P
!
interface Vlan100
ip address 11.0.0.2 255.255.255.0
ip route-cache policy
ip policy route-map P2P
!
ip local policy route-map P2P
ip classless
ip route 192.168.2.0 255.255.255.0 192.168.1.254
ip route 192.168.5.0 255.255.255.0 192.168.1.254
ip http server
ip http secure-server
!
!
ip access-list extended P2P
permit ip host 192.168.1.12 host 192.168.0.25
permit ip 192.168.1.0 0.0.0.255 11.0.0.0 0.0.0.255
!
ip sla enable reaction-alerts
access-list 101 permit ip host 192.168.1.12 host 192.168.0.25
route-map P2P permit 10
match ip address P2P
set ip next-hop 11.0.0.1


Server A on Site A

192.168.0.25 GW 192.168.0.240 (SiteA cisco switch)

ServerB on Site A

192.168.1.12 GW 192.168.1.240 (SiteB cisco switch)


No other router inbetween the servers and the cisco switch.


Two switches can ping each other on 11.0.0.0 network.

Attachment: 
Correct Answer
Peter Paluch Mon, 08/16/2010 - 09:07
User Badges:
  • Cisco Employee,

Cillie,


Thanks for the additional information.


I see some problems in the current configuration. What I will post now is a complete sequence of commands you can directly paste into the respective switch configuration to get them into the form I would configure them. Understandably, back up your configuration before making these changes.


Switch at the Site A:


no ip local policy route-map P2P

no ip default-gateway 192.168.0.254


ip route 0.0.0.0 0.0.0.0 192.168.0.254


ip access-list extended P2P

no permit ip host 192.168.0.25 11.0.0.1 0.0.0.252

permit ip host 192.168.0.25 11.0.0.0 0.0.0.255


interface Vlan1

no ip policy route-map VPN

ip policy route-map P2P


interface Vlan101

no ip policy route-map P2P


Switch at the Site B:


no ip local policy route-map P2P

no ip default-gateway 192.168.1.254


ip route 0.0.0.0 0.0.0.0 192.168.1.254


interface Vlan100

no ip policy route-map P2P


Please make the indicated changes to the switch configuration and test the results. If that does not work, please post again the resulting configurations of both switches on Site A and B, and also include the output of the command show route-map


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 09:30
User Badges:

Tracert from 192.168.0.25 to 192.168.1.12


Tracing route to hostname [192.168.1.12]
over a maximum of 30 hops:


  1     1 ms     1 ms     5 ms  192.168.0.240
  2     *        *        *     Request timed out.
  3    70 ms    70 ms    70 ms  hostname [192.168.1.12]


Trace complete.


sh route-map before and after.


route-map P2P-LONDON, permit, sequence 10
  Match clauses:
    ip address (access-lists): P2P-ACL
  Set clauses:
    ip next-hop 11.0.0.2
  Policy routing matches: 1503 packets, 157302 bytes
LOND-R245#sh route-map
route-map P2P-LONDON, permit, sequence 10
  Match clauses:
    ip address (access-lists): P2P-ACL
  Set clauses:
    ip next-hop 11.0.0.2
  Policy routing matches: 1506 packets, 157620 bytes


So route map shows that there is traffic going through.

Could I remove the following to check if it is realy going over the P2P, because still gettting a feeling its going over the VPN.

ip route 0.0.0.0 0.0.0.0 192.168.0.254<br/>



P2P is only 20Mb

VPN is 80Mb


When copying a file from 192.168.1.12 to 192.168.0.25 getting a download of 9Mb (That is the through put of the VPN tunnel)

Correct Answer
Peter Paluch Mon, 08/16/2010 - 09:35
User Badges:
  • Cisco Employee,

Hello Cillie,


Yes, you can try to remove that default route and let's see what happens. Just pay attention to be in a network that is known to that switch, otherwise you could lock yourself out.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 09:36
User Badges:

Hi Peter


Think you are on the right track.

Seeing data on port Fa0/8 now.

So this must be going over the P2P.

I probably just need to sort out the access-list.

Because I went and allowed the whole network to go over the P2P.

Peter Paluch Mon, 08/16/2010 - 09:43
User Badges:
  • Cisco Employee,

Cillie,


Thank you for letting me know.


Please be so kind as to post the ACLs here after you make modifications to them. They are at the core of this entire issue so let's have them double checked.


Regarding the traceroute, we can make an additional test. On the switch on the Site B, enter these commands:


ip access-list extended TracTest

permit ip any host 192.168.0.25


route-map TracTest 10 permit

match ip address TracTest

set ip next-hop 11.0.0.1


ip local policy route-map TracTest


Now, try to do the traceroute from the 192.168.0.25 on Site A to 192.168.1.12 on Site B. With a little luck, the traceroute should now show the 2nd next hop to be the 11.0.0.2. If this test is successful, you may remove all these commands from the switch on the Site B.


Best regards,

Peter

cillie.truter Mon, 08/16/2010 - 10:01
User Badges:

Just copied over a 800Mb file.

Took about 11min but sh route-map did not have any changes.


route-map P2P-LONDON, permit, sequence 10
  Match clauses:
    ip address (access-lists): P2P-ACL
  Set clauses:
    ip next-hop 11.0.0.2
  Policy routing matches: 1512 packets, 158256 bytes
LOND-R245#sh route-map
route-map P2P-LONDON, permit, sequence 10
  Match clauses:
    ip address (access-lists): P2P-ACL
  Set clauses:
    ip next-hop 11.0.0.2
  Policy routing matches: 1512 packets, 158256 bytes


Web interface showing that only port Fa0/8 is showing network through put though.

Is this something to be concerned about?

Peter Paluch Mon, 08/16/2010 - 12:09
User Badges:
  • Cisco Employee,

Hello Cillie,


Web interface showing that only port Fa0/8 is showing network through put though. Is this something to be concerned about?


I do not think so. On multilayer switches, this command will probably show only packets that have been process-switched. As the Catalyst do their packet switching in hardware, the counter on the route-map will not increase for hardware-switched packets.


Did you make that experiment with the traceroute I suggested in my previous post? Did that work? Please give it a try and let me know.


I am somewhat concerned about the transmission speed. Copying an 800 MB for 11 minutes results in 9.69 Mbps. Is that a sensible speed or do you feel it is unusually slow? This depends on the parameters of the circuit that interconnects your two 3560 switches.


Best regards,

Peter

cillie.truter Tue, 08/17/2010 - 01:09
User Badges:

Regarding the :


ip access-list extended TracTest<br/> permit ip any host 192.168.0.25<br/><br/>route-map TracTest 10 permit<br/> match ip address TracTest<br/> set ip next-hop 11.0.0.1<br/><br/>ip local policy route-map TracTest<br/>

Will this affect any other route-map's that is currently configured?

Would it be possible to leave this route map so you can always see the tracert?

Peter Paluch Tue, 08/17/2010 - 01:38
User Badges:
  • Cisco Employee,

Hello Cillie,


Will this affect any other route-map's that is currently configured?


No. The TracTest route-map is applied as a local policy which means that it affects only packets originated by the switch itself. It does not affect routed traffic. Currently, it makes sure that the packets originated by the switch at the Site B (such as ICMP messages used for tracerouting) and sent to the Win2008 server at the Site A will be sent through the direct connection, not through the VPN according to the global routing table.


Would it be possible to leave this route map so you can always see the tracert?


Yes. I see no problem with it.


Actually, it would be correct to create a similar configuration for the switch at the Site A as well:


ip access-list extended TracTest
permit ip any host 192.168.1.12

route-map TracTest 10 permit
match ip address TracTest
set ip next-hop 11.0.0.2

ip local policy route-map TracTest


With these two configurations in place, the tracert from whichever site to another should display the IP address of the switch on the direct connection.


Best regards,

Peter

cillie.truter Tue, 08/17/2010 - 06:07
User Badges:

The tracert did come back as it should.

Tracing route to hostname [192.168.1.12]
over a maximum of 30 hops:


  1     5 ms     1 ms     1 ms  192.168.0.240
  2    72 ms    70 ms    71 ms  11.0.0.2
  3    70 ms    70 ms    70 ms  hostname [192.168.1.12]


Trace complete.


If i change the line :


 permit ip any host 192.168.1.12<br/>

to permit ip any any.

Would this give a problem?


Only problem I having now is it looks like the riverbed device is not increasing performance when using the P2P.

Riverbed DG is pointing to the switches.

And did add their ips in the accesslist.


SiteA

ip access-list extended P2P-ACL
permit ip 192.168.0.0 0.0.0.255 11.0.0.0 0.0.0.255
permit ip host 192.168.0.25 host 192.168.1.12
permit ip host 192.168.0.180 host 192.168.1.180
permit ip host 192.168.0.181 host 192.168.1.181
permit ip host 192.168.0.180 host 192.168.1.12
permit ip host 192.168.0.181 host 192.168.1.12


SiteB

ip access-list extended P2P-ACL-NY
permit ip 192.168.1.0 0.0.0.255 11.0.0.0 0.0.0.255
permit ip host 192.168.1.12 host 192.168.0.25
permit ip host 192.168.1.180 host 192.168.0.180
permit ip host 192.168.1.181 host 192.168.0.181
permit ip host 192.168.1.180 host 192.168.0.25
permit ip host 192.168.1.181 host 192.168.0.25

Peter Paluch Tue, 08/17/2010 - 06:45
User Badges:
  • Cisco Employee,

Cillie,


Changing the line permit ip any host 192.168.0.25 into permit ip any any will result in all unicast packets originated by the switch to be sent to the IP next-hop 11.0.0.1 for routing, even if the packets are destined for hosts on directly connected networks. I do not believe that this is an intended behavior. Personally, I would not modify the ACL entry to be so unspecific.


Your ACLs currently contain the entire networks 192.168.0.0/24 and 192.168.1.0/24 as their first entries. Is that by intention? Perhaps it is a remainder of your debugging with the Riverbed devices. I suppose you want to remove those lines after your diagnostic is finished.


It is hard to tell whether the Riverbed devices should see an increase in performance. We need some more precise indication. Is it possible to perform a traceroute from the Riverbed device and see the results?


Best regards,

Peter

Peter Paluch Tue, 08/17/2010 - 06:51
User Badges:
  • Cisco Employee,

Cillie,


One issue in addition: I see that you have fixed your ports on the 3560 switches to 100 Mbit / Full Duplex by statically configuring them to use this speed and duplex. Is that necessary? Are you absolutely sure you need it configured? Having one side of a connection configured for static speed/duplex and the other running in autonegotiation mode often results in duplex mismatches than can exhibit themselves as a slow connection.


I recommend very strongly that either you do not use the static speed/duplex setting at all, or if you configure a port statically to a particular speed/duplex combination, you must configure the attached device manually to the same speed/duplex. Otherwise a number of nasty and hard-to-diagnose problems may arise. Ideally, I suggest removing the speed and duplex settings from all ports on your 3560 unless you know perfectly that it won't work correctly without them. After removing these commands, use the show interfaces status to see a list of all your interfaces and their current speed and duplex settings. All should be a-full for duplex setting and a-100 or a-1000 for speed setting.


Best regards,

Peter

cillie.truter Tue, 08/17/2010 - 08:04
User Badges:

Got the riverbed to work in the end.

Think it had a session from the day before open and that is why it did not optimize traffic.


We where asked by the ISP to set the port to Speed 100 Duplex full.


Will sort out the access list as soon as I know everything is working as it should.


I must say Thanks allot to you.

You helped me allot!!!

Peter Paluch Tue, 08/17/2010 - 08:13
User Badges:
  • Cisco Employee,

Cillie,

We where asked by the ISP to set the port to Speed 100 Duplex full.


Okay. Hopefully, the ISP also statically set his speed/duplex on his interface. Nevertheless, I would personally make an experiment: remove the speed and duplex setting from a port and see whether it has automatically negotiated the 100/fullduplex operation. If yes then it is better to leave it on autonegotiation. If a port without the static speed and duplex setting fails to link or if it links as 100/halfduplex then the static setting of speed/duplex is required as the ISP indicated.


I must say Thanks allot to you.

You helped me allot!!!


We did it together. You are welcome. Thank you too!


Best regards,

Peter

cillie.truter Tue, 08/17/2010 - 09:27
User Badges:

We did have it on auto.

But then nothing wanted to communicate on the switches/P2P and Riverbed devices.

Actions

This Discussion