Disabling PVST simulation on an MST>RSTP link

Hello

Two situations are possible on a link between an MST region and a non-MST region:

  • either the root for all vlans is in the MST region OR
  • the root for all vlans is in the non-MST region

To meet the condition, BPDU for vlans other than 1 needs to be identical or better than BPDU for vlan 1. This means e.g:

priority for vlan 1 = 8192 + system-id (1)

priority for all other vlans = 4096 + system-id (2 or higher).
This is called PVST simulation. We can disable it on the port with the command:

spanning-tree mst simulate pvst disable.

After enabling this, the port between the MST region and non-MST region will be blocked.

 

 

OSPF capability transit

capability transit

If we want to get from router on the left to the router on the far right, the cost is only 100 through area 1; however, OSPF says we need to go through area 0 to go to another area UNLESS capability transit flag is ON.

On cisco routers it is ON by default, so we actually pick the lower cost path even though it is in area 1.

Step 1: create a virtual link to the first router in area 1 (see further below)

Step 2: issue show ip ospf topology-info

 

R4#show ip ospf topology-info

OSPF Router with ID (10.1.4.4) (Process ID 1)
Base Topology (MTID 0)

Topology priority is 64
Router is not originating router-LSAs with maximum metric
Number of areas transit capable is 2
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Area BACKBONE(0)
SPF algorithm last executed 00:00:26.936 ago
SPF algorithm executed 113 times
Area ranges are
Area 14
This area has transit capability: Virtual Link Endpoint
SPF algorithm last executed 00:09:24.535 ago
SPF algorithm executed 5 times
Area ranges are
Area 45
This area has transit capability: Virtual Link Endpoint
SPF algorithm last executed 00:09:24.535 ago
SPF algorithm executed 7 times
Area ranges are
Area 47
SPF algorithm last executed 00:09:24.535 ago
SPF algorithm executed 4 times
Area ranges are

Important: you can only route in this way if there is a shorter Inter-Area pathvia a non-area 0 router. So if the router in area 1 at the bottom suddenly gained an additional link in area 0, it would no longer be possible to route through area 1. ***Unless we create a virtual link from the router on the left to the bottom router.

Just having capability transit ON does NOT mean that if, for example, we will simply go through the path of lower cost (e.g. the path through area 0 = 50000 and path through a different area is 1000).

If we look at RFC, it says that we need to enable a virtual link to a router in this area! see https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/212607-ospf-virtual-links-transit-capability.html for details.

TransitCapability is set to TRUE
        if and only if there are one or more fully adjacent virtual
        links using the area as Transit area), and is used as an input
        to a subsequent step of the routing table build process (see
        Section 16.3). When an area's TransitCapability is set to TRUE,
        the area is said to be a "transit area"

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.

Multicast helper

Hello

We can use a multicast helper to ”transport” broadcast traffic onto a different segment.

multicast_helper

Everybody is familiar with unicast helper which changed broadcast into directed unicast traffic, for example if a DHCP server is outside the broadcast segment. Here the idea is similar: we would like to change broadcast into multicast.

  1. R1 sends broadcast traffic to 155.1.12.255 udp 3000
  2. R2 does 3 things:

a) adds udp 3000 to its list of protocols that it can forward,

ip forward-protocol udp 3000

b) enables multicast helper on the link R1>R2, and maps the broadcast traffic to a multicast address, defining an ACL which defines which traffic should mapped.

ip multicast helper-map broadcast 226.0.0.1 MYTRAFFIC

ip access-list extended MYTRAFFIC

permit udp any any eq 3000

permit udp any any eq 53

c) enables ip pim dense-mode on all links

int eth0/0.12

ip pim dense-mode

int eth0/0.23

ip pim dense-mode

3. R3 also does the same three things (and one extra):

a) adds udp 5000 to its list of protocols that it can forward,

b) enables helper on interface R2>R3 and maps the multicast traffic onto its broadcast segment defining an ACL that says which traffic should be mapped

ip multicast helper-map 226.0.0.1 155.1.33.255 MYTRAFFIC !!!but without the word broadcast this time!!!

permit udp any any eq 3000

permit udp any any eq 53

c) enables dense mode on both links

int eth0/0.23

ip pim dense-mode

int eth0/0.33

ip pim dense-mode

d) additionally, on its broadcast segment it needs two commands:

int eth0/0.33

ip directed-broadcast

ip broadcast-address 155.1.33.255

 

Test this by enabling ip domain-lookup on R1 but not specifying domain server. The lookups will start anyway, sending traffic to udp port 53.

This is debug from R3.

access-list 100

permit udp any any eq 53

debug ip packet detail 100

 

