I just want to share here a note-to-myself about route-maps and IPv4/IPv6 BGP prefixes matching.
R1 and R2 were BGP speakers, R1 was announcing both IPv4 and IPv6 prefixes to R2 and I wanted to set, let’s say, different weights on those prefixes: weight = 4 to the IPv4 prefix and weight = 6 to the IPv6 prefix. It’s stupid, of course, but it’s just to simplify the real task I had to face. 🙂
Such as IPv4 addresses, 2-byte pool of Autonomous System (AS) Numbers is going to be exhausted soon. By the time I’m writing, it seems Internet will run out of 16-bit AS Number on 26-Sep-2012. To prevent this situation, IANA extended the AS Number field to 32 bits and, on 2007, RIRs started assigning them… or, at least, to offer them!
Of course, in order to let 4-byte ASN to work properly, a little adjustement was needed in the BGP protocol. Enter RFC 4893, BGP Support for Four-octet AS Number Space.
In this post I don’t want to cover the mechanisms of this protocol extension, if you want to understand them I please you to follow some links in the References section; I prefer to show some interactions between OLD 2-byte ASN and NEW 4-byte ASN BGP speakers. I built a little GNS3/Dynamips lab using a couple of 7200s with IOS 12.2(33)SRE as NEW speakers, and a couple of 3640s as OLD peers.
In the topology every router announces any subnet to the others; BGP peering sessions follow the physical topology. Green ASs support 4-byte AS, while gray do not.
For the sake of readibility I’ll use asdot notation in this post, with the exception of some configuration blocks where I’ll use asplain just to show both notation usage.
I also uploaded two packet captures on PacketLife.net: they show BGP UPDATES with and without the NEW_AS_PATH attributes. They are 4-byte_AS_numbers_Full_Support.cap and 4-byte_AS_numbers_Mixed_Scenario.cap.
Router A is on AS 10.1 / 655361 (asdot / asplain notation):
A#sh run | sec bgp router bgp 655361 no synchronization bgp log-neighbor-changes network 10.0.0.0 neighbor 172.16.3.2 remote-as 2 no auto-summary B#sh run | sec bgp router bgp 2 no synchronization bgp log-neighbor-changes network 20.0.0.0 neighbor 172.16.3.1 remote-as 23456 no auto-summary
As you can see, on router B neighbor statement we can’t use the real ASN to peer with A, so we have to use the AS_TRANS (23456). Let’s wait until our sessions come up, then show BGP neighbors and tables:
A#sh ip bgp neighbors 172.16.3.2
BGP neighbor is 172.16.3.2, remote AS 2, external link
BGP version 4, remote router ID 20.0.0.1
BGP state = Established, up for 00:00:27
Last read 00:00:27, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is not multisession capable
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised
Address family IPv4 Unicast: advertised and received
Multisession Capability: advertised
...
Please note the Four-octets ASN Capability: advertised line: A advertised this capability but did not receive it back from B.
A#sh ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 0.0.0.0 0 32768 i *> 20.0.0.0 172.16.3.2 0 0 2 i
As expected, A receives the B‘s route but…
B#sh ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 172.16.3.1 0 0 23456 i *> 20.0.0.0 0.0.0.0 0 32768 i
… B only sees A‘s subnet as from AS_TRANS (23456).
This is because B does not support 4-byte ASN, and router A knows this (capabilities exchange during session setup), so it just sends AS_PATH attributes containing the 16-bit AS_TRANS in place of the real 32-bit AS number.
You can find a similar UPDATE on the first capture I sent on PacketLife.net (4-byte_AS_numbers_Mixed_Scenario.cap), packet number 2.
Let’s setup the BGP session between routers A and D; they both support 4-byte ASN.
A#sh run | sec bgp router bgp 655361 no synchronization bgp log-neighbor-changes network 10.0.0.0 neighbor 172.16.1.2 remote-as 2621441 neighbor 172.16.3.2 remote-as 2 no auto-summary D#sh run | sec bgp router bgp 2621441 no synchronization bgp log-neighbor-changes network 40.0.0.0 neighbor 172.16.1.1 remote-as 655361 no auto-summary
When sessions come up…
A#sh ip bgp neighbors 172.16.1.2
BGP neighbor is 172.16.1.2, remote AS 40.1, external link
BGP version 4, remote router ID 40.0.0.1
BGP state = Established, up for 00:04:04
Last read 00:00:46, last write 00:00:53, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is multisession capable
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Multisession Capability: advertised and received
...
Here A both sent and received the 4-byte ASN capability to/by B, because it supports this feature.
A#sh ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 0.0.0.0 0 32768 i *> 20.0.0.0 172.16.3.2 0 0 2 i *> 40.0.0.0 172.16.1.2 0 0 2621441 i D#sh ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 172.16.1.1 0 0 655361 i *> 20.0.0.0 172.16.1.1 0 655361 2 i *> 40.0.0.0 0.0.0.0 0 32768 i
Both A and D have subnets with the full 32-bit AS number.
You can see the capture on the file 4-byte_AS_numbers_Full_Support.cap on PacketLife.net.
As I already said, let’s switch to asdot notation now, just to improve readibility:
D#conf t Enter configuration commands, one per line. End with CNTL/Z. D(config)#router bgp 40.1 D(config-router)#bgp asnotation dot D(config-router)#do show ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 172.16.1.1 0 0 10.1 i *> 20.0.0.0 172.16.1.1 0 10.1 2 i *> 40.0.0.0 0.0.0.0 0 32768 i A#conf t Enter configuration commands, one per line. End with CNTL/Z. A(config)#router bgp 10.1 A(config-router)#bgp asnotation dot
Ok, 10.1 is better than 655361, and 40.1 than 2621441!! 🙂
Let’s have more fun now and bring D-B session up!
D(config-router)#neighbor 172.16.2.1 remote-as 2 B(config-router)#neighbor 172.16.2.2 remote-as 23456
As we already saw, B doesn’t support 4-byte ASN, so we have to use AS_TRANS to peer with D.
D#show ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path * 10.0.0.0 172.16.2.1 0 2 10.1 i *> 172.16.1.1 0 0 10.1 i *> 20.0.0.0 172.16.2.1 0 0 2 i * 172.16.1.1 0 10.1 2 i *> 40.0.0.0 0.0.0.0 0 32768 i
The interesting thing we can see now on D is the presence of A‘s subnet (10.0.0.0) advertised by B: even if B does not support 4-octect ASN, D receives it with the real 32-bit path. When A advertises the subnet to B it makes the AS_PATH attribute up using AS_TRANS, but it also adds the transitive attribute NEW_AS_PATH, containing the full 32-bit AS numbers; when B advertises the subnet to D it adds this attribute and so D can rebuild the real 32-bit path.
As before, you can find a similar UPDATE on the capture I sent on PacketLife.net; the file is 4-byte_AS_numbers_Mixed_Scenario.cap, packet number 3.
Another interesting aspect of 4-byte AS lack of support can be seen in the following table:
B#sh ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path * 10.0.0.0 172.16.2.2 0 23456 23456 i *> 172.16.3.1 0 0 23456 i *> 20.0.0.0 0.0.0.0 0 32768 i *> 40.0.0.0 172.16.2.2 0 0 23456 i * 172.16.3.1 0 23456 23456 i
Here B has two entries for the 10.0.0.0 subnet: they both seem to be originated from the same AS, but that’s not true: the first comes from D (AS 40.1), while the second (the selected one) comes directly from A.
Similar behaviour is for the 40.0.0.0 subnet. Of course, this is not a really big problem, but may lead to false assumptions and compromise traffic patterns analysis.
Just to complete all the possible scenarios, here is C configuration:
B#conf t Enter configuration commands, one per line. End with CNTL/Z. B(config)#router bgp 2 B(config-router)#neighbor 172.16.4.2 remote-as 3 C#sh run | sec bgp router bgp 3 no synchronization bgp log-neighbor-changes network 30.0.0.0 neighbor 172.16.4.1 remote-as 2 no auto-summary C#sh ip bgp | beg Network Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 172.16.4.1 0 2 23456 i *> 20.0.0.0 172.16.4.1 0 0 2 i *> 30.0.0.0 0.0.0.0 0 32768 i *> 40.0.0.0 172.16.4.1 0 2 23456 i
It has no idea of what 4-byte ASN are, so it sees both 10.0.0.0 and 40.0.0.0 subnets as originated from the same AS.
I have to say thanks to Marco Rizzi for his kind support on helping me to build this lab! 😉 And, of course, I suggest you to visit his blog: Marco Rizzi Blog – networking with passion!!!
To download the lab and configuration files click here.
Report on consumption of AS Numbers: http://www.potaroo.net/tools/asns/
BGP Support for Four-octet AS Number Space: RFC 4893
APRICOT 2007: 4-Byte AS Numbers (PDF)
Cisco.com: Migration Guide for Explaining 4-Byte Autonomous System
Cisco.com: Cisco IOS BGP 4-Byte ASN Support
Cisco.com: Explaining 4-Byte Autonomous System (AS) ASPLAIN and ASDOT Notation for Cisco IOS
After the brief overview about the installation of flow-tools and FlowViewer, in this post I’d like to share my experience about the setup of a basic solution based on another pair of tools: NFDUMP and NfSen. As always on my posts, the starting point is a fresh Debian 5.0 setup.
UPDATE: you may be interested in FlowGraph too, a tool that allows to dynamically build graphs based on previously collected netflow data and to use them in a web-based front-end, adding details about Autonomous System Number holders, IPv4 and IPv6 prefixes, inet(6)num objects, netnames from RIPE Stat.
Working with FlowViewer and flow-print (from the flow-tools suite), if you filter some NetFlow data by TCP flags you may notice a weird behaviour, like the one in the following picture:
FlowViewer - TCP Flags
Here I applied a filter on TCP Flags = 27, but on the output I had the “Fl” (Flag) column reporting 3! What’s up? Is 3 a kind of alias for 27? Is this a math puzzle? None of this!
NetFlow is a very useful tool/protocol to monitor network traffic’s patterns. Many tools have been developed to collect and analyze NetFlow data, here I chose flow-tools and FlowViewer packages, and I would like to show how to get them work on a fresh Debian 5.0 (Lenny) setup.