Multicast across BGP domains

Hello

Sometimes we may have multicast sources in one BGP domain and receivers in another BGP domain. In this case we need to exchange information across domains about:

  1. routes to get to the source of the multicast traffic
  2. sources of multicast traffic

 

To do 1), we need BGP to share multicast information, not just unicast.

To do 2), we need MSDP, a special TCP application that will inform domain B that domain A has a multicast source.

 

  1. To activate sharing RPF information, that is how to get to a source of multicast traffic, we need to activate a neighbor for a given address family, e.g.router bgp 100
    bgp log-neighbor-changes
    neighbor IBGP peer-group
    neighbor IBGP remote-as 100
    neighbor IBGP update-source Loopback0
    neighbor 150.1.3.3 peer-group IBGP
    neighbor 150.1.6.6 peer-group IBGP
    neighbor 150.1.9.9 peer-group IBGP
    !
    address-family ipv4
    neighbor IBGP route-reflector-client
    neighbor 150.1.3.3 activate
    neighbor 150.1.6.6 activate
    neighbor 150.1.9.9 activate
    exit-address-family
    !
    address-family ipv4 multicast
    neighbor IBGP route-reflector-client
    neighbor 150.1.3.3 activate
    neighbor 150.1.6.6 activate
    neighbor 150.1.9.9 activate
    exit-address-family
  2. We need to establish an MSDP peering on an RP in domain A with the RP in domain B, e.g.
    ip msdp peer 150.1.8.8 connect-source Loopback0 remote-as 200
    ip msdp peer 150.1.5.5 connect-source Loopback0 remote-as 200

Now we have everything we need to get multicast traffic from domain A to domain B. If a host in domain B joins a multicast stream, this info will go to its RP. In domain A, a source starts streaming. This goes to the RP in domain A. Domain A RP informs Domain B RP that it has a streaming source.

ORF short notes

Hello

ORF is a method of limiting routing updates sent from router B to router A by creating a prefix-list on router A and sending it over to router B so that router B applies it outbound towards router A. Why? it is always better to limit routing updates outbound than inbound on the other end because this saves bandwidth.

  1. enable capability on router B
    ROUTER B: neighbor 1.1.1.1 capability orf prefix-list both
  2. create a loopback on router B and advertise it into BGP

int loop22

ip addr 22.22.22.22 255.255.255.255

router bgp 100

network 22.22.22.22 mask 255.255.255.255

3. Enable capability on router A

 

ROUTER A: neighbor 2.2.2.2 capability orf prefix-list both

4. Create a prefix list that denies some prefix and apply it INBOUND (yes, inbound!) towards router B

neighbor 2.2.2.2 prefix-list dontsendloopback22 in

ip prefix-list dontsendloopback22 deny 22.22.22.22/32

ip prefix-list dontsendloopback22 permit 0.0.0.0/0 le 32

5. Soft clear BGP for the prefix filter.

clear ip bgp 2.2.2.2 soft in prefix-filter

6. Watch the filter being applied on router B:

RouterB#show ip bgp neighbors 1.1.1.1 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 1.1.1.1: 2 entries
seq 5 deny 22.22.22.22/32
seq 10 permit 0.0.0.0/0 le 32

 

BGP dampening – how not to use maths

Hello

Today I had a bgp dampening scenario and the task was to calculate what parameters should be used if a route should be reused after 5 minutes.

By default, a flap adds 1000 to the penalty, while the half-life time reduces the penalty by 50%.

Therefore, two flaps will result in a 2000 penalty, which will be reduced by 50% after the half-life time. But what if the reuse threshold is not exactly 50% but less: how will we calculate when the route will be reused?

There is a complex algorithm for that where we can use the logarithmic function to calculate this, but frankly: who will remember this during the exam?

I have a better idea: how about a simple command to show how long until the route is reused?

R3#show ip bgp dampening dampened-paths
BGP table version is 16, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network         From        Reuse     Path
*d 1.1.1.0/24 155.1.13.1 00:00:50 100 i

So now:

  1. add the command neighbor x.x.x.x advertise-interval 0 on router A
  2. Use the bgp dampening command (which by the way creates a handy log if you are debugging: BGP(0): Created dampening structures with halflife time 4, reuse/suppress 750/2000)
  3. Flap the routes that you want to advertise to router B (e.g. shut/unshut loopbacks)
  4. Use the command above to see how long until the route is reused.

3#show ip bgp dampening dampened-paths
BGP table version is 32, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network From Reuse Path
*d 1.1.1.0/24 155.1.13.1 00:05:30 100 i
R3#
EvD: accum. penalty decayed to 1971 after 7 second(s)

We can see that with the half-life time of 4 minutes, suppress penalty of 2000 and reuse threshold of 750, the reuse time is 5minutes 30 seconds.

Obviously, if our goal is e.g. 4 minutes, then the reuse threshold should be 1000.

If our goal is e.g. 6 minutes, how about simply raising the half life time to 6 minutes and setting reuse to 1000?

What is the conclusion? There’s no point in using maths if you can just be clever.

But wait! there’s more! Let’s have a look at how the penalty actually decays: Linearly? i don’t think so…

In this example we turned on debugging and flapped the link 3 times on the other router so the penalty has accumulated to 3000.

BGP(0): flapped 3 times since 00:00:04. New penalty is 3000
EvD: accum. penalty 2956, now suppressed with a reuse intervals of 47
EvD: accum. penalty decayed to 2671 after 35 second(s)        !!! 329 decayed in 35 seconds = 9.3points/sec
EvD: accum. penalty decayed to 2379 after 40 second(s)       !!! 292 points in 40 seconds = 7.27 points/sec
EvD: accum. penalty decayed to 1971 after 67 second(s)    !!! 408 points in 67 seconds = 6.1 pts/sec
EvD: accum. penalty decayed to 1413 after 115 second(s)
EvD: accum. penalty decayed to 1043 after 105 second(s)
EvD: accum. penalty decayed to 864 after 68 second(s)
EvD: accum. penalty decayed to 851 after 6 second(s)
EvD: accum. penalty decayed to 747 after 49 second(s)     !!!104 points in 49 seconds!!!=2pts/sec

