Re: Pinging between eBGP neighbors...

MikeAW2010 · ‎02-13-2021

I designed this topology...

I configured all neighborships on the 172.16.x.x networks, but was unable to ping between each neighbor until I configured the 172.16.x.x network statements (and I mean network and not neighbor statements) on the cloud which got me to thinking, is there a simpler way to advertise the actual eBGP peers? How do ISP's typically do it? Do they have to write out a network statement for every single eBGP peer they have?

Georg Pauwen · ‎02-14-2021

Hello,

not sure what exactly you have configured, but with the below, all 172.16.0.0/16 addresses should be able to ping each other, without the need to announce any networks:

R11

interface Loopback1
ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
ip address 172.16.11.1 255.255.0.0
!
router bgp 1
bgp router-id 10.1.1.1
neighbor 172.16.31.1 remote-as 2
neighbor 172.16.41.1 remote-as 3

R31

interface Loopback1
ip address 10.3.3.3 255.255.255.0
!
interface Ethernet0/0
ip address 172.16.31.1 255.255.0.0
!
router bgp 2
bgp router-id 10.3.3.3
neighbor 172.16.11.1 remote-as 1

R41

interface Loopback1
ip address 10.4.4.4 255.255.255.0
!
interface Ethernet0/0
ip address 172.16.41.1 255.255.0.0
!
router bgp 3
bgp router-id 10.4.4.4
neighbor 172.16.11.1 remote-as 1

MikeAW2010 · ‎02-14-2021

Hi, in this instance, the cloud is an actual Router emulating an ISP network rather than a pass-through object like a hub. It has physical interfaces assigned and IP's configured. The 172 network between each physical interface and the cloud is subnetted into /30 node to node networks. Because the Cloud would technically be subnetted, like an ISP, I don't think R11, R31 and R41 would be able to communicate with each other unless there were some form of routing between each network on the cloud router.

I guess what I am trying to figure out is, how a real ISP handles the cloud aspect of BGP where as the example above shows me how the end-client handles it if they were connected on the same subnet.

Cloud#show run
Building configuration...

Current configuration : 1673 bytes
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cloud
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone CST -6 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Ethernet0/0
 ip address 172.16.11.2 255.255.255.252
!
interface Ethernet0/1
 no ip address
 shutdown
!
interface Ethernet0/2
 no ip address
 shutdown
!
interface Ethernet0/3
 no ip address
 shutdown
!
interface Ethernet1/0
 ip address 172.16.31.2 255.255.255.252
!
interface Ethernet1/1
 no ip address
 shutdown
!
interface Ethernet1/2
 no ip address
 shutdown
!
interface Ethernet1/3
 no ip address
 shutdown
!
interface Ethernet2/0
 ip address 172.16.41.2 255.255.255.252
!
interface Ethernet2/1
 no ip address
 shutdown
!
interface Ethernet2/2
 no ip address
 shutdown
!
interface Ethernet2/3
 no ip address
 shutdown
!
router bgp 100
 bgp log-neighbor-changes
 network 172.16.11.0 mask 255.255.255.252
 network 172.16.31.0 mask 255.255.255.252
 network 172.16.41.0 mask 255.255.255.252
 neighbor 172.16.11.1 remote-as 11
 neighbor 172.16.31.1 remote-as 31
 neighbor 172.16.41.1 remote-as 41
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end

R11#show run
Building configuration...

Current configuration : 1172 bytes
!
! Last configuration change at 08:24:24 CST Sun Feb 14 2021
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R11
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone CST -6 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
 ip address 172.16.11.1 255.255.255.252
!
interface Ethernet0/1
 no ip address
 shutdown
!
interface Ethernet0/2
 no ip address
 shutdown
!
interface Ethernet0/3
 no ip address
 shutdown
!
router bgp 11
 bgp log-neighbor-changes
 neighbor 172.16.11.2 remote-as 100
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end

R31#show run
Building configuration...

Current configuration : 1172 bytes
!
! Last configuration change at 08:24:55 CST Sun Feb 14 2021
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R31
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone CST -6 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
 ip address 10.3.3.1 255.255.255.0
