Mike, I'm not sure if I understand your question correctly, but to be able
to see TACACS settings in ACS Interface configuration section, you have
to have at least one network device added as a TACACS+ AAA Client (in
Network Configuration).
Marta Sokolowska.
2012/3/6 Mike Rojas
I can see this topic only under 12.4 Mainline documentation - I cannot
find it in 12.4T. Anyway, the path is written below:
http://www.cisco.com/cisco/web/psa/default.html?mode=prod
Products
Cisco IOS and NX-OS Software
Cisco IOS
Cisco IOS Software Release 12.4 Family
*Cisco IOS Software
The native support for IP multicast by IPSEC would be:
the IP header (outer and the only one) with IP multicast
destination address, and the payload protected by IPSEC.
IPSEC cannot do this in cisco implementation. Period.
All that VTI does is encapsulating mcast in IP unicast,
and replicating it
No, that is perfect, we are all learning! (at least I am). That makes
sense. So a true native IP multicast with IPSEC would by your
definition HAVE to run in transport mode with a stack looking somewhat
like this: [IP][ESP][L4][DATA][ESP Trail] whereby the IP header has a
destination multicast
Yes, exactly.
While IP multicast implementation with cisco IPSEC VTI (end to end) is
possible, it requires that each IP multicast router on the SPT path
performs decryption/encryption of each packet it has to forward.
On 6 March 2012 15:44, Joe Astorino
I have one more question for you Peter if you don't mind. How would
this differ from a plain old fashioned crypto map whereby we are
running ESP in tunnel mode with a proxy ACL configured as permit ip
any any. From an IP stack perspective this and the VTI
implementation look the same, but we
We were able to protect IP multicast with good old IPSEC cryptomaps
when applying them to GRE tunnels. Functionally, there's no
difference with the newer VTI. For GRE tunneled traffic you
said permit all gre in your crypto, and then the traffic to protect
was chosen according to IP routing tables
Yes, you guessed right that was what I was ultimately getting at.
That makes sense. Rock on, thanks Peter.
On Tue, Mar 6, 2012 at 11:47 AM, Peter Debye pde...@gmail.com wrote:
We were able to protect IP multicast with good old IPSEC cryptomaps
when applying them to GRE tunnels. Functionally,
Hi Martha,
Yeah, Basically the tacacs settings where there is a box to check Exec and then
add the value for privilege level, I am only able to see that at the group
level, not under User. On the ACS at work (when I do most of my labs) I can see
it under each user.
On the interface
If you have permit ip any any, crypto maps will encrypt multicast
and I have confirmed it with wireshark using AH.
Here, we are talking about two things - Multicast in the payload and
Multicast in the IPsec IP header.
Multicast in the IPsec IP header has not been addressed in the rfcs.
Are we
As we know, ISAKMP SA's are bi-directional and run over UDP port 500
by default, but IPSEC SA's are unidirectional -- We must have one in
each direction. Say we have a topology like this where R1 wants to
make an IPSEC tunnel to R2 through an ASA
R1 --- ASA --- R2
R1 is on the inside where R2
I was talking about multicast as a destination IP address in the
original IP header.
On Wed, Mar 7, 2012 at 1:03 AM, Kingsley Charles
kingsley.char...@gmail.com wrote:
If you have permit ip any any, crypto maps will encrypt multicast
and I have confirmed it with wireshark using AH.
Here, we
I am pretty sure debug crypto isakmp just confirmed my thought, but
I welcome any other discussion!
On Wed, Mar 7, 2012 at 1:15 AM, Joe Astorino joeastorino1...@gmail.com wrote:
As we know, ISAKMP SA's are bi-directional and run over UDP port 500
by default, but IPSEC SA's are unidirectional --
13 matches
Mail list logo
