Fwd: (RADIATOR) cisco-avpair for a route-map ?

Mon Feb 4 18:09:18 CST 2008

Hello Kurt -

Thanks to Matthew Nichols from Cisco for the following.

regards

Hugh

Begin forwarded message:

> From: Matthew Nichols <nicholsm at cisco.com>
> Date: 5 February 2008 10:10:53 GMT+11:00
> To: Hugh Irvine <hugh at open.com.au>
> Subject: Re: (RADIATOR) cisco-avpair for a route-map ?
>
> I have
>
> I replied to the list, but I don't think it came through:
>
> Here is what I sent:
>
>
> Kurt,
>
> This can be done by adding a reply attribute to the user:
>
> "cisco-avpair = "lcp:interface-config=ip policy route-map mymap"
>
> as you stated in the email. You should probably allow virtual- 
> profiles and use a virtual-template to make sure the access is  
> virtualized.
>
> I used to use this configuration many years ago when I worked for a  
> service provider where we used to enforce PBR for transparent proxy  
> as well as other features, and works quite well. You can use this  
> as a per-user attribute reply or use AddToReply directive in the  
> config for a Realm/Handler.
>
> Thanks,
>
> Matt
>
>
> Thanks Hugh,
>
> Matt
>
>
> On 04/02/2008, at 2:33 PM, Hugh Irvine wrote:
>
>>
>> Hello Kurt -
>>
>> I think you are going to have to do some lab testing to see if/how  
>> you can get this to work.
>>
>> It really depends on whether the Cisco accepts a cisco-avpair to  
>> do this (or not).
>>
>> Has anyone on the list got any operational experience with this?
>>
>> regards
>>
>> Hugh
>>
>>
>> On 5 Feb 2008, at 09:08, Kurt Jaeger wrote:
>>
>>> Dear radiator community,
>>>
>>> I have a question on adding a "ip policy route-map mymap" to
>>> a vpdn-generated interface using cisco-avpair radius attributes.
>>>
>>> First, why do I want to do this:
>>>
>>> Given the following fallback scenario:
>>>
>>> - customer has a fixed line (normal case), terminating on ourrouter1
>>> - customer has a dsl line (fallback case), terminating on  
>>> otherrouter2
>>> - we have a tunnel from otherrouter2 to ourrouter1.
>>>
>>> otherrouter2 is located somewhere else (not inside our AS).
>>>
>>> If customer runs on fallback, we receive traffic from the internet
>>> to the customer and send it over the tunnel to otherrouter2.
>>>
>>> What happens to traffic sent from customer ? Normal case:
>>> He sends it to otherrouter2, which sends it out his default route.
>>>
>>> What we therefore need is the return traffic coming in from the  
>>> fallback
>>> to go into our tunnel, so that we can handle both directions  
>>> properly.
>>>
>>> Second, how can this be done ?
>>>
>>> http://www.cisco.com/univercd/cc/td/doc/product/software/ 
>>> ios122/122cgcr/fqos_c/fqcprt1/qcfpbr.htm
>>>
>>> says that we should define a route-map like this:
>>>
>>> --------------
>>> access-list 11 permit 205.206.207.0 0.0.0.255
>>>
>>> route-map mymap permit 10
>>>  match ip address 11
>>>  set ip next-hop <mytunnelendpoint>
>>> --------------
>>>
>>> For this, I want to assign a
>>>
>>>  ip policy route-map mymap
>>>
>>> to the fallback dsl session.
>>>
>>> Would adding a
>>>
>>> 	Cisco-AVPair = "lcp:interface-config=ip policy route-map mymap"
>>>
>>> work ? Has anyone ever tried this ? Is there some other way to do
>>> this ?
>>>
>>> Thanks for any pointer.
>>>
>>> -- 
>>> pi at opsec.eu            +49 171 3101372                        12  
>>> years to go !
>>>
>>> --
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>
>>
>>
>> NB:
>>
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/ 
>> archives/radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page
>>
>> -- 
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
>> Includes support for reliable RADIUS transport (RadSec),
>> and DIAMETER translation agent.
>> -
>> Nets: internetwork inventory and management - graphical, extensible,
>> flexible with hardware, software, platform and database independence.
>> -
>> CATool: Private Certificate Authority for Unix and Unix-like systems.
>>
>>
>> --
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.

NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.