Solved: Re: BGP SVI Routing Configuration

timhudson55 · ‎02-08-2022

Hello everyone,

Thanks to a very useful community answer (Can BGP be Routed Between 2 SVI's), I now know that I can use SVI's as BGP neighbours. However, I am very new to being hands-on with BGP! Is anyone able to help out a little with some of the commands? I've attached my small topology.

Vlan 151 is for the core site, with VLANs 11 and 12 for sites 1 and 2 respectively.

Any help that someone could provide is greatly appreciated!

Kind regards,

Tim

Richard Burts · ‎02-08-2022

Tim

Thanks for the additional information. There is one new piece of information that is very helpful:

- There is a MGMT VLAN (253) that must be accessible everywhere.

Now the requirement for trunk ports makes sense. If site 1 is connected to core and needs to process both the management vlan and a transit vlan then it needs to be a trunk.

So the connection from each remote site will be an Ethernet. The Ethernet interfaces will be trunks. Each device will have an SVI for the management vlan and an SVI for the transit vlan/subnet.

The IP scheme that you were given specifies the LAN subnets for each site. That scheme does not specify the management vlan but the directions are clear that you need to configure it. The scheme does not specify transit vlans but the requirement to connect core to remote means that 2 additional subnets are also required and you need to create them.

HTH

Rick

View solution in original post

Jon Marshall · ‎02-09-2022

So you need to create the vlan in the vlan database on both switches.

Then you should be able to ping.

Jon

View solution in original post

Richard Burts · ‎02-08-2022

Tim

Given the drawing that you post I wonder why you want to use BGP. If the main site is connected to remote sites using leased lines then it would seem that some Interior Routing Protocol (perhaps OSPF or EIGRP) would give you what you need.

BGP is a sophisticated protocol with many options. But to get started with the basics here is what you would need:

- a router bgp statement defining the AS number you are using.

- one or more neighbor statements specifying that AS number the neighbor is using and the IP address of the neighbor.

- one or more network statements specifying what networks you want to advertise.

HTH

Rick

timhudson55 · ‎02-08-2022

Hi Richard,

Thank you for the response. I would definitely agree that BGP is not the best protocol for this. Unfortunately, that is the requirement given to me.

Can I use e.g.

CORE-SWITCH
# router bgp 151
# neighbour 10.1.1.252 remote-as 11
# network 10.15.1.0 255.255.255.0

SITE-1-SWITCH
# router bgp 11
# neighbour 10.15.1.252 remote-as 151
# network 10.1.1.0 255.255.255.0

Or do the neighbour addresses have to be in the same subnet?

Many thanks!

Richard Burts · ‎02-08-2022

Tim

Thanks for the clarification that this is an assignment. Your drawing shows a main site and 2 remote sites connected by leased lines. And it shows a subnet at each site. I would assume that the subnet at each site is the LAN/user segment for the site. And I would assume that each of the leased lines would also have a subnet. The BGP neighbor relationship would use the leased line subnet address and not the LAN addresses for forming the neighbor relationship.

HTH

Rick

timhudson55 · ‎02-08-2022

Thanks again Rick,

I assume this would need to be slightly different if the leased lines need to stay as trunk interfaces? I believe this is where @paul driver's solution could work?

Kind regards!

Richard Burts · ‎02-08-2022

Tim

I am puzzled about your suggestion that the leased lines need to stay as trunk interfaces? Why would it be a trunk? If it is a trunk which carries multiple vlans between sites, then why would you need BGP?

I believe that we need to clarify some things about the topology of your network. So far we know about 3 sites and about 3 networks. It makes sense to me that these 3 networks would be the LAN subnet for each site. Is that correct? In that case we need to think about the connection between sites. I have looked at the discussion that you reference in your original post and see that this is an aspect that Jon did not address in his suggestions. He is quite correct that you can configure BGP on an SVI. What he did not clarify is that the SVI used for BGP is different from the SVI used for the local LAN. There need to be transit subnets that connect the remote site to the core site. If those links connecting the remote sites to the core are Ethernet then it is quite possible to configure BGP on the SVI of the transit vlan. But the BGP config would not use the SVI for the local lan.

HTH

Rick

timhudson55 · ‎02-08-2022

Apologies about all of the confusion. There has been a process of me understanding the topology myself.

- So the 'leased line' is very loose and more like a direct cable.

- Apparently, the ports on each side have to be a trunk but I am not 100% sure of the reason to be sure. Sorry about that.

- The mention of 'transit subnets' I found really interesting as I had been leaning towards the idea that there had to be something in between surely!

Overall, the requirements I have got are:

- Must use BGP

- Must be Trunk ports on each side of the 'leased line'

- Each site must have its own access VLAN

- Each site has a device connected (10.x.1.1 - not a gateway) must be able to ping a device connected to the core switch with the IP 10.15.1.1 (not a gateway)

- There is a MGMT VLAN (253) that must be accessible everywhere.

Thank you so much for your patience thus far Rick. I realise I am probably not putting forward the most amount of information that is useful! Here is the IP scheme I was given.

Core Site (VLAN 151)

Network: 10.15.1.0/24

Gateway: 10.15.1.254




Site 1 (VLAN 11)

Network: 10.1.1.0/24

Gateway: 10.1.1.254




Site 2 (VLAN 21)

Network: 10.2.1.0/24

Gateway: 10.2.1.254

Thanks again,

Tim

timhudson55 · ‎02-08-2022

Also, it would be generally interesting to know the most efficient way of doing this!

Richard Burts · ‎02-08-2022

Tim

Thanks for the additional information. There is one new piece of information that is very helpful:

- There is a MGMT VLAN (253) that must be accessible everywhere.

Now the requirement for trunk ports makes sense. If site 1 is connected to core and needs to process both the management vlan and a transit vlan then it needs to be a trunk.

So the connection from each remote site will be an Ethernet. The Ethernet interfaces will be trunks. Each device will have an SVI for the management vlan and an SVI for the transit vlan/subnet.

The IP scheme that you were given specifies the LAN subnets for each site. That scheme does not specify the management vlan but the directions are clear that you need to configure it. The scheme does not specify transit vlans but the requirement to connect core to remote means that 2 additional subnets are also required and you need to create them.

HTH

Rick

timhudson55 · ‎02-08-2022

Thankyou so much! That has been extremely helpful in helping me understand the scenario. I'm going to have an interesting evening!!!! (It's 17:11 over here in the UK)

