I have 2 7k that I have to configure in a port channel group that will be connected to a fortigate
firewall.
do I assign to separate IP address for the 1 port channel ?
I understand the config from the firewall to the 7k,
I am having a blonde moment about the configuration from both 7k to the firewall
Hello Michael
It depends on whether you want to create an L2 or an L3 portchannel. You have two choices.
- Make the port channel a routed port channel, disabling any switchport configurations and assigning an IP address to the logical port itself. You would do this if the link between the nexus and the fortigate is to be a single separate point to point subnet.
- Make the port channel an access port on a VLAN and create an SVI that will have the IP address and the responsibility of the routing on the nexus.
Both will give you the same routing options on the nexus but the second choice will allow you to add additional ports on the nexus on the same VLAN providing connectivity to the same subnet connecting the two devices, to other devices as well. Which one you choose should not affect your fortigate configuration.
A third option would be to create a trunk on the aggregated link, but that depends on what configuration you have on the fortigate end.
I hope this has been helpful!
Laz
Lazaros thanks for that. A couple of more questions
- I will create a routable port channel from both 7k to Firewall. These will be used as BGP peering session within a VRF, does this seem ok
- If it is ok how can I prevent routing loops ? can I make 7k1 the primary?
- If I can make it the primary, if it goes down how can I make 7k2 kick in as the primary?
is it to make a floating static route pointing to 7k2 with a higher AD with the VRF
once again thanks
Hello Michael
It depends on what the topology is showing. If you want to create an aggregated link that spans multiple nexus switches, then you must create a vPC peer link between the two switches, and then create a vPC (an aggregated link that spans both switches) between the firewall and the two switches. If this is the case, then you won’t have any issues with loops as there is logically only one path between the firewall and the switches, and you can create a straightforward BGP peering between your ASN and that of any devices behind the firewall (ISP routers etc). You can find out more information on how to configure this on Nexus switches here:
If you enable this, then you have redundancy even if one of the two nexus switches fails.
I hope this has been helpful!
Laz
Lazors
Thanks for that all done and working fine done with routable port channel to fortigate and configuration between both 7ks done
One last thing,
if the BGP peering between 7k1 and fortigate goes down how do I make the 7k2 the primary?
Is it floating static with greater AD than BGP pointing to the second 7k?
Hello Michael
Great to hear that all is working well. If BGP peering between 7k1 and fortigate goes down, then the firewall will not see the 7k1 as an option for routing traffic, so it will automatically use 7k2. This will take some time of course, until BGP reconverges, but you can adjust various parameters to improve on that. One of these is the BGP next hop address tracking about which you can read more here:
Now if the 7k1 fails, the firewall will detect this via the failure of the BGP peer, and all incoming traffic will go via the 7k2 switch. However, it is also possible to influence incoming traffic when both switches are running normally. You may want one switch to take a heavier load than the other. You can do this in several ways, but you must remember, if the AS you are connecting to is not administrated by use (it may belong to the ISP), then you don’t have ultimate control over incoming traffic routing, but you can attempt to influence it. You can do this by doing any of the following:
- Leaking more specific routes (smaller subnet masks)
- MED
- AS-PATH Prepending
- Community/Local Pref agreement
You can link to those lessons above if you find them useful.
I hope this has been helpful!
Laz
Lagabides
Thanks that work perfect
final Q I promise.
If I have no route-map and no prefix list, and my BGP configuration has address family ipv4 unicast , will all my bgp routes be advertised to the firewall bgp peer/
Hello Michael
First of all, keep the questions coming, that’s why we’re here!
In order to advertise BGP routes, the only prerequisites are to have the routes explicitly stated using the network command, and to have those routes in the routing table of the local device. No other constructs are necessary. Oh and make sure that the BGP peering is taking place correctly too. More info on advertising networks using BGP can be found below.
Also, the address-family ipv4 unicast command is considered the default for most IOS systems, and I’m assuming it’s the same for Nexus. So even if you don’t configure BGP under this address family, the ipv4 unicast address family is assumed by default.
I hope this has been helpful!
Laz
Laz
The peering between the 7k and fortigate is all good. The fortigate is connected to ISP. The fortigate has 2 subnets in its routing table that needs to be sent to 7k.
when I bring up the BGP peer between the 7k and the fortigate the 7k routing table is advertised to the fortigate. I need to stop this.
I have tried route-maps with prefix-list permit 0.0.0.0/0 le 19 applied both IN and OUT but they are stll advertised.
Any ideas?
Hello Michael
There are various methods that you can use to prevent the advertising of networks when using BGP. If you look at the BGP section of NetworkLessons, you will see that Unit 5 is called BGP Filtering.
In that unit you will find various methods by which you can filter these routes. Now these lessons are catered towards Cisco IOS devices, but the concepts are the same for Nexus, and if there are any differences in the commands, you can look them up in appropriate command references.
I hope this has been helpful!
Laz
Laz
I have done that but still can not advertise the correct subnet
router bgp 2
bgp router-id 192.168.0.5
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 1
neighbor 10.0.0.1 description eBGP to csr1000v-1
neighbor 10.0.0.6 remote-as 3
neighbor 10.0.0.6 description eBGP to csr1000v-3
neighbor 10.0.128.2 remote-as 4
neighbor 10.0.128.2 description eBGP to csr1000v-4
!
address-family ipv4
network 10.0.0.4 mask 255.255.255.252
network 10.0.128.0 mask 255.255.255.252
network 192.168.0.5 mask 255.255.255.255
neighbor 10.0.0.1 activate
neighbor 10.0.0.1 send-community
neighbor 10.0.0.1 next-hop-self
neighbor 10.0.0.6 activate
neighbor 10.0.0.6 send-community
neighbor 10.0.0.6 next-hop-self
neighbor 10.0.0.6 prefix-list TRANSIT out
neighbor 10.0.128.2 activate
neighbor 10.0.128.2 send-community
neighbor 10.0.128.2 next-hop-self
exit-address-family
csr1000v-2#sh bgp ipv4 unicast neighbors 10.0.0.6 advertised-routes
Total number of prefixes 0
csr1000v-2#sh ip pre
csr1000v-2#sh ip prefix-list
ip prefix-list TRANSIT: 2 entries
seq 5 permit 192.168.0.0/16
seq 10 permit 11.11.11.0/24
Hello Michael
In your configuration above, you are advertising only 192.168.0.0/16 and 11.11.11.0/24 to BGP peer 10.0.0.6. All other networks should not be advertised to that peer from csr1000v-2. Are you getting more networks appearing in the BGP table of the 10.0.0.6 peer? If so, is it receiving them from another source, say csr1000v-1 or csr1000v-3?
Take a look and let us know.
I hope this has been helpful!
Laz
Laz
I was running this in VIRL prior to implementing it. The connection are all single point to point so there was no other source. However I configured it in production and wit worked perfect
Thanks again for your help
Michael
Hello Michael
Great to hear and always glad to be of help!
Laz