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

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

ACE: Multiple contexts odd behavior

Hi Guys,

Our production ACE environment consists of one Admin context and one virtual context for the load balanced services (VC-GREEN).  For test purposes I've setup in our lab another virtual context called VC-BLUE as below.  For simplicity I've kept the configs simple.

! Admin context

login timeout 60

hostname clay1-ace

boot system image:c6ace-t1k9-mz.A5_1_2.bin

resource-class RC-GREEN

  limit-resource all minimum 10.00 maximum unlimited

resource-class RC-BLUE

  limit-resource all minimum 10.00 maximum unlimited

access-list ALLOW line 8 extended permit ip any any

access-list ALLOWv6 line 8 extended permit icmpv6 anyv6 anyv6

access-list ALLOWv6 line 16 extended permit ip anyv6 anyv6

class-map type management match-any REMOTE_ACCESS

  description Remote access traffic match to ACE

  3 match protocol ssh any

  4 match protocol icmp any

  5 match protocol https any

  6 match protocol snmp any

class-map type management match-any REMOTE_ACCESSv6

  description Remote access traffic IPV6 match

  2 match protocol icmpv6 anyv6

policy-map type management first-match REMOTE_MGMT_ALLOW_POLICY

  class REMOTE_ACCESS

    permit

  class REMOTE_ACCESSv6

    permit

interface vlan 768

  description Management connectivity

  ipv6 enable

  ip address fdfd:eb1a:eb14:2800::2e/64 unique-local

  peer ip address fdfd:eb1a:eb14:2800::2f/64 unique-local

  ip address 172.20.40.46 255.255.255.0

  peer ip address 172.20.40.47 255.255.255.0

  service-policy input REMOTE_MGMT_ALLOW_POLICY

  no shutdown

context VC-GREEN

  allocate-interface vlan 11

  allocate-interface vlan 367

  member RC-GREEN

context VC-BLUE

  allocate-interface vlan 12

  allocate-interface vlan 300

  member RC-BLUE

ip route 0.0.0.0 0.0.0.0 172.20.40.254

ip route ::/0 fdfd:eb1a:eb14:2800::fffc

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Green Context

access-list ALLOW line 8 extended permit icmp any any

access-list ALLOW line 16 extended permit ip any any

access-list ALLOWv6 line 8 extended permit icmpv6 anyv6 anyv6

access-list ALLOWv6 line 16 extended permit ip anyv6 anyv6

interface vlan 11

  description Client side subnet

  ip address 10.194.11.228 255.255.255.0

  alias 10.194.11.232 255.255.255.0

  peer ip address 10.194.11.229 255.255.255.0

  access-group input ALLOW

  access-group input ALLOWv6

  access-group output ALLOW

  access-group output ALLOWv6

  no shut

interface vlan 367

description server side subnet

  ip address 10.194.13.228 255.255.255.248

  alias 10.194.13.230 255.255.255.248

  access-group input ALLOW

  access-group input ALLOWv6

  access-group output ALLOW

  access-group output ALLOWv6

  no shut

ip route 0.0.0.0 0.0.0.0 10.194.11.254

!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Blue Context

access-list ALLOW line 8 extended permit icmp any any

access-list ALLOW line 16 extended permit ip any any

access-list ALLOWv6 line 8 extended permit icmpv6 anyv6 anyv6

access-list ALLOWv6 line 16 extended permit ip anyv6 anyv6

interface vlan 12

  description Client side subnet

  ip address 10.194.12.228 255.255.255.0

  alias 10.194.12.232 255.255.255.0

  peer ip address 10.194.12.229 255.255.255.0

  access-group input ALLOW

  access-group input ALLOWv6

  access-group output ALLOW

  access-group output ALLOWv6

  no shut

interface vlan 300

description server side subnet

  ip address 10.194.13.61 255.255.255.192

  alias 10.194.13.62 255.255.255.192

  peer ip address 10.194.13.60 255.255.255.192

  access-group input ALLOW

  access-group input ALLOWv6

  access-group output ALLOW

  access-group output ALLOWv6

  no shut

ip route 0.0.0.0 0.0.0.0 10.194.12.254

!!!!!!!!!!!!!!!!!!!!!!!!!

! MSFC

On the MSFC

1) The vlans are added t the svclc vlan group  11,12,300,367,768

2) The Client side subnets VLAN11 and 12 are configured

3) Spanning tree configured for all vlans

4) Static routes in place for connectivity to the server side subnets

5) And all the standard routing good stuff....

What I find odd is that when I am on VC-BLUE:

a) I can ping VLAN300's interface address (10.194.13.61), however

b) I cannot ping the alias IP address (10.194.13.62)

c) From the MSFC I cannot ping the client side interface IP on VC-BLUE 10.194.12.228

d) As a real server on VLAN300 I cannot ping the gateway for VLAN300 at all.

Note I have no such issue for the VC-GREEN context.  In that:

a) I can ping VLAN367's interface address (10.194.13.228)

b) I can ping the alias IP address (10.194.13.230)

