[CISCO ACI] Inter tenant contract

The ACI configuration for inter tenant contract is complicated.

A contract provides two functions:

  1. Provide filter.
  2. Provide route leak.

A tenant is considered a VRF itself. In this example there are two tenants T05 and T06.

T05 exports the contract to T06, and T05 provide the contract. T06 consumed the contract exported by T06.

tenant to tenant contract4

Shared my bridge domain subnet.

tenant to tenant contract1

Export the contract. The contract created has a GLOBAL scope.

tenant to tenant contract2

Give a meaningful name of this export, because the target tenant can only see the name of the contract. Choose the GLOBAL scope contract which is ICMP-GLOBAL. Choose the target Tenant which is T06.

tenant to tenant contract3

Provide the ICMP-GLOBAL contract in EPG which you want to route leak to another tenant.

T06 will need to consume the contract exported from T05. T06 also follows the same steps as above. Now T05 will need to consume the exported contract from T06.

tenant to tenant contract5

On T05 tenant, select Application Profile > EPG > Contracts and right click to choose Add Consumed Contract Interface.

tenant to tenant contract6

Now T05 and T06 can ping to each other.

There is a common tenant which is a built-in in APIC, common tenant to another tenant communication does not need to do export, common tenant’s contract is visible by all tenants, but a contract created by a tenant is only visible by its own creator. Which is why tenant T05 need to export the contract to T06, and T06 did vice versa.

 

 

Posted in General stuffs, Software Defined Network | Tagged , | Leave a comment

[CISCO ACI] Same VRF contract

I have an EPG Web and an EPG DB, I have provided a contract in EPG web and consumed contract in EPG DB. The results are:

DB server can ping to Web server, and Web server can ping to DB server. How is this possible?

See the below screenshots. EPG Web provided the icmp contract, and EPG DB consumed the icmp contract.

contracts2

EPG Web provided the contract

contracts3

EPG db consumed the contract

The above is achieved due to these condition:

  1. The EPGs are under one VRF. No route leaking is required.
  2. The contracts have these defaults: Apply Both Directions and Reverse Filter Ports.

contracts1

Posted in Software Defined Network | Tagged , , | Leave a comment

bigip snat automap

You created a forwarder virtual server for your servers behind the bigip appliance to access the internet, your server could not get a respond back. You troubleshoot the problem and found that:

  1. Default route is configured in the bigip.
  2. You cannot ping the next hop gateway specified in the default route.
  3. You could not determine if this is the cause of routing because the next hop router is not in your governance.

To troubleshoot the problem you can try using SNAT automap. SNAT automap will translate the address in this sequence:

  1. floating self ip of the egress vlan.
  2. floating self ip of a different vlan.
  3. non-floating self ip of an egress vlan.
  4. non-floating selfip of a different vlan.

snat-automap.png

After you have turned on the SNAT automap your server is able to get external updates

apt-get1.png

Now you can conclude that it is highly possible that the next hop router does not have a route back to your server.

snat1

what this means is that your server’s traffic is being translated into the floating self ip address of vlan internet, and the firewall thought that the incoming request is from a directly connected route.

 

 

Posted in F5, General stuffs | Tagged | Leave a comment

Is bigip packet filter stateful or stateless?

Packet filter
I have allowed vmnet5 to http and dns to any destination, and drop all for the rest.

pf1.png

Nmap from client

nmap.png

Actually nmap could not determine whether port 80 is opened or closed because there is no response.

Packet filter log

pf2

Looks like the packet filter accept despite TCP FIN was sent…

The below tcpdump proves that TCP FIN was sent over.

tcpdump1.png

So based on the packet filter log I should conclude that packet filter is a stateless access control?

Posted in General stuffs | Leave a comment

Upgrade bigip image in active/standby HA

Import the latest iso to both the active and standby bigip

import1import2

Install latest iso on standby bigip

install1.png

On command line:

[root@bigip2:Standby:In Sync] config # tmsh
root@(bigip2)(cfg-sync In Sync)(Standby)(/Common)(tmos)# /sys software image
root@(bigip2)(cfg-sync In Sync)(Standby)(/Common)(tmos.sys.software.image)# install BIGIP-12.1.0.0.0.1434.iso volume HD1.1

HD1.1 currently has the base version 12 image, we will want to overwrite this.

progress.png

Activate the new image on the standby bigip

activate1.png

After the standby unit has finished rebooted the configsync status will be disconnected. This means latest configuration cannot be sync over to the standby unit. This is caused by version mismatch.

The active bigip will still be accepting traffic, failover to the standby unit is still possible. Hence after the active bigip finished installation, do a failover to the standby unit.

root@(bigip1)(cfg-sync Disconnected)(Active)(/Common)(tmos)# run /sys failover standby

Install the latest image on the active unit

The installation process is the same when upgrading the standby unit. The active bigip will still accept traffic hence till now there should be no disruption to the clients.

install2.png

When finished installation, make this unit a standby bigip by issuing the command in tmsh.


root@(bigip1)(cfg-sync Disconnected)(Active)(/Common)(tmos)# run /sys failover standby

The failover should be transparent to the client, traffic will still be processed on the newly active bigip the state should also be failed over.

install3

Activate the latest image.

Config sync device to group

Do a config sync and overwrite the config after the standby has finished reboot.

sync the configsync the config 2

Client’s impact

client

0% packet loss while doing the upgrade and failover

 

Posted in F5, General stuffs, High Availability | Tagged , | Leave a comment

bigip tcpdump

Capture inbound and outbound from an interface


[root@bigip1:Active:In Sync] config # tcpdump -nni 1.1

This command disables ip address and port resolution and from interface 1.1.

Capture inbound and outbound and filter by address and port


[root@bigip1:Active:In Sync] config # tcpdump host 172.16.5.254 and port 80 -nnvvi 1.1

This command filter the host by 172.16.5.254 and filter port 80. Verbose is used in this command.

Capture outbound and filter by ip address and port


[root@bigip1:Active:In Sync] config # tcpdump src host 172.16.5.254 and dst port 80 -nnvvi 1.1 -w /var/tmp/vmnet5.cap

This command writes the result to /var/tmp/vmnet5.cap, and filter outbound traffic from 172.16.5.254 to port 80

Read the vmnet5.cap


[root@bigip1:Active:In Sync] config # tcpdump -r /var/tmp/vmnet5.cap -X

-X is used to present the data in ascii format.

The sample is like this:

20:35:13.406570 IP 172.16.5.254.47300 > 172.16.3.254.http: Flags [P.], seq 0:435, ack 1, win 229, options [nop,nop,TS val 29089249 ecr 11663189], length 435 in slot1/tmm0 lis=/Common/dvwa
0x0000: 0005 0800 4500 01e7 f16e 4000 4006 e585 ....E....n@.@...
0x0010: ac10 05fe ac10 03fe b8c4 0050 4607 2c8d ...........PF.,.
0x0020: e307 7839 8018 00e5 cc72 0000 0101 080a ..x9.....r......
0x0030: 01bb dde1 00b1 f755 4745 5420 2f64 7677 .......UGET./dvw
0x0040: 612f 696e 7374 7275 6374 696f 6e73 2e70 a/instructions.p
0x0050: 6870 2048 5454 502f 312e 310d 0a48 6f73 hp.HTTP/1.1..Hos
0x0060: 743a 2031 3732 2e31 362e 332e 3235 340d t:.172.16.3.254.
0x0070: 0a55 7365 722d 4167 656e 743a 204d 6f7a .User-Agent:.Moz
0x0080: 696c 6c61 2f35 2e30 2028 5831 313b 2055 illa/5.0.(X11;.U
0x0090: 6275 6e74 753b 204c 696e 7578 2078 3836 buntu;.Linux.x86
0x00a0: 5f36 343b 2072 763a 3436 2e30 2920 4765 _64;.rv:46.0).Ge
0x00b0: 636b 6f2f 3230 3130 3031 3031 2046 6972 cko/20100101.Fir
0x00c0: 6566 6f78 2f34 362e 300d 0a41 6363 6570 efox/46.0..Accep
0x00d0: 743a 2074 6578 742f 6874 6d6c 2c61 7070 t:.text/html,app
0x00e0: 6c69 6361 7469 6f6e 2f78 6874 6d6c 2b78 lication/xhtml+x
0x00f0: 6d6c 2c61 7070 6c69 6361 7469 6f6e 2f78 ml,application/x
0x0100: 6d6c 3b71 3d30 2e39 2c2a 2f2a 3b71 3d30 ml;q=0.9,*/*;q=0
0x0110: 2e38 0d0a 4163 6365 7074 2d4c 616e 6775 .8..Accept-Langu
0x0120: 6167 653a 2065 6e2d 5553 2c65 6e3b 713d age:.en-US,en;q=
0x0130: 302e 350d 0a41 6363 6570 742d 456e 636f 0.5..Accept-Enco
0x0140: 6469 6e67 3a20 677a 6970 2c20 6465 666c ding:.gzip,.defl
0x0150: 6174 650d 0a52 6566 6572 6572 3a20 6874 ate..Referer:.ht
0x0160: 7470 3a2f 2f31 3732 2e31 362e 332e 3235 tp://172.16.3.25
0x0170: 342f 6476 7761 2f76 756c 6e65 7261 6269 4/dvwa/vulnerabi
0x0180: 6c69 7469 6573 2f65 7865 632f 0d0a 436f lities/exec/..Co
0x0190: 6f6b 6965 3a20 7365 6375 7269 7479 3d69 okie:.security=i
0x01a0: 6d70 6f73 7369 626c 653b 2050 4850 5345 mpossible;.PHPSE
0x01b0: 5353 4944 3d33 7270 376a 3468 3866 3665 SSID=3rp7j4h8f6e
0x01c0: 6872 6c6c 3262 6831 646e 6f73 706c 300d hrll2bh1dnospl0.
0x01d0: 0a43 6f6e 6e65 6374 696f 6e3a 206b 6565 .Connection:.kee
0x01e0: 702d 616c 6976 650d 0a0d 0a01 1101 0100 p-alive.........
0x01f0: 000c 2f43 6f6d 6d6f 6e2f 6476 7761 ../Common/dvwa

Posted in F5, General stuffs, Security | Tagged , , | Leave a comment

BIGIP virtual server status

Virtual server is enabled but is unavailable

vs1

Although the virtual server is enabled, is unavailable. This is because a pool member has reached its connection limit.

vs-pools

In this scenario two virtual servers were marked down by health monitor, and the only available virtual server has reached its connection limit.

vs2.png

Virtual server is enabled and ready to receive traffic

vs3.png

This is the business as usual status of a virtual server.

Virtual server is enabled but offline

vs4.png

The virtual server is enabled but is marked offline, the virtual server will not receive any incoming traffic. This indicate pool members might be down which caused the virtual server to be offline.

vs5

In this scenario, the http services were down for all pool members.

vs6.png

In this scenario the pool members are all been forced offline; which caused the virtual server to be offline as well.

vs7

Interestingly if all pool members are disabled the pool will still indicate as enabled, hence caused virtual server to indicate as enabled as well.

vs3.png

vs8

If there is already a persistence to a server traffic will still be sent to the pool member even if it has been disabled.

Virtual server is available but disabled

vs9.png

This happens when you disabled the virtual server, when virtual server is disabled no incoming traffic will be received.

Virtual server status is unknown

vs10

Bigip cannot determine the status of the virtual server because there is no health monitor configured for a node or a pool member.

 

 

Posted in F5, General stuffs, High Availability | Tagged , , | Leave a comment