Crs-1 ABF traceroute policy routing
We config ABF on crs-1 interface to policy traffic to another next hop
But when we use traceroute. Policy not work
Cco said ABF not support ip option. Traceroute is one of ip option
How can I verify this policy
Thanks
Hello Fly,
Normally default traceroute does not use ipv4 option and should work just fine.
We can not test ABF with traffic originating from the router where the ABF is applied to. It has to be a transit traffic and ABF has to be applied to an ingress interface of the router with ABF.
Here is the example:
RP/0/RP1/CPU0:pixies#sh run ipv4 access-list abf33
Tue May 22 09:53:52.884 CEST
ipv4 access-list abf33
10 permit ipv4 192.168.101.0 0.255.255.255 any nexthop 10.12.113.2
20 permit ipv4 any any
Traceroute from the adjacent router:
before ABF configuration
=================================
RP/0/RP1/CPU0:placebo#traceroute 77.77.77.77
Tue May 22 09:46:12.446 CEST
Type escape sequence to abort.
Tracing the route to 77.77.77.77
1 192.168.101.2 9 msec 8 msec 7 msec
2 12.1.1.1 14 msec * 11 msec
After the ABF configuration on the ingress if of pixies
=================================
RP/0/RP1/CPU0:placebo#traceroute 77.77.77.77
Tue May 22 09:49:12.049 CEST
Type escape sequence to abort.
Tracing the route to 77.77.77.77
1 192.168.101.2 17 msec 9 msec 7 msec
2 10.12.113.2 11 msec 11 msec 7 msec <-------------------- NH from ABF
3 13.1.1.1 7 msec * 9 msec
RP/0/RP1/CPU0:pixies#show access-lists abf33 hardware ingress location 0/2/CPU0
Tue May 22 09:50:55.047 CEST
ipv4 access-list abf33
10 permit ipv4 192.0.0.0 0.255.255.255 any (52 hw matches) (next-hop: 10.12.113.2) <------------------ matching entries in HW
20 permit ipv4 any any (25 hw matches)
Regards,
/A
Similar Messages
-
Ipfilter: does policy routing work on Solaris 10?
Hello,
- Does the ipf redirection (aka policy routing) feature work with the
ipfilter that comes with Solaris 10?
I would like to use the the ipf redirection statements "to
interface:router_ip" or "reply-to interface:router_ip" as decribed in
http://coombs.anu.edu.au/~avalon/ipf.new.txt
(The syntax is mentionned in the BNF of the Solaris 10 ipf(4) man
page, but the explanations there are lacking.)
On a machine that has two interfaces, the purpose is to send output
reply packets of a TCP session to the same interface that the input
packets came from. The idea to use ipfilter to do this comes from the
blog entry:
Packets out of the wrong interface
http://blogs.sun.com/carlson/entry/packets_out_of_the_wrong
My first try was to use "reply-to" in a "keep state" rule:
pass in quick on e1000g305000 reply-to e1000g305000:10.13.5.1 proto tcp from any to any port = 443 keep state keep frags group i_sso-test1
Which I understand as "once a connection to port 443 starts on
interface e1000g305000 send all reply packets to the same interface to
the gateway 10.13.5.1"
But it does not work; in the ipf log it shows that the rule matched:
22:56:32.770690 e1000g305000 @i_sso-test1:1 p 10.194.17.11,5648 -> 10.13.5.181,443 PR tcp len 20 60 -S K-S K-F IN
22:56:32.770783 e1000g0 @i_sso-test1:1 p 10.13.5.181,443 -> 10.194.17.11,5648 PR tcp len 20 44 -AS K-S K-F OUT
But the reply packet is not seen on the router (10.13.5.1), nor does
it get to 10.194.17.11 through another route (no firewall on that
machine).
My second try was to use two stateless rules, and to do "source port
routing" for outgoing packets:
pass in quick proto tcp from any to any port = 443 group i_sso-test1
pass out quick on e1000g0 to e1000g305000:10.13.5.1 proto tcp from any port = 443 to any group o_sso-test1
pass out quick proto tcp from any port = 443 to any group o_sso-test1
Which I understand as "incoming packets to port 443 are allowed and
outgoing packets from port 443, if passing on interface e1000g0, are
redirected through interface e1000g305000 via the gateway 10.13.5.1,
if not, are just allowed".
It does not work either; in the ipf log it shows that both the in and
the first out rules matched:
23:09:00.591163 e1000g305000 @i_sso-test1:1 p 10.194.17.11,26080 -> 10.13.5.181,443 PR tcp len 20 60 -S IN
23:09:00.591363 e1000g0 @o_sso-test1:1 p 10.13.5.181,443 -> 10.194.17.11,26080 PR tcp len 20 44 -AS OUT
But again the reply packet seems to be lost in thin air.
I have tried various other rules to no avail.
- Should this work with ipfilter v4.1.9 (592) coming with Solaris 10
u7?
- Am I missing something in the configuration?
- Shouldn't the ipf log show the outgoing reply packet twice? (Once on
the "wrong" interface e1000g0 and once on the interface it is
redirected to e1000g305000.) Or indicate in another manner that the
redirection occurred (like it indicates K-S for "keep state")?
Context:
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
default 10.194.7.1 UG 1 2407
default 10.194.7.1 UG 1 5104 e1000g0
10.13.5.0 10.13.5.181 U 1 5 e1000g305000:1
10.194.7.0 10.194.7.81 U 1 3 e1000g0:2
224.0.0.0 10.194.7.81 U 1 0 e1000g0:2
127.0.0.1 127.0.0.1 UH 1 7 lo0:7
# cat /etc/release
Solaris 10 5/09 s10s_u7wos_08 SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 30 March 2009
# ipf -V
ipf: IP Filter: v4.1.9 (592)
Kernel: IP Filter: v4.1.9
Running: yes
Log Flags: 0x70000000 = pass, block, nomatch
Default: pass all, Logging: available
Active list: 0
Feature mask: 0x107
If it matters, this is occuring in a Solaris 10 zone, whith virtual
interfaces one of which uses 801.q tagging (vlan 305, subnet
10.13.5.0/24), and the "router" is a Cisco ACE load balancer with
interface 10.13.5.1 on the server side.
Thanks in advance for your help in this matter!
Best regards,
Dominique
Mr Dominique Petitpierre Email: User@Domain
Division Informatique User=Dominique.Petitpierre
University of Geneva Domain=unige.chI was saying
If it matters, this is occurring in a Solaris 10 zone, whith virtual
interfaces one of which uses 801.q tagging (vlan 305, subnet
10.13.5.0/24),...Well, it turns out that 802.1q tagging does matter: packets redirected
by an ipf policy based routing rule to an interface with tagging are
not transmitted.
In order to better see what was happening the ipf rules were extended
like this (stateless case):
@1 pass in quick on e1000g0 proto tcp from any to any port = 443 group i_sso-test1
@2 pass in quick on e1000g305000 proto tcp from any to any port = 443 group i_sso-test1
@1 pass out quick on e1000g0 to e1000g305000:10.13.5.1 proto tcp from 10.13.5.181/32 port = 443 to any group o_sso-test1
@2 pass out quick on e1000g305000 to e1000g0:10.194.7.1 proto tcp from 10.194.7.81/32 port = 443 to any group o_sso-test1
@3 pass out quick on e1000g305000 proto tcp from any port = 443 to any group o_sso-test1
@4 pass out quick on e1000g0 proto tcp from any port = 443 to any group o_sso-test1Also, for the purpose of the demonstration, the zone configuration was
modified to direct all packets to the same interface with tagging,
thus having just one default route:
zonecfg -z sso-test1 info net
net:
address: 10.13.5.181/24
physical: e1000g305000
defrouter: 10.13.5.1
net:
address: 10.194.7.81/24
physical: e1000g305000
defrouter: 10.13.5.1
netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
default 10.194.7.1 UG 1 2867
default 10.13.5.1 UG 1 86 e1000g305000
10.13.5.0 10.13.5.181 U 1 2 e1000g305000:1
10.194.7.0 10.194.7.81 U 1 0 e1000g305000:3
224.0.0.0 10.13.5.181 U 1 0 e1000g305000:1
127.0.0.1 127.0.0.1 UH 1 7 lo0:7 (In this peculiar case the default route to 10.194.7.1 is an artifact
displayed by netstat due to the zone isolation mechanism, but it is
not actually used for routing at the zone level; the interface without
tagging, e1000g0, is only displayed on the global zone where ipfilter
operates)
When testing from 10.194.17.11 with "telnet 10.13.4.180 443", it
works. And one can see in the ipf logs that it is the third out rule
that matched (@o_sso-test1:3), i.e. there was no redirection on
another interface (proof that there is nothing wrong with the context
setup):
16:59:30.479660 e1000g305000 @i_sso-test1:2 p 10.194.17.11,2111 -> 10.13.5.181,443 PR tcp len 20 60 -S IN
16:59:30.479844 e1000g305000 @o_sso-test1:3 p 10.13.5.181,443 -> 10.194.17.11,2111 PR tcp len 20 44 -AS OUT
16:59:30.480182 e1000g305000 @i_sso-test1:2 p 10.194.17.11,2111 -> 10.13.5.181,443 PR tcp len 20 40 -A INWhen testing from 10.194.17.11 with "telnet 10.194.7.81 443", it works
also. This time one can see in the ipf logs that it is the second out
rule that matched (@o_sso-test1:2), i.e. there was redirection from
e1000g305000 to e1000g0.
16:59:41.247101 e1000g0 @i_sso-test1:1 p 10.194.17.11,3851 -> 10.194.7.81,443 PR tcp len 20 60 -S IN
16:59:41.247206 e1000g305000 @o_sso-test1:2 p 10.194.7.81,443 -> 10.194.17.11,3851 PR tcp len 20 64 -AS OUT
16:59:41.247508 e1000g0 @i_sso-test1:1 p 10.194.17.11,3851 -> 10.194.7.81,443 PR tcp len 20 52 -A INA packet capture confirms this and one can see in the capture the
SYN-ACK reply packet go out on e1000g0.
The reverse case, essentially the original setup shown in my first
post, where the default route is the interface without tagging
(e1000g0) and the reply packet matches the redirection rule from
e1000g0 to the interface with tagging e1000g305000, the packet is lost
(i.e. is not visible in the packet capture on either interface).
Further tests with stateful redirection ("reply-to") show the same
pattern (does not work when packets are redirected to an interface
with tagging).
It looks like it is a bug: may be ipfilter injects the redirected
packet at a processing stage where it should already have a 802.1q tag
but does not, or something similar; in the working case, ipfilter acts
on a not yet tagged packet which can be used "as is" at the same
processing stage on the non tagging interface, and thus is correctly
transmitted.
Conclusion: ipfilter policy based routing does work on Solaris 10u7,
but, at least in my setup, not when redirection occurs to a 802.1q
tagging interface.
- Could somebody confirm this?
- Is this a known bug? (I didn't find anything relevant on sunsolve or
on the ipfilter mailing list)
Edited by: kleinstein on Oct 1, 2009 4:22 AM
Edited by: kleinstein on Oct 1, 2009 4:25 AM
Edited by: kleinstein on Oct 1, 2009 4:30 AM
Edited by: kleinstein on Oct 1, 2009 4:32 AM
Edited by: kleinstein on Oct 1, 2009 4:37 AM
Edited by: kleinstein on Oct 1, 2009 4:40 AM
Edited by: kleinstein on Oct 1, 2009 4:41 AM -
Multiple routing tables and/or policy routing
Hey all,
I'm trying to configure a Mac Mini (10.8) for multiple routing tables and policy routing. This server runs Ostinato, a freeware traffic generator. My purpose is to generate traffic on multiple VLANs towards different gateways and different destinations. To that end, I have VLAN tagged the (only) Ethernet port and configured 5 VLANs on it. The first one has the default route (I manage this Mac over this VLAN). The other four have IP addresses in the test range I'm using.
The goal is to have traffic sourced from IP-address-X go out vlanX towards gateway-X. It's counterpart on the far end runs Linux and I have configured it in this way:
ip route add default via <gateway-X> dev ethX table X
ip rule add from <network-X> table X priority X
Researching on OpenBSD forums (since it's the base of MacOS X), provided this:
route -T X add 0.0.0.0/0 -iface <gateway-X>
echo pass in from <network-X> to 0.0.0.0/0 rtable X | pfctl -mf -
However, the Mountain Lion "route" command does not support the -T option, so that killed that idea. Another forum suggested that this would have worked on 10.4:
ipfw add X fwd <gateway-X> ip from <IP-address-X> to any
I tried this on 10.8 though the man page says it's deprecated, and (surprise, surprise) it did not work.
Any ideas to get this working appreciated!
Thanks,
AaronStill doesn't have it in 10.9.4.
irene:~ cschwartz$ sudo bash
bash-3.2# route -T add
route: illegal option -- T
usage: route [-dnqtv] command [[modifiers] args]
I'm guessing you want policy-based routing due to VLANs...? If you can get a USB-to-Ethernet adapter, then maybe you can work around this by using multiple physical links instead of VLAN tagging. But if you need source-based routing etc. then no. -
Policy Routing - Unix and MS (Dare I ask?)
Guys,
Need to route out of a dual homed Unix and Windows box based on the source address or source interface as not to follow the default route.
ie, Packet arrives at host x on interface eth0 but the default route is out of eth1 so I get assemetric packet forwarding on the box.
I think ipfw is the way to policy route on unix, but anyone got a plan for windows?
Many thx indeed, and kind regards,
KenThe standard action, as performed by router software (such as Cisco IOS), is to select the next hop address and the output device. I will refer to this action as a "match & set" style of action. However, Linux takes a much more flexible approach. In Linux, there are several actions to choose from. The default action performs a route lookup from a specified destination-based routing table. The match & set action then becomes the simplest case of Linux route selection, which is realized when the specified destination-based routing table contains only a single default route. Linux supports multiple routing tables, containing multiple standard destination routes. Bear in mind that each of these routing tables is the same as the entire routing table for any other OS. Linux effectively provides 255 Ciscos to choose from. (For number freaks, Linux 2.2.12 supports 255 routing tables, 255 aggregate realms, and 232 (4294967296 decimal) policy rule priorities.
-
Local policy route-map for policy route
Hi
this is related my previous question:
I want to set policy route on asr1004, that redirect vpn traffic.
my case is:
asr1004 import a default route 0.0.0.0 from int 0 with bgp neibour address 10.100.100.100
assume internal traffic 10.10.10.0/24 coming into asr1004 on int 1.
assume vpn with ip address 10.2.2.2 is direct linked to asr1004 int 2, and int 2 ip address is 10.2.2.1
assume taget network is 10.200.200.0/24
I want internal traffic (10.10.10.0/24) go to target (10.200.200.0/24) to be redirect to10.2.2.2 (vpn) first, so I add "ip route 10.200.200.0/24 10.2.2.2" on asr1004.
Than, I want vpn (10.2.2.2) encrypt traffic and send it to one of ip in10.200.200.0/24 range again. at this point if I put local policy route-map below, is it will work?
ip local policy route-map vpn-out
access-list 100 permit ip 10.2.2.2 any
route-map vpn-out permit 10
match ip address 100
set ip next-hop 10.100.100.100
if not, do I have any change to do policy route for this case?
any comment will be appreciated
Thanks in advance
Julxuhi Jon
can I refresh the question again:
my case is:
asr1004 import a default route 0.0.0.0 from int 0 with bgp neibour address 10.100.100.100
assume internal traffic 10.10.0.0/16 coming into asr1004 on int 1 with ip address 10.3.3.3
assume vpn with ip address 10.10.2.2 is direct linked to asr1004 int 2, and int 2 ip address is 10.10.2.1
assume taget network is 10.200.200.0/24
I want internal traffic (10.10.0.0/16) go to target (10.200.200.0/24) to be redirect to10.10.2.2 (vpn) first, so I add "ip route 10.200.200.0/24 10.10.2.2" on asr1004.
Than, I want vpn (10.10.2.2) encrypt traffic and send it to one of ip in10.200.200.0/24 range again. at this point if I put local policy route-map below, is it will work?
ip local policy route-map vpn-out
access-list 100 permit ip 10.10.2.2 any
route-map vpn-out permit 10
match ip address 100
set ip next-hop 10.100.100.100
such as:
interface TenGigabitEthernet0/0/0
description bgp to get default
ip address 10.100.100.100 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
interface TenGigabitEthernet0/1/0
description get internaltraffic
ip address 10.3.3.3 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
interface GigabitEthernet0/2/1
description vpn
ip address 10.10.2.1 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
media-type rj45
negotiation auto
ip local policy route-map vpn-out
access-list 100 permit ip 10.10.2.2 any
route-map vpn-out permit 10
match ip address 100
set ip next-hop 10.100.100.100
ip route 10.200.200.0/24 10.10.2.2
Could you please advise if it is correct? -
Policy routing via address ranges
Is it possible to use policy routing based on ranges of a subnet? I want to have 192.168.1.1-100 go out e0 and 192.168.1.101-250 go out e1. From what I've read it only looks like policy routing works with route-maps using access lists
You certainly can.. just use multiple lines in your ACLs to cover each range.
For example,
192.168.1.1-100 can be covered by:
access-list 1 permit 192.168.1.0 0.0.0.63
access-list 1 permit 192.168.1.64 0.0.0.31
access-list 1 permit 192.168.1.96 0.0.0.3
access-list 1 permit 192.168.1.100 0.0.0.0
And use the following for everything else:
access-list 1 permit 192.168.1.0 0.0.0.255
So you can use the following:
route-map PBR permit 10
match ip address 1
set interface e0
route-map PBR permit 20
match ip address 2
set interface e1
Hope that helps - pls rate the post if it does.
Paresh -
Can't apply policy route-map on C3750 stack vlan interface
Hi All.
I've come up with this problem and i could see some people have had the same issue. I've tried to overlook and check other replies but it didn't help me. So I'm hoping someone could spot the problem. Here are the details:
2 x WS-C3750G-24T-E in stack
Cisco IOS Software, C3750 Software (C3750-ADVIPSERVICESK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2)
switch#sh sdm prefe
The current template is "desktop IPv4 and IPv6 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: 1.5K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 2.75K
number of directly-connected IPv4 hosts: 1.5K
number of indirect IPv4 routes: 1.25K
number of IPv6 multicast groups: 1.125k
number of directly-connected IPv6 addresses: 1.5K
number of indirect IPv6 unicast routes: 1.25K
number of IPv4 policy based routing aces: 0.25K
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 0.5K
number of IPv6 policy based routing aces: 0.25K
number of IPv6 qos aces: 0.5K
number of IPv6 security aces: 0.5K
There are 2 ISPs, G1/0/1 and G2/0/1. After creating a route-map i can apply a policy route-map to Vlan5 and it accepts without any errors. But when you do sh run vlan5 the command is not there, it's not applied.
Any help will be appretiated.
Thanks.Hi Jon.
Thanks for your reply. I didn't put those configs as they're basic without use of VRF and WCCP. Also i've checked or tried to find the list of unsupported commands and didn't see them in that list. See config below with some extras:
track 11 rtr 1 reachability
track 22 rtr 2 reachability
ip routing
no ip dhcp use vrf connected
interface GigabitEthernet1/0/1
description ISP1
no switchport
ip address 9.9.9.2 255.255.255.252
no ip proxy-arp
no ip mroute-cache
speed 100
duplex full
ipv6 address 2B01:4B8:0:3::2/64
ipv6 ospf 1 area 0
no mdix auto
no cdp enable
interface GigabitEthernet2/0/1
description ISP2
no switchport
ip address 9.9.9.5 255.255.255.252
ip ospf cost 10000
speed 1000
duplex full
ipv6 address 2B01:4B8:0:7::2/64
ipv6 enable
ipv6 ospf cost 10000
ipv6 ospf 1 area 0
interface Vlan5
description Company Ext Subnet
ip address 9.9.8.1 255.255.255.128
no ip proxy-arp
no ip mroute-cache
ipv6 address 2B01:4B8:1:22::1/64
ipv6 ospf 1 area 15
access-list 111 permit tcp any any eq www
route-map pbr1 permit 10
match ip address 111
set interface GigabitEthernet2/0/1 GigabitEthernet1/0/1
route-map pbr1 permit 20
set interface GigabitEthernet1/0/1 GigabitEthernet2/0/1
route-map pbr2 permit 10
match ip address 111
set ip next-hop verify-availability 9.9.9.6 1 track 11
set ip next-hop 9.9.9.1
route-map pbr2 permit 20
set ip next-hop verify-availability 9.9.9.1 1 track 22
set ip next-hop 9.9.9.6
I've tried to apply both policies pbr1 and pbr2, it allowed to do that without errors but at the end it wasn't there.
Cheers, -
IOS used: c3550-i5q3l2-mz.121-22.EA3.bin
I try to policy-route packets coming from a certain source (160.160.160.0/24)to a next-hop ip address:
route-map from_server permit 10
match ip address 160
set ip next-hop 192.168.1.1
access-list 160 permit ip 160.160.160.0 0.0.0.255 any
interface GigabitEthernet0/1
ip policy route-map from_server
The next-hop IP is in the routing table, nevertheless the packets matched with ACL 160 are not policy-routed.
What am I doing wrong? Any ideas?
Thanks a lot
FlorianYou probably need to do this to get PBR to work:
You must modify the SDM template to enable the switch to support the 144-bit Layer 3 TCAM. Use
the sdm prefer extended-match, sdm prefer access extended-match, or the sdm prefer routing
extended-match global configuration commands to reformat the TCAM space allocated to unicast
routing in the default, access, or routing template, respectively. Reformatting the unicast routing
TCAM reduces by half the number of supported unicast routes in the template.
This is from the configuration guide for the 3550. -
Can Policy Routing be configured on the RPR interface?
We have three 10720 routers connected via RPR ring. And we found the policy routing is not working, however the same config works on Ethernet interfaces.
Are you applying the config on the DPT interface or the Ethernet interface? I'd be suprised if you could configure any policy routing on the DPT interface. Rather I would have thought it should be applied on the Ethernet interfaces involved in the connection. Bear in mind that the router function of the 10720 does not really see the DPT ring, but as logical point to point links.
-
Hello,
We currently have our gateway / web filter routing setup in this manor:
lan --- 2921 ---asa(firewall) ---internet
|
------ web filter
So the traffic destined to the internet that is not supposed to be filtered goes right through the router to the asa. The traffice that is destined to be filtered gets policy routed to the web filter which then gets routed back to the 2921 and out to the asa. This is a bad design, I will admit that.
What I want to do is this:
lan - 2921 --- asa(firewall) --- internet
| |
--- web filter ---
With this change the traffic will not have to go back to the router and then back out to the asa. This will cut the traffic going through the router in half, which will result in lower cpu usage.
My question about changing this is as follows.
The asa has a route to the lan networks that are getting filtered. Lets say they are 172.16.0.0/16. The route comes from the lan which is advertiesed to the router which in turn is advertized to the asa. If I use a route-map to policy route certain networks to the web filter, will the return traffic go back through the web filter or will it go back directly to the router? I don'th have a spare ASA to test this with.
Thanks,
Dan.not possible.
If you want this behavior, you can achieve it by source nating on the next-hop all traffic going to the CSS. This will force the CSS to responds back to the nated ip address on the same interface.
Gilles. -
Hello,
Can i do policy routing only if a route it´s present?. My problem is that i want send some traffic to other router but if this router loose the internet conection my router continues send it this traffic and it´s droped
Regards.If all of the routers are connected via a common Ethernet segment you could run HSRP between the Internet router and the other router with the Internet router being the primary. Then you can policy route your traffic to the HSRP address. If you configure HSRP to track your internet connection and there is a failure, HSRP would fail over to the standby router. PBR would then be sending the traffic to the other router to meet your requirement.
-
Policy route on CSS11506 management interface?
can I setup policy route, so that, all the response traffic came from management interface will go out by it?
If so, please advice how to do it.
Any comments will be appreciated
Thanks in advancenot possible.
If you want this behavior, you can achieve it by source nating on the next-hop all traffic going to the CSS. This will force the CSS to responds back to the nated ip address on the same interface.
Gilles. -
Policy routing and black hole filtering on 6500
I have a 6500 with many SVIs configured and every one with multiple ip addresses. The users are accessing the network through these SVIs. For access control I use the black hole filtering method by dinamically injecting static routes to Null 0 for every user that is not authenticated.
But I need these users to reach one server to authenticate.
Is there a way to do this besides putting the server inside every VLAN ? Something like policy routing all the packets to the server to exit the server interface and the response packets to reach the user bypassing the global routing table ? Maybe using a vrf for the server only ?
Thanx.Dave Northampton UK here.
We seem to have different consumer laws to US it seems?
Here the RETAILER is wholly responsible for the goods he sells. If such a case as this arose there would be NO time limit of 15 days, if the goods were found not to be of "merchantable quality" the time factor would not matter, certainly up to a year!
Certainly a retailer can take matters up with their supplier/manfctr but the CUSTOMER must get a new, working product PDQ or a total refund..IN CASH or put on a card, no credit notes or any other such swaddling!
Of course! Many shops wriggle and tell people porkies but in the end that is da law!
Dave. -
Hi
I have a vpn box with only one ip address, assuming the ip address - public ip address, assuming it is a.a.a.a
if there is any possible, I can policy route using BGP to let vpn communication with internal with one route and vpn communication with external go to another route?
Any comments will be appreciated
Thanks in advance
JulxuHi,
you may find this reference useful that talks about inline vs named lists when it comes to RPL.
named lists are easier to edit and preferred when the lists are long, but inline sets are faster to process.
When stating faster, you should think in usec improvements.
One improvement I see is that you can change this:
route-policy client-in
if (as-path in aspath_Client) then
pass
elseif (as-path in aspath_Other) then
drop
endif
end-policy
to this:
route-policy client-in
if (as-path in aspath_Client) then
pass
else
drop
endif
end-policy
Considering the aspath other is a catch all it is a waste of cycles to invoke regex to make sure that it is matches any.
On the topic of using prefix sets vs AS paths there are probably different opinions about it.
If your client originates prefixes that are not theirs your policy still accepts them and will result in rogue routing and hijacking of prefixes.
So with that I would recomment using a prefix set to accept prefixes from my client, just to make sure that we accept legimate prefixes. You dont want to be the guy that sourced rogue prefixes because of a client misconfiguration.
regards
xander -
CRS, IOS-XR: local IGP route not installed in BGP table when learned from RR
Hello,
We use CRS routers in our IGP/BGP network core, some of which are acting as BGP originators and reflectors (RRs) for IPv4 unicast. We also use CRS routers as Internet PEs. The problem we have is between those PEs and the core routers.
Premise: each Internet PE is terminating customer cisrcuits and injects those downstream routes in IGP (via redistributing static, or just learned via IGP from a downstream router). The core (P) routers then learn those routes from the PE via the IGP. Two of the P-routers act as BGP originators and install the necessary routes in BGP using the network statement. These routes are mostly supernets (i.e. summarized), but some coincide with IGP routes, as learned from the PEs. The P-routers acting as RRs then reflect all iBGP routes to all IPv4 unicast BGP speakers in the network, including the Internet PEs (we also have BGP peers on those PEs, which is why this is necessary).
Problem: if a specific downstream route, learned on an Internet PE via IGP (i.e. from downstream), is then received by that PE from an RR via iBGP (i.e. from upstream), the route is not installed in the BGP table (the output of the show bgp x.x.x.x/xx command is: Network not in table)
Question: does anyone know why this is happening? This is concictent on all of our CRS PEs. As far as I am aware there is no BGP rule that would explain this behavior. We don't expect the PE to prefer the iBGP route over the IGP route, but that should not prevent it from learning it and installing it in the BGP table... The only discrepancy I could think of is that the IGP route has a next-hop pointing downstream, whereas the the same route, learned over iBGP has a next-hop pointing upstream. Then again,this shouldn't prevent the route to appear in the BGP table....
Your help would be appreciated!
Thanks!Hi !
If I am understandung you correctly then Split Horizon is the keyword
Because if the route is learned from downstream BGP drops any same path information learned from upstream
SPLIT-HORIZON only applies to distance-vector routing protocols. In case of BGP, it simply means that a prefix learned via a peer is not advertised back to that peer.
Split horizon will simply block out routes with the same neighbor as the next-hop for the router
regards
alexander
Maybe you are looking for
-
It's simple... I want the Illustrator pen tool to ALWAYS make corner annchor points and NEVER smooth. Right now I have to convert every single one of them, or I have to do a work around every time I draw a line and make one of the handles disappear.
-
Mouse clicks to hyperlinks instigate an error noise, and to recover your internet session, all you can do is re-start the PC - but also re-setting the router seems to clear the problem. Its not the individual PC, as my netbook which i connect through
-
Bridge is not to be found and cannot be loaded on my iMac
I have an Imac and loaded the new software from Apple, mountain Lion 10.8. After Iloaded Photoshop CS6 from the Cloud but cameraRAW did not work good. That is the begin and the end. Now Bridge is gone missing. I reloaded Photoshop several times and
-
[SOLVED] Some GTK apps look funny in XFCE
Hi again! Some of my apps like bluefish, cairo-dock settings, and others do not look uniform to the rest of the environment. The dropdown menus, checkboxes and the like get's ugly gray shadings around them. Is there a way to make it look uniform? Las
-
How do I create a new shopping cart in the SRM system (not portal)
Hi, I'm working on a test landscape with Purchase request WF. I want to create a new shopping cart from the SAP system, not from the portal, and this purchase request should go to a manager approval. I've been told that I need a SRM system. Could you