c) From the MSFC I can ping the client side interface IP on VC-GREEN 10.194.11.228

d) As a real server on VLAN367 I can ping the gateway for VLAN367

The arp table on the VC-BLUE context looks as follows:

Context VC-BLUE

================================================================================

IP ADDRESS      MAC-ADDRESS        Interface  Type      Encap  NextArp(s) Status

================================================================================

10.194.12.165   00.00.00.00.00.00  vlan12    LEARNED    -       * 3 req     dn

10.194.12.168   00.00.00.00.00.00  vlan12    LEARNED    -       * 3 req     dn

10.194.12.228   e0.5f.b9.a1.e9.d9  vlan12    INTERFACE  LOCAL     _         up

10.194.12.254   00.00.0c.07.ac.04  vlan12    GATEWAY    29     52 sec       up

10.194.13.61    e0.5f.b9.a1.e9.d9  vlan300   INTERFACE  LOCAL     _         up

================================================================================

Notice there is no entry for the VLAN300 gateway.  I'm trying to understand why this is the case, i.e. why I cannot ping the gateway for VLAN300 on the BLUE context itself.

I also notice the following oddities when comparing a subnet on the GREEN and BLUE contexts below.  Why would VLAN367 indicate "VLAN got assigned from the supervisor", whereas for VLAN300, this is not seen?

test-clay1-ace/VC-GREEN# sh int vlan 367

vlan367 is up, VLAN got assigned from the supervisor

  Hardware type is VLAN

  MAC address is e0:5f:b9:a1:e9:d9

  Virtual MAC address is 00:0b:fc:fe:1b:02

  Mode : routed

  IP address is 10.194.13.228 netmask is 255.255.255.248

  FT status is active

  Description:not set

  MTU: 1500 bytes

  Last cleared: never

  Last Changed: Wed Aug 22 03:22:09 2012

  No of transitions: 1

  Alias IP address is 10.194.13.230 netmask is 255.255.255.248

  Peer IP address is 10.194.13.229 Peer IP netmask is 255.255.255.248

  Assigned from the Supervisor, up on Supervisor

     4246 unicast packets input, 778669 bytes

     1656 multicast, 30 broadcast

     0 input errors, 0 unknown, 0 ignored, 0 unicast RPF drops

     2280 unicast packets output, 233742 bytes

     218 multicast, 19 broadcast

     0 output errors, 0 ignored

test-clay1-ace/VC-BLUE# sh int vlan 300

vlan300 is up, administratively up

  Hardware type is VLAN

  MAC address is e0:5f:b9:a1:e9:d9

  Mode : routed

  IP address is 10.194.13.61 netmask is 255.255.255.192

  FT status is non-redundant

  Description:CALLISTA Environment

  MTU: 1500 bytes

  Last cleared: never

  Last Changed: Wed Aug 22 05:51:23 2012

  No of transitions: 1

  Alias IP address is 10.194.13.62 netmask is 255.255.255.192

  Peer IP address is 10.194.13.60 Peer IP netmask is 255.255.255.192

  Assigned from the Supervisor, up on Supervisor

     9 unicast packets input, 8263 bytes

     102 multicast, 0 broadcast

     0 input errors, 0 unknown, 0 ignored, 0 unicast RPF drops

     0 unicast packets output, 256 bytes

     0 multicast, 4 broadcast

     0 output errors, 0 ignored

Note, I have no such issue on the original VC-GREEN context.  For each of the subnets on VC-GREEN, the real servers can ping their gateway etc.

Reading the cisco doco, setting up multiple virtual contexts seems fairly straighforward however the basic issue above leaves things a little unexpected?

Let me know if you have any questions.

thanks

Sheldon

Everyone's tags (3)
5 REPLIES
New Member

ACE: Multiple contexts odd behavior

Hi There,

Further to my above post I also wanted to confim whether inter-context communication, i.e. servers on VLANs on either contexts to VIPs on the other context will work?  Note here that there are no shared client side VLANs between contexts.  And if for example we chose to share the Client side VLAN, will inter-context communication work?

thanks

Sheldon

New Member

ACE: Multiple contexts odd behavior

Hi sgonsalv,

Can you provide a "show run | inc svclc" from MSFC?

Plinio

New Member

ACE: Multiple contexts odd behavior

Hi Plinio,

Here is the output from

show run | inc svclc

svclc module 1 vlan-group 1

svclc vlan-group 1  11,121,123,137,167,171,172,176,179,186,187,257,259,273,300

svclc vlan-group 1  301,306,307,311,314-316,318,319,326,350,366,367,386,488

svclc vlan-group 1  768

New Member

ACE: Multiple contexts odd behavior

Hi sgonsalv,

Please configure this:

svclc vlan-group 1  12

If you verify, the vlan 12 isn't associated to vlan-group 1.

I think that this will solve your problem.

P.S: If this is the correct answer, please rate and mark correct.

New Member

ACE: Multiple contexts odd behavior

Hi sgonsalv,

Good news? Did you try the configuration?

622
Views
0
Helpful
5
Replies
CreatePlease to create content