Output:

IP: tableid=0, s=155.1.12.1 (Ethernet0/0.23), d=155.1.33.255 (Ethernet0/0.33), routed via RIB
IP: s=155.1.12.1 (Ethernet0/0.23), d=155.1.33.255 (Ethernet0/0.33), len 50, sending full packet
UDP src=53300, dst=53
MFIBv4(0x0): Pkt (155.1.12.1,236.0.0.1) from Ethernet0/0.23 (PS) accepted for forwarding
IP: s=155.1.12.1 (Ethernet0/0.23), d=236.0.0.1 (Ethernet0/0.33), len 50, output feature
R8#
UDP src=53300, dst=53, MFIB Adjacency(86), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
IP: s=155.1.12.1 (Ethernet0/0.23), d=236.0.0.1 (Ethernet0/0.33), len 50, sending full packet

 

Multicast stub router

If we have R1>R2>R3, where R1 is an HQ main router and R2 a remote office router, there is little point in asking R2 to spend resources on multicast states, since all it does is forward packets to and from the HQ.

  1. We should therefore configure R8 to ask R5 to hold its IGMP group states with the command:

ip igmp helper-address <address of the link of R5 towards R8>

2. Then let’s make R8 as ”stupid” as possible by making its PIM dense towards R5 and R10 (where hosts are connected).

int eth0/0.58

ip pim dense-mode

int eth0/0.108

ip pim dense-mode

3. Next, let’s prevent R8 from establishing a neighbor relationship with R5 or R10 (it should only forward multicast packets!) with:

eth0/0.58

ip pim neighbor-filter 58

eth 0/0.108

ip pim neighbor filter 108

 

access-list 58 deny 155.1.58.5

access-list 58 permit any

access-list 108 deny 155.1.108.10

access-list 108 permit any

4. On R10, PIM DM must also be enabled on the link towards R8. Let’s also join a group.

eth0/0.108

ip pim dense-mode

ip igmp join-group 225.0.0.10

 

Now R5 will see the hosts as if they were directly connected to R5. R5 will use sparse mode to create the tree, R8 will use dense mode, and R10 will use dense mode to process received multicast traffic.

IGMP snooping and AutoRP

Hello

Another (reasonably) tough tshooting ticket:

Logical topology

R5>R8>R10

I turned on autoRP announce on R10 and autoRP discovery on R8. Result? R8 was not getting announce packets from R10. I tried everything then had an idea:

Physical topology is actually

R5>SW1>R8>SW1>R10

I turned off IGMP snooping on interfaces leading to R8 and R10 and R5 on SW1. Everything started working fine.

 

 

Multicast tshooting fail

Hello

Just found something funny when fighting multicast labs. I’ve joined an igmp group on R6 and I was trying to ping it from R10 but getting no responses from R6.

I enabled debugging and saw these mysterious entries. Google is not (!!!) helpful at all with this.

R6#debug ip mfib pak
MFIB IPv4 pak debugging enabled for default IPv4 table
R6#
MFIBv4(0x0): Pkt (155.1.108.10,239.6.6.6) (FS) lookup miss, dropping
R6#
MFIBv4(0x0): Pkt (155.1.108.10,239.6.6.6) (FS) lookup miss, dropping
R6#
MFIBv4(0x0): Pkt (155.1.108.10,239.6.6.6) (FS) lookup miss, dropping
R6#
MFIBv4(0x0): Pkt (155.1.108.10,239.6.6.6) (FS) lookup miss, dropping
R6#
MFIBv4(0x0): Pkt (155.1.108.10,239.6.6.6) (FS) lookup miss, dropping
R6#
MFIBv4(0x0): Pkt (155.1.108.10,239.6.6.6) (FS) lookup miss, dropping

It was a multiaccess ethernet interface and when I joined this group on another router, I was getting responses from the other router so there had to be something wrong with R6.

And of course, there was.

R6#show ip mroute
IP Multicast Forwarding is not enabled.
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry, E – Extranet,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report,
Z – Multicast Tunnel, z – MDT-data group sender,
Y – Joined MDT-data group, y – Sending to MDT-data group,
G – Received BGP C-Mroute, g – Sent BGP C-Mroute,
N – Received BGP Shared-Tree Prune, n – BGP C-Mroute suppressed,
Q – Received BGP S-A Route, q – Sent BGP S-A Route,
V – RD & Vector, v – Vector, p – PIM Joins on route
Outgoing interface flags: H – Hardware switched, A – Assert winner, p – PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

 

I think that this is the real value of doing these labs. You learn stuff the hard way. But why oh why does IOS not shout that multicast is not enabled if you join an igmp group on it?

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.