BGP Routing

[mudvayne15]

Hi Everyone,

Anyone can help me about my issue right now, we are trying to ping vpn.catonetworks.net from our gateway router but using our Public IP's results to have very high latency. The public IP where ISP provided by ISP looks very good. Is there something wrong on how we configured BGP? Thanks in Advance. 

GigabitEthernet0/2 x.x.111.201 <- Advertised public IP
Loopback0 x.x.236.61 <- ISP Provided IP
!
router bgp xxxx
bgp router-id x.x.x.x
bgp log-neighbor-changes
neighbor upstream peer-group
neighbor upstream version 4
neighbor iBGP peer-group
neighbor iBGP update-source Loopback0
neighbor iBGP version 4
neighbor x.x.236.62 remote-as 37965
neighbor x.x.236.62 peer-group upstream
neighbor x.x.236.62 ebgp-multihop 255
!
address-family ipv4
network x.x.111.0 mask 255.255.254.0
neighbor upstream soft-reconfiguration inbound
neighbor upstream prefix-list BOGONS in
neighbor upstream prefix-list ANNOUNCE out
neighbor upstream filter-list 500 out
neighbor iBGP next-hop-self
neighbor iBGP soft-reconfiguration inbound
neighbor x.x.x.x activate
neighbor x.x.236.62 activate
exit-address-family

!
ping vpn.catonetworks.net so x.x.236.61 - ISP IP configured on Loopback
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 47.103.125.9, timeout is 2 seconds:
Packet sent with a source address of x.x.236.61
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/14 ms
!
ping vpn.catonetworks.net so x.x.111.201   - Our Public IP
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 47.103.125.9, timeout is 2 seconds:
Packet sent with a source address of x.x.111.201
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 268/269/274 ms

[Giuseppe Larosa]

Hello @mudvayne15 ,

if your loop0 is configured with an ISP provided public IP address I would expect the eBGP session to use

neighbor x.x.236.62 update-source loop0

because you have configured

>> neighbor x.x.236.62 ebgp-multihop 255

it looks like you would like to configure an eBGP session on loopbacks and not direct eBGP peers.

Before making any change check the status of your BGP sessions with

show ip bgp summary

! here you should see a number of prefixes in the line for x.x.236.62

show ip bgp neighbors

! here for x.x.236.62 you must see status established any other status including Active is bad news

Hope to help

Giuseppe

[mudvayne15]

Thank you for getting back at me. That is correct we are using x.x.236.62

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
x.x.111.2 4 38792 1218720 1362599 24606 0 0 2y17w 2
x.x.236.62 4 37965 284963 287442 24606 0 0 25w4d 1

is it better to update the value of multi-hop? 

[Giuseppe Larosa]

Hello @mudvayne15 ,

>> Is it necessary to remove multi-hop? 

No,  it is a necessary command for eBGP between loopbacks.

Edit: you could tune it to 2 that is the minimum value of TTL that allows to setup eBGP with loopbacks.

The session with ISP is correctly established

>> x.x.236.62 4 37965 284963 287442 24606 0 0 25w4d 1

And you are likely receiving a default route.

Your BGP configuration is correct.

At this point is difficult to understand what is happening.

Are you sure that your company is not multihomed ? I mean if it is also peeing with another upstream ISP?

if so the return traffic from the remote VPN server can come back on the alternate path.

Otherwise, you need to examine the internal topology to see if there any possible bottle neck because the high RTT times for that ping looks like using a satured link.

Check also the router or firewall performing the NAT operations.

Hope to help

Giuseppe

[mudvayne15]

Thanks again, we are using dual-homing right now. I will investigate further and thanks for the help.

[mudvayne15]

hello, how do I block a certain IP from going to the other router since we are dual-homed?

x.x.111.200/30 is the network? I just want to make sure that it's returning back to the router where the traffic originated.

[mudvayne15]

The latency however is the same for our gateway routers but when I try to source it from their public IP x.x.236.61 -- it shows the good result with better latency

cnshaccent-gw-1#traceroute vpn.catonetworks.net so x.x.236.61
Type escape sequence to abort.
Tracing the route to vpn.catonetworks.net (123.59.229.222)
VRF info: (vrf in name/id, vrf out name/id)
1 10.90.45.29 [AS 37965] 2 msec 2 msec 0 msec
2 Gi0-0-0.30.r3.pek3.pbscn.net (222.126.130.170) [AS 37965] 28 msec 28 msec 28 msec
3 Gi0-0-3.r4.pek3.pbscn.net (222.126.130.62) [AS 37965] 28 msec 28 msec 28 msec
4 137.88.202.1.static.bjtelecom.net (1.202.88.137) [AS 37965] 30 msec 30 msec 30 msec
5 *
145.234.120.106.static.bjtelecom.net (106.120.234.145) [AS 37965] 32 msec *
6 36.110.244.42 [AS 37965] 28 msec 28 msec 28 msec
7 220.181.177.190 [AS 37965] 32 msec 32 msec *
8 * * *
9 * * *
10 114.118.0.138 [AS 37965] 30 msec * 30 msec

