Wyróżnione

become an IT expert with #humanITy

john_whitelbow

My name is Tomek De Wille. I’m the owner of humanITy, a small IT training shop for all those of you who want to change their lives and believe they can.

I used to be a language teacher but in 2009 I had a sudden change of heart. I knew I could do more than teach. I joined Nokia as a technical editor and started learning about networks. Fast forward to 2017 and i’m a senior network engineer, troubleshooting networks all around the globe. Because I still love teaching, i’ve created humanITy – a home for anyone who wants to become an IT expert. We run IT courses on Saturdays and Sundays in the beautiful city of Wroclaw, the very heart of Europe.

For a very brief (and very true) explanation of why we founded humanity, see this 3minute youtube video

If you speak English and would like to start a successful career in IT, have a look at our site http://www.humanity.pl

Follow our blog for discount codes, information on new and exciting IT courses and much, much more.

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.

 

Important: you can only route in this way if there is a shorter Inter-Area pathvia a non-area 0 router. So if we 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.

GNS3 config import problem with non-UTF config files

Hello

Today I spent like an hour when my GNS3 couldn’t properly import configs and would give the following output in the console:

Traceback (most recent call last):
File „/usr/share/gns3/gns3-gui/lib/python3.5/site-packages/gns3/qt/__init__.py”, line 241, in partial
return func(*args, **kwargs)
File „/usr/share/gns3/gns3-gui/lib/python3.5/site-packages/gns3/http_client.py”, line 652, in _processResponse
callback(params, server=server, context=context, raw_body=raw_body)
File „/usr/share/gns3/gns3-gui/lib/python3.5/site-packages/gns3/qt/__init__.py”, line 241, in partial
return func(*args, **kwargs)
File „/usr/share/gns3/gns3-gui/lib/python3.5/site-packages/gns3/dialogs/file_editor_dialog.py”, line 69, in _getCallback
self.uiFileTextEdit.setText(raw_body.decode(„utf-8”))
UnicodeDecodeError: ‚utf-8’ codec can’t decode byte 0xff in position 0: invalid start byte

It turned out that there were some weird chinese characters at the beginning of the files, which in the hex editor looked as follows:

EFBFBDEF BFBD

As usual, the solution is simple: the txt files I had were not in the UTF-8 format. With the application UTFcast Express you can convert your non-utf files into the UTF format.

Now I can go back to my labs…

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.