Kind regards,

Tim

Richard Burts · ‎02-08-2022

Tim

Now it is making sense. We seem to have started with the assumption that the IP specs given were all of what you needed. Now we realize that they were only for specifying the LAN of each site. You need to also have the vlan for MGMT and vlans for transit. The essential parts that you will need for each site would include:

- configure the vlan for the LAN at each site.

- configure an SVI for that vlan. configure an IP and mask for the SVI. This will be the gateway for any device connected in the vlan.

- configure the vlan for MGMT.

- configure an SVI for the MGMT vlan. configure an IP and mask for the SVI.

- configure the vlan for transit. (core will have 2 each remote site will have 1)

- configure an SVI for the transit vlan. configure an IP and mask for the SVI.

- configure BGP including commands for

=BGP AS number

= BGP neighbor with IP address and AS number (neighbor address on the transit subnet)

= BGP network statement. (you will need to advertise the LAN, you do not need to advertise the transit networks)

Good luck with this. Let us know how it goes.

HTH

Rick

timhudson55 · ‎02-08-2022

Hello again,

This is the configuration I have come to so far and am struggling to see why it still won't ping? Any help is appreciated!

Core Switch

router bgp 151
neighbor 10.101.1.1 remote-as 11
neighbor 10.101.1.1 maximum-routes 12000
!
address-family ipv4
neighbor 10.101.1.1 activate
network 10.15.1.0/24
network 10.101.1.0/30

!

interface Vlan101
description TRANSIT-SITE-1
no autostate
ip address 10.101.1.1/30
!
interface Vlan151
no autostate
ip address 10.15.1.254/24
!
interface Vlan252
vrf OOB-MGMT
!
interface Vlan253
description IB-MGMT
no autostate
ip address 10.16.253.101/24




Site 1

router bgp 11
neighbor 10.101.1.2 remote-as 151
!
address-family ipv4
neighbor 10.101.1.2 activate
network 10.1.1.0/24
network 10.101.1.0/30

!

interface Vlan11
no autostate
ip address 10.1.1.254/24
!
interface Vlan101
description TRANSIT-SITE-1
no autostate
ip address 10.101.1.2/30
!
interface Vlan253
description IB-MGMT
no autostate
ip address 10.16.253.1/24

Am I missing something silly or am I on the wrong track completely?

Many thanks,

Tim

Jon Marshall · ‎02-08-2022

Are there typos in the configurations you posted ie. the BGP neighbor IPs need to be the remote SVI IP addresses but you have made them the IPs on the same switch eg. the core switch IP is 10.101.1.1 but you have used that as the peer IP (which should be 10.101.1.2).

Jon

timhudson55 · ‎02-08-2022

Apologies! Yep that is a typo

Jon Marshall · ‎02-08-2022

From the core switch can you ping 10.101.1.2 ?

If you can then can you post the output of

sh ip bgp summary

from the core switch.

Jon