***Traceroute sourcing from our owned public IP

cnshaccent-gw-1#traceroute vpn.catonetworks.net so x.x111.201
Type escape sequence to abort.
Tracing the route to vpn.catonetworks.net (123.59.229.222)
VRF info: (vrf in name/id, vrf out name/id)
1 10.90.45.29 [AS 37965] 2 msec 2 msec 2 msec
2 Gi1-1-1.r5.sha2.pbscn.net (222.126.129.133) [AS 37965] 80 msec 2 msec 2 msec
3 unknown.telstraglobal.net (210.176.44.53) [AS 37965] 26 msec 28 msec 26 msec
4 i-92.tpei-core01.telstraglobal.net (202.84.137.249) [AS 37965] 30 msec 28 msec 28 msec
5 202.84.138.73 [AS 37965] 42 msec
202.84.138.181 [AS 37965] 50 msec 50 msec
6 202.84.153.54 [AS 37965] 44 msec
i-0-4-0-18.hkhh11.bi.telstraglobal.net (202.84.156.134) [AS 37965] 60 msec
202.84.153.54 [AS 37965] 46 msec
7 219.158.40.233 [AS 37965] 222 msec 224 msec 222 msec
8 219.158.10.29 [AS 37965] 218 msec 218 msec 216 msec
9 219.158.115.157 [AS 37965] 232 msec 226 msec 232 msec
10 219.158.3.29 [AS 37965] 226 msec 224 msec 232 msec
11 219.158.5.145 [AS 37965] 218 msec 218 msec 218 msec
12 123.126.0.126 [AS 37965] 214 msec
202.96.12.178 [AS 37965] 218 msec
61.49.214.6 [AS 37965] 204 msec
13 125.33.185.250 [AS 37965] 214 msec
61.51.169.234 [AS 37965] 228 msec
61.148.157.122 [AS 37965] 214 msec
14 * * *

[Giuseppe Larosa]

Hello @mudvayne15 ,

your enterprise is multihomed with two ISPs.

You can try to influence the return path by using AS prepending to one ISP : that is making an artificial longer AS path by prepending multiple times your own AS number when sending updates to ISP-B.

This action will increase the probability that return traffic will be via ISP-A but it is not a 100% guarantee.

What is really important in multihoming is to avoid to advertise routes coming from ISP-A to ISP-B and viceversa to avoid to become a transit AS.

Hope to help

Giuseppe

[mudvayne15]

Hello, thanks for helping me with this. I noticed a difference in the latency of our Public IPs configured on the router interface. 

GigabitEthernet0/2 ----  x.x.111.201/30

Vlan1 ----- x.x.110.1/24

Network Advertised to ISP:  x.x.110.0 mask 255.255.254.0

cnshaccent-gw-1#ping vpn.catonetworks.net so x.x.110.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.59.229.244, timeout is 2 seconds:
Packet sent with a source address of x.x.110.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/101/104 ms

cnshaccent-gw-1#ping vpn.catonetworks.net so x.x.111.201
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.59.229.244, timeout is 2 seconds:
Packet sent with a source address of x.x.111.201
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 246/246/248 ms

Do you have any idea what may have been causing this? I have attached the current config that we have. I hope you can review my config further.

Thank you

[Giuseppe Larosa]

Hello @mudvayne15 ,

if both source addresses are within the advertised prefix x.x.110.0/23 there is not a possible different return path at least at BGP level.

One address is an SVI and the other one is a routed interface but besides this they are both interfaces of the same router.

Even if gi0/2 would have a lot of traffic on it the increase in RTT would not be explained.

I have looked at your configuration file and I have noticed that loop1 is not used.

I mean I would expect in the router bgp section the following command:

neighbor x.x.236.62 update-source loop1

This may be just a typo and you have missed reporting this line.

On the other hand the eBGP session is established meaning that the configuration is fine.

Hope to help

Giuseppe

[mudvayne15]

Thank you for checking, I just want to know, I thought update-source is
usually used for IBGP and unusual for EBGP?

[Giuseppe Larosa]

Hello @mudvayne15 ,

you are right.

However, when configuring eBGP between loopbacks the update-source command is required.

The use case is when two eBGP routers are connected with two links or more in that case instead of having one eBGP session per link it is better to have an eBGP session between loopbacks.

static routes are needed on each side to allow the eBGP session to be setup and also eBGP multihop 2 or more is needed.

Hope to help

Giuseppe

[mudvayne15]

Thank you

[Vishnu Vardhan S]

I would suggest to check on below points :

1. Use update source loopback at your end. 

2. Reduce the TTL to 2 or max 3 as its only used  for eBGP to form neighborship.

3. The path is changing based on the source address. Please check with the ISP.