!
interface Ethernet0/0
 ip address 172.16.31.1 255.255.255.252
!
interface Ethernet0/1
 no ip address
 shutdown
!
interface Ethernet0/2
 no ip address
 shutdown
!
interface Ethernet0/3
 no ip address
 shutdown
!
router bgp 31
 bgp log-neighbor-changes
 neighbor 172.16.31.2 remote-as 100
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end

R41#show run
Building configuration...

Current configuration : 1172 bytes
!
! Last configuration change at 08:25:54 CST Sun Feb 14 2021
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R41
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone CST -6 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
 ip address 10.4.4.1 255.255.255.0
!
interface Ethernet0/0
 ip address 172.16.41.1 255.255.255.252
!
interface Ethernet0/1
 no ip address
 shutdown
!
interface Ethernet0/2
 no ip address
 shutdown
!
interface Ethernet0/3
 no ip address
 shutdown
!
router bgp 41
 bgp log-neighbor-changes
 neighbor 172.16.41.2 remote-as 100
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end

Georg Pauwen · ‎02-14-2021

Hello,

I guess I misunderstood what you are looking for...

I once worked for a large ISP (the largest one by far at the time, unfortunately that ended in the largest bankruptcy ever as well). Either way, when it came to BGP, not only was everything entered manually, but double and triple checked as well. After all, this is the backbone of the Internet, so no mistakes are allowed, and there are very strict rules (such as route aggregation, which is mandatory), and if an ISP would somehow not adhere to these rules, they were in trouble. So in your case, all three neighbors would get an IP address (block), the (aggregate) routes would be announced, and everything would be documented extremely precise.

MikeAW2010 · ‎02-14-2021

I see, so would an ISP use the network commands I used manually entering every network command in their BGP peer? Would they put the point to point interfaces to the network nodes themselves in the BGP network statements?

MHM Cisco World · ‎02-14-2021

I check the config no DMVPN only eBGP

!
BGP like bridge base on big column
this column is IP address of underlay
the underlay is separate than the overlay "BGP"
Cloud
router bgp 100

neighbor 172.16.11.1 remote-as 11 <-all these neighbor is direct connect

neighbor 172.16.31.1 remote-as 31 <-all these neighbor is direct connect

neighbor 172.16.41.1 remote-as 41 <-all these neighbor is direct connect

R1,R2,R3 bgp
config the network of 10.x.x.x

finally ping the network 10.x.x.x between each Peer.

this how BGP work "OVERLAY"

MikeAW2010 · ‎02-14-2021

Haven't configured the DMVPN yet. Do I need to advertise the 10.x networks in BGP or will the tunnel handle that?

MHM Cisco World · ‎02-14-2021

You don’t need dmvpn,

in R1 ,2,3

router bgp ....

network 10......

now R1,2,3 will advertise 10... to cloud which re advertise it and hence all router know the 10... and can ping each other.

paul driver · ‎02-14-2021

Hello
Most simplistic way:

route-map connected
match interface x/x x/y x/z etc...
set origin igp

router bgp xxx
address-family ipv4 unicast
redistribute connected
or
redistribute connected route-map connected

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Deepak Kumar · ‎02-15-2021

Hi,

It's a difference between the IGP and BGP protocols. BGP is using TCP port 179 and all updates or packets are unicast by design, so it would require the Neighbor command for the neighborship established between two BGP peers. But it won't advertise or table that particular subnet in BGP until you define the network statement or redistribute it.

I never worked on the ISP backbone so I can't answer you, but I worked with the ISP at the circle level, and that ISP is enforcing the network statement as well. This is normal behavior for BGP (I'm not talking about the dynamic neighborship or similar method).

Regards,
Deepak Kumar,
Don't forget to vote and accept the solution if this comment will help you!

MikeAW2010 · ‎02-20-2021

Thanks for all the help so far. I have one more question.

I'm now moving forward to the next step of this configuration. (I'm in Texas and just got my power back YAY)

