RHEL/Rocky Linux create root CA server

 

Introduction

This document describes the configuring Custom CA on RHEL/Rocky Linux system.

 

Prerequisites

 

Requirements

recommends that you have knowledge of these topics:

• Digital signatures and digital certificates
• Certificate issuance process by Certificate Authority (CA) organization

Components Used

The information in this document is based on these software and hardware versions:

• Red Hat Enterprise Linux 9.3 (Plow)
• openssl.x86_64                 1:3.0.7-24.el9 

Configuration

Step 1. Create Folder

[root@ns1 pki]#  mkdir -p /etc/pki/CA/private

Step 2. Create private key

[root@ns1 CA]# openssl genrsa -aes256 -out /etc/pki/CA/private/cakey.pem 2048

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

[root@ns1 CA]# 

Step 3. Create root CA certificate

[root@ns1 CA]#  openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/CA/cacert.pem -days 3660

Enter pass phrase for /etc/pki/CA/private/cakey.pem:

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [XX]:US

State or Province Name (full name) []:California

Locality Name (eg, city) [Default City]:San Francisco

Organization Name (eg, company) [Default Company Ltd]:google Systems, Inc.

Organizational Unit Name (eg, section) []:Technical Assistance Center          

Common Name (eg, your name or your server's hostname) []:ca.gc.google.com

Email Address []:

[root@ns1 CA]# 

[root@ns1 CA]# ls

cacert.pem  private

[root@ns1 CA]# 

Step 4. Create index and serial

[root@ns1 CA]# touch /etc/pki/CA/index.txt

[root@ns1 CA]# echo 01 > /etc/pki/CA/serial

[root@ns1 CA]# mkdir  /etc/pki/CA/newcerts

[root@ns1 CA]# echo 01 > /etc/pki/CA/crlnumber

Step 5. Modify openssl config

[root@ns1 CA]# vim /etc/pki/tls/openssl.cnf

#policy          = policy_match

policy          = policy_anything

Step 6. add ext file

[root@localhost ~]# cat https.ext 

subjectAltName=@SubjectAlternativeName

[ SubjectAlternativeName ]

DNS.1 = dlc-aci06-apic1.google.com

DNS.2 = dlc-aci06-apic2.google.com

DNS.3 = dlc-aci06-apic3.google.com

[root@localhost ~]# 

step 7. Certificate issuance process 

[root@localhost ~]# 

[root@ns1 ~]# openssl ca -in test.csr -out test.crt -ext https.ext

Using configuration from /etc/pki/tls/openssl.cnf

Enter pass phrase for /etc/pki/CA/private/cakey.pem:

Check that the request matches the signature

Signature ok

Certificate Details:

        Serial Number: 1 (0x1)

        Validity

            Not Before: Mar  7 08:30:04 2024 GMT

            Not After : Mar  7 08:30:04 2025 GMT

        Subject:

            countryName               = US

            stateOrProvinceName       = CA

            organizationName          = google Team

            organizationalUnitName    = TAC

            commonName                = dlc-aci06-apic1.google.com

        X509v3 extensions:

            X509v3 Basic Constraints: 

                CA:FALSE

            X509v3 Subject Key Identifier: 

                79:5B:DD:03:BA:B1:D3:DC:DE:A5:CC:2C:1E:97:9C:D4:B4:03:7F:80

            X509v3 Authority Key Identifier: 

                51:C7:28:92:57:8E:81:4A:81:04:6E:84:33:2A:81:95:06:B0:0A:83

Certificate is to be certified until Mar  7 08:30:04 2025 GMT (365 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

[root@ns1 ~]# 

setp8: 

[root@ns1 ~]# openssl ca -revoke test.crt 

Using configuration from /etc/pki/tls/openssl.cnf

Enter pass phrase for /etc/pki/CA/private/cakey.pem:

Revoking Certificate 01.

Data Base Updated

[root@ns1 ~]# 

setp 9:

[root@ns1 ~]# cat /etc/pki/CA/index.txt

R       250307083004Z   240307083510Z   01      unknown /C=US/ST=CA/O=Cisco ACI Team/OU=TAC/CN=dlc-aci06-apic1.cisco.com

[root@ns1 ~]# 

[root@ns1 ~]# openssl ca -gencrl -out /etc/pki/CA/crl.pem

Using configuration from /etc/pki/tls/openssl.cnf

Enter pass phrase for /etc/pki/CA/private/cakey.pem:     

[root@ns1 ~]# openssl crl -in /etc/pki/CA/crl.pem -noout -text

Certificate Revocation List (CRL):

        Version 2 (0x1)

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: C = US, ST = California, L = San Francisco, O = "Cisco Systems, Inc.", OU = Technical Assistance Center, CN = ca.gc.cisco.com

        Last Update: Mar  7 08:36:58 2024 GMT

        Next Update: Apr  6 08:36:58 2024 GMT

        CRL extensions:

            X509v3 CRL Number: 

                1

Revoked Certificates:

    Serial Number: 01

        Revocation Date: Mar  7 08:35:10 2024 GMT

    Signature Algorithm: sha256WithRSAEncryption

    Signature Value:

        36:8c:3c:e1:78:c9:57:17:40:bf:e9:3a:9d:2a:5b:2b:e2:6a:

        9d:e9:0a:7e:3a:47:22:45:4d:01:70:44:ca:56:c5:f5:14:f6:

        c3:67:33:ab:ab:e9:80:e4:0d:59:cd:1c:bb:d6:ef:a5:10:79:

        04:2b:10:43:db:cf:c4:8e:b8:38:56:09:29:c4:3b:17:bc:99:

        4b:a6:ad:1a:4d:d3:7b:1f:7e:57:79:a0:fc:c5:bb:11:01:b2:

        89:70:37:21:31:57:1a:95:a8:6f:ec:83:d0:f9:4a:b6:4b:c6:

        68:81:7e:a1:7a:f5:0e:e7:69:04:04:3e:86:40:75:28:be:71:

        39:08:95:e0:5b:2a:80:20:3b:30:ba:cf:5e:0c:0d:9c:31:22:

        88:31:56:94:a7:44:c2:91:cc:ec:3e:24:3b:e1:0f:12:1d:f7:

        d5:b8:e3:83:ce:13:54:9c:f0:45:8f:c8:b7:9e:f8:e1:73:f4:

        b2:ff:87:cf:39:3e:b9:2f:48:09:a2:d6:c8:76:3d:2b:20:bc:

        15:1f:2c:52:07:41:5b:44:34:d2:b5:e0:aa:17:46:c3:a8:34:

        8f:be:78:05:c1:ef:ee:d3:b6:92:df:bb:dd:25:95:d1:c3:91:

        18:78:e0:55:ae:62:ab:c2:45:d7:29:a0:38:9b:90:0e:63:c5:

        19:24:f2:83

[root@ns1 ~]# 

vim字符串替换及小技巧

 

字符串替换

vi/vim 中可以使用 :s 命令来替换字符串。以前只会使用一种格式来全文替换，今天发现该命令有很多种写法(vi 真是强大啊，还有很多需要学习)，记录几种在此，方便以后查询。

　　:s/vivian/sky/ 替换当前行第一个 vivian 为 sky

　　:s/vivian/sky/g 替换当前行所有 vivian 为 sky

　　:n,$s/vivian/sky/ 替换第 n 行开始到最后一行中每一行的第一个 vivian 为 sky

　　:n,$s/vivian/sky/g 替换第 n 行开始到最后一行中每一行所有 vivian 为 sky

　　n 为数字，若 n 为 .，表示从当前行开始到最后一行

　　:%s/vivian/sky/(等同于 :g/vivian/s//sky/) 替换每一行的第一个 vivian 为 sky

　　:%s/vivian/sky/g(等同于 :g/vivian/s//sky/g) 替换每一行中所有 vivian 为 sky

　　可以使用 # 作为分隔符，此时中间出现的 / 不会作为分隔符

　　:s#vivian/#sky/# 替换当前行第一个 vivian/ 为 sky/

　　:%s+/oradata/apras/+/user01/apras1+ (使用+ 来 替换 / )： /oradata/apras/替换成/user01/apras1/

　　* ************************************

　　1.:s/vivian/sky/ 替换当前行第一个 vivian 为 sky

　　:s/vivian/sky/g 替换当前行所有 vivian 为 sky

　　2. :n,$s/vivian/sky/ 替换第 n 行开始到最后一行中每一行的第一个 vivian 为 sky

　　:n,$s/vivian/sky/g 替换第 n 行开始到最后一行中每一行所有 vivian 为 sky

　　(n 为数字，若 n 为 .，表示从当前行开始到最后一行)

　　3. :%s/vivian/sky/(等同于 :g/vivian/s//sky/) 替换每一行的第一个 vivian 为 sky

　　:%s/vivian/sky/g(等同于 :g/vivian/s//sky/g) 替换每一行中所有 vivian 为 sky

　　4. 可以使用 # 作为分隔符，此时中间出现的 / 不会作为分隔符

　　:s#vivian/#sky/# 替换当前行第一个 vivian/ 为 sky/

　　5. 删除文本中的^M

　　问题描述：对于换行,window下用回车换行(0A0D)来表示，linux下是回车(0A)来表示。这样，将window上的文件拷到unix上用时，总会有个^M.请写个用在unix下的过滤windows文件的换行符(0D)的shell或c程序。

　　· 使用命令：cat filename1 | tr -d “^VM” >newfile;

　　· 使用命令：sed -e “s/^VM//” filename >outputfilename。需要注意的是在1、2两种方法中，^V和M指的是Ctrl+V和Ctrl+M。你必须要手工进行输入，而不是粘贴。

　　· 在vi中处理：首先使用vi打开文件，然后按ESC键，接着输入命令：%s/^VM//。

　　· :%s/^M$//g

　　如果上述方法无用，则正确的解决办法是：

　　· tr -d "r" <src >dest

　　· tr -d "5" dest

　　· strings A>B

　　6. 其它

　　利用 :s 命令可以实现字符串的替换。具体的用法包括：

　　:s/str1/str2/ 用字符串 str2 替换行中首次出现的字符串 str1

　　:s/str1/str2/g 用字符串 str2 替换行中所有出现的字符串 str1

　　:.,$ s/str1/str2/g 用字符串 str2 替换正文当前行到末尾所有出现的字符串 str1

　　:1,$ s/str1/str2/g 用字符串 str2 替换正文中所有出现的字符串 str1

　　:g/str1/s//str2/g 功能同上

　　从上述替换命令可以看到：g 放在命令末尾，表示对搜索字符串的每次出现进行替换;不加 g，表示只对搜索

　　字符串的首次出现进行替换;g 放在命令开头，表示对正文中所有包含搜索字符串的行进行替换操作。

前几天我记录一下如何在vim中替换文字。只是很简单的给出了两个命令。其实还只是初级功能，今天来看看稍微复杂一点的。 用:%s/from/to 命令只替换每行的第一个匹配字符，如果要替换每行的所有匹配项，需要在后面加上g命令。如： :%s/from/to/g

另外，我们往往在替换的时候需要很小心，不能够这样就全部替换了，需要我们一个个的确认，那么我们可以加上c命令，意思就是confirm。如： :%s/from/to/gc 输入这个命令之后，vim会把所有匹配的文字高亮，并会询问你 replace with to (y/n/a/q/l/^E/^Y) ,输入y表示替换当前这个，n表示这个不要替换，a表示全部替换，q表示退出，不替换了，l表示把当前这个替换后就退出，^E(ctrl+e,好像大小写都可以)表示向下滚动一行，^Y表示向上滚动一行.

上次我们说了可以在s前面加上范围,比如:1,5s/from/to表示替换1到5行的from,在vim中有些字符可以很方便的表示一些特殊行,比如.表示当前行,\(表示最后一行,第一行当然就是1了.所以我们可以用:.s/from/to命令替换当前行的from,用:.,\)s/from/to替换从当前行到结束行的每行的第一个匹配的from.

好了现在对于vim的文字替换功能有了更一步的了解了.其实这样的替换还是最简单的,并且很容易出错,因为它并不会断词,会把fromxxx也当成匹配项,这当然是错误的,我们可以加上\<来表示匹配一个单词的开始,\>来表示单词的结束, 命令看起来就像这个样子:%s/\<from\>/to/g

:%s/\r//g 清除那个^M

linux使用grep或者vim删除空行

grep -v ^$ oldfile > newfile 但是似乎在FreeBSD下面不行，会不会是grep版本的问题? 后来想到了很刁的vim的全局替换，最后成功

vim的命令为：%s/^\n//g 意思是全局替换所有以回车开头的字符，替换为空。

顺便研究了一下 如果有多个连续的空行，想保留一个 vim的命令为：%s/^\n$//g

VIM对中文编码的支持

1、支持中文编码的基础

Vim要更好地支持中文编码需要两个特性：+multi_byte和+iconv，可以用|:version|命令检查当前使用的Vim是否支持，否则的话需要重新编译。

2、影响中文编码的设置项

Vim中有几个选项会影响对多字节编码的支持：

encoding（enc）：encoding是Vim的内部使用编码，encoding的设置会影响Vim内部的Buffer、消息文字等。在 Unix环境下，encoding的默认设置等于locale；Windows环境下会和当前代码页相同。在中文Windows环境下encoding的 默认设置是cp936（GBK）。 fileencodings（fenc）：Vim在打开文件时会根据fileencodings选项来识别文件编码，fileencodings可以同时设置多个编码，Vim会根据设置的顺序来猜测所打开文件的编码。 fileencoding（fencs） ：Vim在保存新建文件时会根据fileencoding的设置编码来保存。如果是打开已有文件，Vim会根据打开文件时所识别的编码来保存，除非在保存时重新设置fileencoding。 termencodings（tenc）：在终端环境下使用Vim时，通过termencoding项来告诉Vim终端所使用的编码。

3、Vim中的编码转换

Vim内部使用iconv库进行编码转换，如果这几个选项所设置的编码不一致，Vim就有可能会转换编码。打开已有文件时会从文件编码转换到 encoding所设置的编码；保存文件时会从encoding设置的编码转换到fileencoding对应的编码。经常会看到Vim提示[已转换]，这是表明Vim内部作了编码转换。终端环境下使用Vim，会从termencoding设置的编码转换到encoding设置的编码。

可以用|:help encoding-values|列出Vim支持的所有编码。

4、具体应用环境的设置

只编辑GBK编码的文件

set fileencodings=cp936 set fileencoding=cp936 set encoding=cp936

只编辑UTF-8编码的中文文件

set fileencodings=utf-8 set fileencoding=utf-8 set encoding=cp936 或者 set encoding=utf-8

同时支持GBK和UTF-8编码

set fileencodings=ucs-bom,utf-8,cp936 set fileencoding=utf-8 set encoding=cp936 或者 set encoding=utf-8

如果在终端环境下使用Vim，需要设置termencoding和终端所使用的编码一致。例如：

set termencoding=cp936 或者 set termencoding=utf-8

Windows记事本编辑UTF-8编码文件时会在文件头上加上三个字节的BOM：EFBBBF。如果fileencodings中设 置ucs-bom的目的就是为了能够兼容用记事本编辑的文件，不需要的话可以去掉。Vim在保存UTF-8编码的文件时会去掉BOM。去掉BOM的最大好处是在Unix下能够使用cat a b>c来正确合并文件，这点经常被忽略。

5、FAQ

为什么在Vim中一次只能删除半个汉字？

因为encoding设置错误，把encoding设置为cp936就可以解决此问题。在Unix环境下Vim会根据locale来设置默认的encoding，如果没有正确设置locale并且没有设置encoding就会一次只能删除半个汉字。

VIM为什么不能输入繁体字？

把euc-cn或者GB2312改为cp936就可以了。euc-cn是GB2312的别名，不支持繁体汉字。cp936是GBK的别名，是GB2312的超集，可以支持繁体汉字。

VIM为什么提示不能转换？

因为在编译Vim时没有加入iconv选项，重新编译Vim才能解决。

如何打开一个GBK编码的文件并另存为UTf-8编码？

保存文件时运行命令|:set fileencoding=utf-8|就可以了。

怎样使用certbot-dns-cloudflare

 【介绍】 

源码：https://github.com/cloudflare/certbot-dns-cloudflare certbot-dns-cloudflare 1.30.0 

源码：https://pypi.org/project/certbot-dns-cloudflare/ 

作者：https://github.com/certbot/certbot 

参考：https://www.cnblogs.com/senro/p/Blog01_L_S.html 

参考：https://www.cnblogs.com/senro/p/Blog01_L_S.html 

参考：https://community.letsencrypt.org/t/certbot-dns-cloudflare-automatic-renewal-issue/97627 

【安装】 

参考：https://bobcares.com/blog/install-certbot-dns-cloudflare/ 

1. 安装 snap ： 

参考：https://amon.org/snap 

设置 snapd 为开机启动：

 2. 安装 certbot-dns-cloudflare ：

 sudo snap install certbot-dns-cloudflare

 输出： 1 2 2022-09-18T19:46:35Z INFO Waiting for automatic snapd restart... certbot-dns-cloudflare 1.30.0 from Certbot Project (certbot-eff✓) installed 

3. 安装 python3-certbot-dns-cloudflare ：

 Ubuntu 系统：

 sudo apt-get install python3-certbot-dns-cloudflare 

CentOS 系统： 

sudo yum install python3-certbot-dns-cloudflare 

【配置】 

注意：如果同一台设备切换 CloudFlare 账号，务必清空 /etc/letsencrypt/ 下所有证书相关文件，然后从填写邮箱重新开始。 

先在 CloudFlare 获得 API Token ： 

1. 登录Cloudflare后，点击右上角用户头像，在下拉列表中点击My Profile。 

2. 在新页面便可看到API Token的标签。点击Create Token。

 3. 显示有很多模板可供使用，使用第一个 Edit zone DNS。 

4. 一切保持默认就好；在 Zone Resources，选择 All zones 。

 5. 创建Token后，页面会显示一个很长的字符串，这就是Token，点击后面的Copy保存下来。 

参考：https://laowangblog.com/python-cloudflare-api-update-dns.html 

参考：https://juejin.cn/post/7069995574266691614 

在需要运行Certbot的主机上创建一个文件：/etc/letsencrypt/certbot-dns-cloudflare.ini 1 dns_cloudflare_api_token = _yourToken_ 修改这个文件的所有者和权限，提高域名安全性。

建议root:root和600。 

【使用】 签发证书： 

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/certbot-dns-cloudflare.ini -d domain.name -d *.domain.name 

Certbot的所有信息的路径：/etc/letsencrypt。 

archive目录：包含所有已经申请的证书及私钥，包括已经过期的证书。

 live目录：只包含最新的证书及私钥，通过符号链接指向archive目录对应的文件。 

fullchain.pem是大多数软件需要的证书文件，实际上它是cert.pem和chain.pem的拼接。 privkey.pem如其名，是私钥文件。 

更新证书： 

 certbot renew 查看证书： 

 certbot certificates 删除证书：

 certbot delete 自动更新证书： 

Certbot的设计就是用来自动化的，根据获得软件包的方式，你的Certbot可能已经带有自动化的脚本。 自动化有两套方案，Crontab或Systemd Timer。 

这里说Systemd Timer。 

创建文件：/etc/systemd/system/certbot.service 

[Unit]

Description=Let's Encrypt renewal

[Service]

Type=oneshot ExecStart=/usr/bin/certbot renew --quiet --agree-tos 

创建文件：/etc/systemd/system/certbot.timer

[Unit]

Description=Automatic renewal of Let's Encrypt's certificates

[Timer]

OnCalendar=03:00:00

RandomizedDelaySec=1h

Persistent=true

[Install]

WantedBy=timers.target

启用自动更新：

sudo systemctl enable --now certbot.timer

标题: 怎样使用certbot-dns-cloudflare » 阿蒙的礼物
链接: https://amon.org/certbot-cloudflare
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

windows 跨网段访问samba you can't access this shared folder because your org

 提示错误：

　　　　　　You can\'t access this shared folder because your organization\'s security policies block unauthenticated guest access.

　　　　　　These policies help protect your PC from unsafe or malicious devices on the network.

原因：

　　因为Window10 更新安全策略，默认禁止访问无密码的Samba共享

解决：

　　在Samba中增加用户名密码配置, 并在配置文件smb.conf 中注释掉 map to guest = bad user 

          如：　　　　

　　　　# This option controls how unsuccessful authentication attempts are mapped
　　　　# to anonymous connections
　　　　#map to guest = bad user

Cisco ACI Inter VRF/Tenant Route Leaking Design – Simplified!

 There is a difference between something you know and something you understand. Recently, I came across such kind of a situation, when I realized I perfectly knew how to configure Inter VRF communication in ACI, but the in-depth understanding was missing. The intention of this article is not to share my experience, but the learning.

Please note that Shared Services term which is widely used in most of the documents is nothing but about Inter VRF/Tenant Communication.

I would like to mention, the level of documentation Cisco has done for ACI is commendable. You can find a detailed guide for all the bells and whistle in ACI on the Cisco official site.

Then, Why Am I Writing This?

Well, I thought there is a very critical design guideline around Inter VRF/Tenant route leaking methods in ACI, which I should highlight. So, just trying to do that…

Note: This is an advanced topic in ACI and I assume you have the working knowledge of ACI components like Tenant, EPG, BD, VRF, Contract etc. So, let’s begin…

Need for Inter VRF/Tenant Communication

The first thing we need to understand is in which cases Inter VRF/Tenant communication will be needed:

1. Shared Services – Meaning, you have an EPG hosting common shared services in one VRF (shared service provider) and there can be single or multiple EPGs in another VRF (shared service consumers) using the shared services.
2. Ad-Hoc – There can be specific two or more EPGs in separate VRFs and you might need them to communicate with each other as per requirement E.g. Multi-tier application setup with EPGs corresponding to every tier in separate VRFs.

Role of Contracts

As you must be aware of the fact that all the communication in ACI is governed by Contracts, even in case of inter vrf communication, we will need contracts between the EPGs. This is where the duality of the contract comes into the picture. So, there are two roles of contracts in case of inter vrf/tenant communication:

1. Access control with the help of subjects and filters defined in the contracts
2. Route Leaking between consumer and provider VRFs (I know many of us looked at contracts as ACLs, it’s more than that)

Contract Scope is an important attribute, it can be either of the two mentioned below:

1. Scope: Tenant – Provider and consumer EPGs are in different VRFs but the same tenant.
2. Scope: Globe – Provider and Consumer EPGS are in different VRFs as well as the different tenant.

Few Considerations

• In the case of inter tenant communication between two user tenants, the contract must be created in provider tenant and has to be exported to the consumer tenant. On the consumer side, the exported contract has to be attached to the consumer EPG as Consumed Contract Interface.
• Common tenant comes with the superpowers, in case you have one EPG in user tenant and another EPG in common tenant, create a contract in common tenant. That eliminates the overhead of exporting the contract, as contracts created in common tenant can be directly attached to EPGs in user tenant as provided or consumed contract.
• In the case of inter vrf communication within the same tenant, just the contract has to be provided and consumed into respective EPGs like we do normally and contract export is not required.
• Since the subnets between two VRFs will be exported to each other, they have to be unique and non-overlapping.

Design Approach

The design approach is selected based on whether there will be a single EPG or multiple EPGs (in Provider VRF) serving as the shared service provider to the EPGs in consumer VRF. Basically, there are two ways of doing the route leaking and policy enforcement between EPGs in separate VRFs.

1. Shared Services with Subnet defined under provider EPG (Usage: when there is only single EPG in provider VRF which will serve as a shared service provider) 

2. BD-BD Shared Services (Usage: when there are multiple EPGs in provider VRF that can serve as the shared service providers)

Let's get into more details of both methods one by one:

1. Shared Services with Subnet defined under provider EPG

This is the preferred method to configure inter vrf/tenant communication as per ACI Best practices guide and works perfectly fine for shared services requirement (until you reach the Limitations section below). There are about tons of documents online that would serve as a step by step configuration guide for this method. I am taking an example of EPGs in separate tenant and VRFs to explain this method.

Procedure:

• Define the Provider side subnet at EPG level and mark it as Shared between VRFs (define the subnet at EPG level even if you have the same subnet defined at BD level in case it is being used by other EPGs also, as in application-centric deployment).
• Define the Consumer side subnet at BD or EPG level and mark it as Shared between VRFs.
• Create a contract at provider tenant and attach to the provider EPG as provided contract.
• Export that contract from provider tenant to consumer tenant, attach to the consumer EPG as consumed contract interface.

A logical representation of the setup with the provider and consumer EPGs in different Tenants is shown in the diagram below:

What Happens Under the Hood?

Provider Side:

• As soon as the contract is attached at both provider and consumer EPGs, consumer side prefix P2 is leaked into the routing table of provider side VRF (VRF1).
• Along with the routes, VNID rewrite information corresponding to the consumer side VRF (VRF2) and ClassID is also installed in VRF1. Please note that ClassID, which is nothing but PC Tag (EPG ID) is set as 0, meaning there is no consumer EPG information associated with the leaked prefix.
• Policy is also not programmed in provider VRF. So, on the provider side, it just forwards the packet based on routing information and policy is never applied on this side.

Consumer Side:

• Provider side prefix P1 defined at EPG level is installed into the routing table of consumer side VRF (VRF2).
• Along with the prefix, VNID rewrite information corresponding to provider side VRF (VRF1) and ClassID is also installed in VRF2. Please note that ClassID at consumer side is corresponding to EPG1 (provider EPG). This can also be considered as 1:1 static mapping of provider side subnet to the provider side EPG.
• Any incoming or outgoing traffic belonging to the provider subnet(P1) will be classified as EPG1.
• The contract is programmed in consumer VRF (VRF2). So, in this method, the policy is applied at the consumer side only and never on the provider side.

Limitations

In a nutshell, this method works like having 1:1 static mapping of provider side subnet to the provider side EPG in consumer VRF.

What if there are two provider EPGs using the same subnet as we normally have in application-centric deployment and both need to provide services to the consumer, if we follow the same method, what would be the ClassID (EPG ID) for provider’s leaked subnet installed at Consumer side?

Well, both providers will keep fighting (not literally) and at a time ClassID of only one provider EPG will be programmed in the consumer VRF, keeping another one inaccessible for the consumer (contract drop condition). 

Interesting isn’t it? That’s when the second method A.K.A Poor brother of the first method comes into rescue… 

2. BD-BD Shared Services

In my opinion, this method has been highly underrated due to its low profile appearance in shared services deployment guides. This method is also treated as the workaround for the limitation we saw in the first method.

In BD-BD shared services method, EPGs in both the VRFs form provider as well as consumer relation with each other. It’s kind of 360-degree relationship making both of them as a shared service provider as well as the shared service consumer. Again, I am taking the example of EPGs in separate tenant and VRFs to explain this method.

 Procedure:

• Define the subnets at BD level for both the EPGs in both VRF and mark them as Shared between VRFs.
• There is no need to define subnet at EPG level; route leaking is done between BDs.
• Create a contract in both tenants, provide and consume on both sides. It’s like configuring contracts as we did in the first method but twice and in both directions.
• What if you don’t need both EPGs to be the provider as well as the consumer? Well, still you need to form consumer as well as provider relation on both sides.
• So, in that case, you can make the second contract as a dummy contract, with filter mentioning a port on which there is no service running, or denying any unrequired port. It doesn’t need to enable communication, just required to form relationships. To save TCAM space, don’t check on apply in both directions.

A logical representation of the setup with the provider and consumer EPGs in different Tenants is shown in the diagram below:

What Happens Under the Hood?

If you see the diagram, everything is identical on both sides. Routes are leaked between both VRFs along with VNID rewrite info; contracts (policies) are programmed in both VRFs.

One thing to notice is ClassID at both the sides are set as 0. This means, there is no EPG information associated with the leaked subnets. Hence, there is no static mapping of the subnet with EPG ID.

In this case what essentially happens is that, to classify the endpoint a lookup is done in actual endpoint table which contains exact /32 host IPs and EPG information as compared to the first method, where the endpoint is classified based on the provider subnet defined at EPG level.

So even if two EPGs are using the same subnet, there won’t be any impact as there is no static mapping of the subnet to EPG is involved, as the endpoint classification process is more granular.

Once the endpoint is classified, the policy is applied as per the contract between both the EPGs.

Limitations

BD-BD shared services method requires both sides to have a provider and consumer contracts, regardless of the fact whether it is needed for communication or not.

This eats up the TCAM space and should be chosen only when you have more than one EPG in the same VRF to be the shared service provider to the consumer.

Quickbits

Verify VNID rewrite information and ClassID on the leaf switches using following commands:

Leaf-1#vsh

Leaf-1#show ip route vrf <tenant:vrf_name> <imported_IP_prefix> detail

Read the VRF crossing information section to get the details. ClassID will be shown in hex and when converted to decimal, gives us the pc tag of EPG.

Hope this post is helpful for all the ACI Experts out there. Your feedback will be highly appreciated!

Regards,

Jayesh

References:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/ACI_Best_Practices/b_ACI_Best_Practices.html

https://ciscolive.cisco.com/on-demand-library/?search=aci&search.event=ciscoliveus2018#/session/1509501653465001PRkT

• Tags:
• ACI inter vrf
• aci route leaking
• ACI shared service