Tag Archives: BGP

I recently came across an excellent draft at IETF by Job Snijders & friends. This is to address scenarios where a network might miss communication about a maintenance activity when BGP shutdown happens. Once implemented, this can potentially offer to send peer a message with up to 128 bytes with info about shutdown like “Ticket XXX: We are upgrading the router, will be back live in 1hr” etc. It depends by appending such data to the sys notification which is part of BGP protocol. This is one which sends a message just before the shutdown of the session. So it similar to the way you see session tearing down due to prefix limits etc. This has already been implemented in some of the open source routing implementations like OpenBGPd, GoBGP, PMacct, Exabgp etc.

So this blog post is about ways for generating filter config for a given ASN via IRR. One can use such logic with some kind of remote login mechanism like rancid (look for mtlogin here).

I tried building around bgpq3 but it seems more easy with another popular tool in the domain called IRR Power Tools. Once IRR Power Tools (IRRPT) is setup, it allows us to fetch prefixes based via Internet Routing Registries and also aggregates them.

So, for instance, let’s pick AS54456:

1

2

3

4

5

6

7

8

9

10

anurag@tools:~/irrpt$ bin/irrpt_fetch 54456

Processing AS54456 (Record 1)

- Importing /home/anurag/irrpt/db/54456 version 1.1

- Importing /home/anurag/irrpt/db/54456.4 version 1.1

- Importing /home/anurag/irrpt/db/54456.6 version 1.1

- Importing /home/anurag/irrpt/db/54456.agg version 1.1

- Importing /home/anurag/irrpt/db/54456.4.agg version 1.1

- Importing /home/anurag/irrpt/db/54456.6.agg version 1.1

Completed processing of 1 IRR object(s).

anurag@tools:~/irrpt$

So now we have got prefixes and this includes both basic route objects as well as aggregates.

1

2

3

4

5

6

7

8

9

anurag@tools:~/irrpt$ cat /home/anurag/irrpt/db/54456.4

199.116.76.0/24

199.116.77.0/24

199.116.78.0/24

199.116.79.0/24

anurag@tools:~/irrpt$

anurag@tools:~/irrpt$ cat /home/anurag/irrpt/db/54456.4.agg

199.116.76.0/22

anurag@tools:~/irrpt$

It offers a nice interface for generation of config for Cisco, Juniper, Extreme, Foundry and Force10. Example:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

anurag@tools:~/irrpt/bin$./irrpt_pfxgen-fcisco54456

conft

no ip prefix-list CUSTOMER:54456

no ipv6 prefix-list CUSTOMERv6:54456

ip prefix-list CUSTOMER:54456permit199.116.76.0/22le24

end

write mem

anurag@tools:~/irrpt/bin$

anurag@tools:~/irrpt/bin$

anurag@tools:~/irrpt/bin$./irrpt_pfxgen-fjuniper54456

policy-options{

replace:policy-statement CUSTOMER:54456{

termprefixes{

from{

route-filter199.116.76.0/22upto/24;

}

thennext policy;

}

thenreject;

}

}

policy-options{

replace:policy-statement CUSTOMERv6:54456{

termprefixes{

from{

}

thennext policy;

}

thenreject;

}

}

anurag@tools:~/irrpt/bin$

So I put a routeros instance in a VM to test and create config from their CLI. Config looks something like this:

This seems logical and can be scripted. So one can have a script to read the aggregate file and if aggregate says /24 one can put it directly in the filter else allow filter up to /24 from whatever range the pool starts and similar logic in IPv6.

The config between ***start*** and ***end*** can be pasted directly in CLI with Mikrotik. I would not recommend using it for manual filtering of any larger network. Automated filtering where filters are generated regularly makes sense but manual filtering without automation can be damaging. One can use a script like this for connecting to smaller networks. Also, IRRPR offers diff management via CVS (I hope they come up with git on that part) and it comes with an option to trigger email update so Network admins can know when to manually update. I would prefer that for non-commit based platforms since with Cisco ios or Mikrotik routeros it can be tricky to auto update prefix list. If one does no ip prefix list before triggering update it will cause a major noticeable impact. So ideal way to manage that on non-commit based devices would be to maintain a list of prefixes separately in the plain text file or a database and diff it against old one & only push for changes. Do-able and should be preferred that way instead of deleting and re-adding the whole list while automating.