First I wish to state my context, that I am attempting to simulate the configuration on BOTH:

DMVPN peering using EIGRP between DMVPN nodes.
ISP side of eBGP peering between itself and the connected neighbors - therefore the 'cloud' is an actual router running eBGP.

eBGP is configured as per my previous post showing the show run command. eBGP is running and establishing properly but I did not include the commands in this example.

So this is the configuration. The issue is, my EIGRP neighborships are not properly establishing. I'm trying to figure out what is causing it.

##R11-HUB CONFIG##
##Configure EIGRP##
R11(config)#router eigrp 100
R11(config-router)#network 192.168.100.0 0.0.0.255
R11(config-router)#network 10.0.0.0 0.255.255.255
##Configure the tunnel interface. Remember you must lower the MTU to accommodate for the tunnel header##
R11(config)#interface Tunnel100
R11(config-if)#bandwidth 4000
R11(config-if)#ip address 192.168.100.11 255.255.255.0
R11(config-if)#ip mtu 1400
R11(config-if)#ip nhrp map multicast dynamic
R11(config-if)#ip tcp adjust-mss 1360
R11(config)#tunnel source Ethernet0/0
R11(config)#tunnel mode gre multipoint
R11(config)#tunnel key 100

##R31-SPOKE CONFIG##
##Configure EIGRP##
R31(config)#router eigrp 100
R31(config-router)#network 192.168.100.0 0.0.0.255
R31(config-router)#network 10.0.0.0 0.255.255.255
##Configure the tunnel interface – Single Command NHRP Configuration##
R31(config)#interface Tunnel100
R31(config-if)#bandwidth 4000
R31(config-if)#ip address 192.168.100.31 255.255.255.0
R31(config-if)#ip mtu 1400
R31(config-if)#ip nhrp network-id 100 nbma 172.16.11.1 multicast
R31(config-if)#ip tcp adjust-mss 1360
R31(config)#tunnel source Ethernet0/0
R31(config)#tunnel destination 172.16.11.1
R31(config)#tunnel key 100

##R41-SPOKE CONFIG##
##Configure EIGRP##
R41(config)#router eigrp 100
R41(config-router)#network 192.168.100.0 0.0.0.255
R41(config-router)#network 10.0.0.0 0.255.255.255
##Configure the tunnel interface – Multi Command NHRP Configuration##
R41(config)#interface Tunnel100
R41(config-if)#bandwidth 4000
R41(config-if)#ip address 192.168.100.41 255.255.255.0
R41(config-if)#ip mtu 1400
R41(config-if)#ip nhrp map 192.168.100.11 172.16.11.1
R41(config-if)#ip nhrp map multicast 172.16.11.1
R41(config-if)#ip nhrp network-id 100
R41(config-if)#ip nhrp nhs 192.168.100.11
R41(config-if)#ip tcp adjust-mss 1360
R41(config)#tunnel source Ethernet0/0
R41(config)#tunnel destination 172.16.11.1
R41(config)#tunnel key 100

MHM Cisco World · ‎02-20-2021

First I hop you well,
for your config EIGRP only with DMVPN
you need
default route
ip route 0.0.0.0 0.0.0.0 next-hop
in each Router Site to reach other site,
your config I OK no problem

MikeAW2010 · ‎02-20-2021

I see, so even though each router is connected via eBGP, a default route is still needed?

paul driver · ‎02-21-2021

Hello
@MHM Cisco World BGP ebgp wont establish on a default route by design if the only route in the rtrs rib is a default route as when bgp performs a route lookup check for the bgp neighbour and it sees only a default route it won’t even try to establish peering so using a default route wouldn't be applicable.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

MHM Cisco World · ‎02-21-2021

As I mention above EIGRP only with DMVPN,

the tunnel will use default route

the tunnel will advertise route

the router will use longest match and since default always be the last selection the router will select eigrp tunnel not default.

BUT default is need here for DMVPN tunnel to work.

for eBGP EIGRP & DMVPN I really don't know don't know how this work if you can give us example how it work.