Half-life time duly occurred after 4 minutes, but in this case the reuse happened after 483 seconds (>8 minutes).

As you can see, after 35+40+67 = 142 seconds we have 1971 points BUT

after 35+40+67+115+105+68+6+49 = 485 seconds we have still 747 points

So clearly the decay is not linear! Why is that? Of course, to give BGP a longer ”flap memory”, which increases the likelihood that a more reliable path will be kept. In this situation it was enough for the route to flap again once after about 482 seconds and the other route would still be used because the reuse for this path would occur after 483 seconds.

What is the second conclusion, then? If the total penalty was 3000, 1500 happened after 4 minutes, 750 will NOT be reached after 6 minutes which would be the case if the decay was linear. If you don’t want to use maths to calculate the reuse time, it is clearly the best idea to use the show ip bgp dampening dampened-paths command.

 

 

Deaggregating with bgp inject-map

Hello

Let’s say we have an aggregate of 100.0.0.0/21 that we advertise somewhere in our network but we want to advertise also 100.0.1.0/24 to neighbor A, 100.0.2.0 to neighbor B and 100.0.3.0 to neighbor C at different places as best entry points.

We can do this with bgp inject-map.

 

(somewhere in network)

router bgp 100

aggregate-address 100.0.0.0 255.255.240.0 summary-only

network 100.0.0.0 mask 255.255.255.0

 

(near the edge to neighbor A)

router bgp 100

bgp inject-map INJECT exist-map EXIST

 

route-map INJECT permit 10

set ip address prefix-list PARTICULARNETWORK

<any additional parameters here”

route-map EXIST permit 10

match ip address prefix-list AGGREGATE

<any additional conditions here>

 

There is even a nice show command for this:

R7#show ip bgp injected-paths
BGP table version is 22, local router ID is 150.1.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 10.0.1.0/24 155.1.37.3 0 i

bgp update-groups

Hello

I just noticed a useful thing: when displaying received routes it says which updates group this route is later advertised to

R4#show ip bgp 112.0.0.0
BGP routing table entry for 112.0.0.0/8, version 18
Paths: (2 available, best #1, table default)
Advertised to update-groups:
4
Refresh Epoch 1
200 54 50 60
155.1.45.5 from 155.1.45.5 (150.1.5.5)
Origin IGP, localpref 200, valid, external, best
Community: 100:200
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
200 54 50 60, (received-only)
155.1.45.5 from 155.1.45.5 (150.1.5.5)
Origin IGP, localpref 100, valid, external
Community: 100:200
rx pathid: 0, tx pathid: 0

 

and now we can do this:
R4#show ip bgp update-group 4
BGP version 4 update-group 4, internal, Address Family: IPv4 Unicast
BGP Update version : 19/0, messages 0
Topology: global, highest version: 19, tail marker: 19
Format state: Current working (OK, last not in list)
Refresh blocked (not in list, last not in list)
Update messages formatted 1, replicated 1, current 0, refresh 0, limit 1000
Number of NLRIs in the update sent: max 2, min 0
Minimum time between advertisement runs is 0 seconds
Has 1 member:
155.1.146.1

and (from another scenario) we can even see if it’s not advertised to anyone because it has a no-advertise community set inbound.

R2#show ip bgp 51.51.51.51
BGP routing table entry for 51.51.51.51/32, version 18
Paths: (1 available, best #1, table default, not advertised to any peer)
Not advertised to any peer
Refresh Epoch 2
254
192.10.1.254 from 192.10.1.254 (31.3.0.1)
Origin incomplete, metric 0, localpref 100, valid, external, best
Community: no-advertise
rx pathid: 0, tx pathid: 0x0

tricky bgp suppress maps

Hello

I just spent a few minutes working this out…

if we have 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0 /24 networks and we aggregate it with:

aggregate-address 10.0.0.0 255.255.248.0 suppress-map ciscomap

route-map cisco deny 10

match ip address prefix myprefix

ip prefix-list 10.0.3.0/24

 

… then 10.0.3.0 will NOT be suppressed.

suppress-map means suppress these networks that are defined by the route-map. The deny statement in the route-map means do not include these networks in the suppress map that be default suppresses everything if we had only permit statements in the route map.

 

deleted commands… set origin egp

It still exists!

route-map egp permit 10

set origin egp 10

 

and now: clear ip bgp 1.1.1.1 soft in

TADAAAM:

* 205.90.31.0 155.1.13.3 0 200 254 ?
*>i 155.1.45.5 0 100 0 200 254 e
* 220.20.3.0 155.1.13.3 0 200 254 ?
*>i 155.1.45.5 0 100 0 200 254 e
* 222.22.2.0 155.1.13.3 0 200 254 ?
*>i 155.1.45.5 0 100 0 200 254 e

 

if you see this on any cisco router, someone is trolling you big time.

Make a network diagram before you start tshooting

Hello

Today I spent an hour trying to set up a simple as path prepending scenario and I couldn’t make it work. The task seemed impossible because it seemed that the router that was supposed to be making the decision based on the as-path length wouldn’t receive one of the routes, because the routes had its AS in the path already, so the bgp loop condition wasn’t met.

This is an important lesson – always spend time preparing for the task instead of trying to configure everything straightaway. Think, draw, configure. Trying to save time will get you into more trouble than it’s worth.