DO457 - ch07s07

The Break Up scenario described the separation of example.com network into three independent networks. Routing among the networks was established by way of explicitly advertised routes under eBGP, in accordance with peering agreements between the businesses.

Under the Break Up scenario, traffic between server01 in AS10101 and server02 in AS19216 is routed through AS17216 by way of lab environment links simulating connections across the internet.

This is an example of hub and spoke internetwork topology. It is preferred, though, for each of the three networks to consider both of the other two to be BGP neighbors and receive routes from them. When each AS advertises its subnets to both of its neighbors, traffic will not have to be routed across an intermediary (the hub). The new arrangement is an example of a mesh internetwork topology.

Under the first part of the Adjustment scenario, a new layer 3 subnet has been provisioned that provides an alternate path across the internet between AS10101 and AS19216. This Lab configures eBGP to advertise routes so traffic can flow between AS10101 and AS19216 across the alternate path, using the newly provisioned subnet.

The management team asks you to:

Configure eBGP to advertise routes appropriately.
Verify that after making the changes, spine01 and spine02 see two BGP neighbors, and have the desired routes.

You will be accessing the network devices by way of management interfaces. Those interfaces is already configured with respect to layer 3 and up, and should not be changed.

This exercise assumes that Guided Exercises 6.7 and 6.8 have been completed.

Figure 7.3:

The Adjustment Phase Production Services Network of example.com

Table 7.3. Adjustment Phase Interface Descriptions

Devices	Interfaces	Descriptions
`spine01`	`eth3`	`spine02-as19216`
`spine02`	`eth3`	`spine01-as10101`

Table 7.4. Adjustment Phase Layer 3 Addressing (management interfaces not shown)

Devices	Interfaces	IPv4 Addresses
`spine01`	`eth3`	`172.16.50.1/30`
`spine02`	`eth3`	`172.16.50.2/30`

In this lab, you will create an eBGP neighbor relationship across the link that was added in Lab 7.5.

Outcomes

You should be able to:

Revise the data in an existing variables file to support the new requirements
Compose a playbook with a play that configures devices to support new eBGP neighbor relationships and a new set of network advertisements.
Perform the play in the new playbook.
Verify that the outcome is as desired.

Open a terminal window on the workstation VM and change to your ~/ansible-generic-project/ directory.

Instructions

Perform the following steps:

Revise the data in an existing variables file to support the new requirements.
- Create a vars file named vars/ebgp-adjustment-data.yml. It should be identical to /home/student/proj/vars/ebgp-breakup-data.yml, but each border router should now have two neighbors. The border routers are spine01, spine02, and cs01.
Compose a playbook with a play that configures devices to support new eBGP neighbor relationships and a new set of network advertisements.
Name the new playbook ebgp-adjustment.yml. It does the same things as the ebgp-breakup.yml, but uses the vars/ebgp-adjustment-data.yml vars file instead of vars/ebgp-breakup-data.yml.
Perform the play in the new playbook.
Verify that the outcome is as desired.
- Verify that each border router sees two BGP neighbors (sh ip bgp sum).
- Verify that spine01 has routes for 192.168.* by way of spine02 (172.16.50.2) rather than cs01.
- Verify that spine02 has routes for 10.10.* by way of spine01 (172.16.50.1) rather than cs01.

Revise the data in an existing variables file to support the new requirements.

Create a vars file named vars/ebgp-adjustment-data.yml. It should be identical to /home/student/proj/vars/ebgp-breakup-data.yml, but each border router should now have two neighbors. The border routers are spine01, spine02, and cs01.

Create vars/ebgp-adjustment-data.yml by copying proj/vars/ebgp-breakup-data.yml.

[student@workstation ansible-generic-project]$ cp \
> ~/proj/vars/ebgp-breakup-data.yml \
> vars/ebgp-adjustment-data.yml

Add the lines shown in bold in the listing below.

[student@workstation ansible-generic-project]$ cp \
> vars/ebgp-adjustment-data.yml
bgp_data:
  spine01:
    as: 10000
    router-id: 10.0.0.1/32
    networks:
    - 10.10.5.0/30
    - 10.10.10.0/30
    neighbors:
    - { as: 17216, ipv4: 172.16.2.2/30 }
    - { as: 19216, ipv4: 172.16.50.2/30 }

  spine02:
    as: 19216
    router-id: 192.168.0.1/32
    networks:
    - 192.168.5.0/30
    - 192.168.10.0/30
    neighbors:
    - { as: 17216, ipv4: 172.16.5.2/30 }
    - { as: 10000, ipv4: 172.16.50.1/30 }

  cs01:
    as: 17216
    router-id: 172.16.0.1/32
    networks:
    - 172.16.10.0/30
    - 192.168.0.0/16
    - 10.10.0.0/16
    neighbors:
    - { as: 10000, ipv4: 172.16.2.1/30 }
    - { as: 19216, ipv4: 172.16.5.1/30 }

neighbors:
  spine01:
  - { as: 17216, ipv4: 172.16.2.2/30 }
  - { as: 19216, ipv4: 172.16.50.2/30 }

  spine02:
  - { as: 17216, ipv4: 172.16.5.2/30 }
  - { as: 10000, ipv4: 172.16.50.1/30 }

  cs01:
  - { as: 10000, ipv4: 172.16.2.1/30 }
  - { as: 19216, ipv4: 172.16.5.1/30 }

