cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2618
Views
0
Helpful
32
Replies

PBR 3560 12.2(53) ipservice

CT_Dude
Level 1
Level 1

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

32 Replies 32

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.

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

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.

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

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

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)

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

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.

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

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?

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

Regarding the :

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

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?

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

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

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

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

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

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: