Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Policy routing problem

I'm trying to investigate RFC1918 addressed packets coming in on my internet connection. For this I set up policy routing on my serial interface to the provider. This is a frame relay PVC, an unnumbered interface if that matters. An extended access list checks for the source and destination:

access-list 104 permit ip 10.0.0.0 0.255.255.255 any log

access-list 104 permit ip 172.16.0.0 0.15.255.255 any log

access-list 104 permit ip 192.168.0.0 0.0.255.255 any log

The policy routing should move the packets out on interface ethernet 1:

route-map testing permit 10

match ip address 104

set interface Ethernet1

The policy map is bound on both local and on interface serial 0.1000:

ip local policy route-map testing

interface Serial0.1000 point-to-point

mtu 18000

ip unnumbered Ethernet0

no ip directed-broadcast

no ip mroute-cache

no ip route-cache

ip policy route-map testing

bandwidth 512

frame-relay interface-dlci 1000

Problem:

Incoming packets src=10.10.10.206 port 80 dst=whatever are not send to interface e1 while localy generated packets are (extended ping, src=10.0.0.1, dst=whatever)

Am I doing something wrong? Can't this be done the way I try it, is there another way to achieve my goal?

thanks in advance,

Alex

5 REPLIES
New Member

Re: Policy routing problem

How do you know that the packets are not going to E1? What tests have you run?

Do the hits show up on the access-list? In the log (is your logging level set properly)?

It would appear to me that this would work, except that the router would be ARPing for the destination addresses on E1 and there probably isn't anything with the correct address to reply to the arp.

Maybe try (very carefully) some debugs to see where the traffic is actually going.

Also, be sure that the destination IP address is not one that the router owns. If it is, policy routing may not work (depending on IOS version).

Mick.

New Member

Re: Policy routing problem

Sorry, should have mentioned this. The reason I now the packets are coming in on the PVC is because of an access list. The reason I know they are going out on E0 and not on E1 is because I can't capture them on the box connected to E1 and they do get logged on a box connected to E0.

I'm absolutely sure the packets do end up on E0 and not on E1 (unless originating from the router itself --> no problems then).

The arp may be the cause of the problem (although the packets shouldn't go to E0, do they?) and to circumvent that I changed my route-map to have a next-hop of a known host on E1.

Thanks so far, hope you have more for me!

New Member

Re: Policy routing problem

I think that making it a next-hop of an E1 address would work best.

Also, just for giggles, turn off fast switching on your serial interface (no ip route-cache). Depending on your version of IOS, you may have policy routing problems. Just a thought.

Mick.

New Member

Re: Policy routing problem

Unless you're more curious about these packets then you're concerned about security - My advice is simply to block rfc1918 sources on your broder routers. In and Out.

Any source IP using these addresses are likely to be spoofed, and some may be 'single packet attacks'. Its highly unlikely that any reply packets will make it back to these sources, the ISP is not going to route these addresses (unless they happen to be part of the ISP's own internal network). I'd suggest you action this by asking the ISP to properly secure your service and ask them to confirm that they follow cisco security guidelines to disable antispoofing, no ip source-routing, etc on their borders. Add your own ACL's anyway. Then maybe if policy routing is of interest, examine this as a seperate challange once you've plugged the hole and removed a risk.

If your running BGP to the ISP check you're not leaking network 10 etc yourself.

sho ip bgp neighbor n.n.n.n adv

This may also unexpectedly bring this traffic to you. If you find this, eith remove the offending networks from your bgp process, or filter them out in your announcements to your ISP and clear the session.

Regards, Jeremy.

New Member

Re: Policy routing problem

There are reasons to investigate. First of all, I have reasons to believe these packets come from (a) malfunctioning NAT device(s) near (a) frequently used website(s) (which may or may not be hosted/connected by our provider). The packets *are* filtered and thus the user requesting a page from problem sites experiences this as "a bad network connection" I have made. Of course, the problem is on the other side and I want this proven.

The second reason is our beloved ISP/Telco/monopolist where the cluefull people and the customers are being firewalled by a bunch of... never mind.

Anyway, after one full week of "you must be wrong because we're filtering that at the border" now it's "we're not filtering that but we still do not believe you anyway". This all of course gets documented together with a dump of the packets, in order to convince the people who pay that we need a real provider.

97
Views
0
Helpful
5
Replies