networks:
  spine01:
  - 10.10.5.0/30
  - 10.10.10.0/30

  spine02:
  - 192.168.5.0/30
  - 192.168.10.0/30

  cs01:
  - 172.16.10.0/30

Compose a playbook with a play that configures devices to support new eBGP neighbor relationships and a new set of network advertisements.

Name the new playbook ebgp-adjustment.yml. It does the same things as the ebgp-breakup.yml, but uses the vars/ebgp-adjustment-data.yml vars file instead of vars/ebgp-breakup-data.yml.

Create vars/ebgp-adjustment.yml by copying proj/vars/ebgp-breakup.yml.

[student@workstation ansible-generic-project]$ cp \
> /home/student/proj/ebgp-breakup.yml \
> ebgp-adjustment.yml

Modify the line shown in bold in the listing below.

[student@workstation ansible-generic-project]$ cat ebgp-adjustment.yml
---
- name: play that configures eBGP on VyOS and IOS border routers
  hosts: border-routers
  vars:
    vyos_bgp_tpl: j2/vyos-bgp.j2
    ios_bgp_tpl: j2/ios-bgp.j2
  vars_files:
    - vars/ebgp-adjustment-data.yml

  tasks:
    - name: do not use OSPF to advertise across AS boundaries on cs01
      ios_config:
        lines:
          - passive-interface default
        parents: router ospf 1
      when: inventory_hostname == 'cs01'

    - name: do not use OSPF to advertise across AS boundaries on spines
      vyos_config:
        lines:
          - set protocols ospf passive-interface 'eth5'
          - set protocols ospf passive-interface 'eth3'
      when: inventory_hostname in groups['spines']

    - name: static routes on cs01 to support non-local BGP routes
      ios_config:
        lines:
          - ip route 10.10.0.0 255.255.0.0 GigabitEthernet2 172.16.2.1
          - ip route 192.168.0.0 255.255.0.0 GigabitEthernet3 172.16.5.1
      when: inventory_hostname == 'cs01'

    - name: "map bgp data to ios device using {{ ios_bgp_tpl }}"
      ios_config:
        src: "{{ ios_bgp_tpl }}"
      when: ansible_network_os == 'ios'

    - name: "map bgp data to vyos device using {{ vyos_bgp_tpl }}"
      vyos_config:
        src: "{{ vyos_bgp_tpl }}"
      when: ansible_network_os == 'vyos'

The playbook is expecting to use j2/vyos-bgp.j2 and j2/ios-bgp.j2. You should already have copies of these in /home/student/proj/j2, so put a copy in ansible-generic-project/j2/ as well.
```
[student@workstation ansible-generic-project]$ cp \
> /home/student/proj/j2/*-bgp.j2 j2/
```

Perform the play in the new playbook.

[student@workstation ansible-generic-project]$ ansible-playbook \
> ebgp-adjustment.yml

Verify that the outcome is as desired.

Verify that each border router sees two BGP neighbors (sh ip bgp sum).

[student@workstation ansible-generic-project]$ ansible -m vyos_command \
> -a "commands='sh ip bgp sum'" spines
[student@workstation ansible-generic-project]$ ansible -m ios_command \
> -a "commands='sh ip bgp sum'" cs01

Verify that spine01 has routes for 192.168.* by way of spine02 (172.16.50.2) rather than cs01.

[student@workstation ansible-generic-project]$ ansible -m vyos_command \
> -a "commands='sh ip ro 192.168.10.2'" spine01
spine01 | SUCCESS => {
    "changed": false,
    "stdout": [
        "Routing entry for 192.168.10.0/30\n Known via \"bgp\", distance 20, metric
20, best\n Last update 00:04:56 ago\n * 172.16.50.2, via eth3"
    ],
    "stdout_lines": [
        [
            "Routing entry for 192.168.10.0/30",
            " Known via \"bgp\", distance 20, metric 20, best",
            " Last update 00:04:56 ago",
            " * 172.16.50.2, via eth3"
        ]
    ]
}

Verify that spine02 has routes for 10.10.* by way of spine01 (172.16.50.1) rather than cs01.

[student@workstation ansible-generic-project]$ ansible -m vyos_command \
> -a "commands='sh ip ro 10.10.10.2'" spine02
spine02 | SUCCESS => {
    "changed": false,
    "stdout": [
        "Routing entry for 10.10.10.0/30\n Known via \"bgp\", distance 20, metric
20, best\n Last update 00:07:57 ago\n * 172.16.50.1, via eth3"
    ],
    "stdout_lines": [
        [
            "Routing entry for 10.10.10.0/30",
            " Known via \"bgp\", distance 20, metric 20, best",
            " Last update 00:07:57 ago",
            " * 172.16.50.1, via eth3"
        ]
    ]
}

Discuss Red Hat Ansible for Network Automation

Go to community

Welcome to the Red Hat Ansible for Network Automation (DO457) group!

Syed

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Ansible for Network Automation! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to DO457.Read more about Red Hat Ansible for Network Automation here.

3120

Revision: do457-2.5-4693601