There are several well-known communities, and these are listed on the IANA website at the URL reference there. There are several common ones, I've listed five of them that are most commonly used. The no-export community I'll show you an example of in a minute. No-advertise is quite useful as well, no-advertise simply means do not advertise this prefix to any BGP peer. For example you may learn a prefix from a neighbor on your border router and you may decide I don't want to announce this to anywhere else in my network. Now the standard way of doing it, you would think yes I'll just put a prefix filter on all my internal BGP sessions. Then you've got to manage it and you've got to update it and you've got to add as more iBGP sessions are set up. What happens if you forget? What could go wrong? Instead it's actually much easier as the prefix comes in tag it with no-advertise. And the BGP sessions when they see the no-advertise attached to the prefix will automatically drop it. Much easier to manage. The no-export-subconfed is all to do with BGP confederations. We'll make short mention of confederations but I'm not going to cover this well-known community outside of that. There's a no-peer community which arrived much more recently. That has some use across the internet today but is not as widely used as many of us had hoped for. What this one does, it lets operators know not to advertise this prefix to the peers. This is bilateral peers, as opposed to upstream transit providers. As I say, some operators have used it, many operators are simply unaware that this useful community actually exists. The idea behind it is to ensure that we don't end up filling the global default-free zone full of traffic engineering prefixes in BGP, and again I've got a short example to show you how it works. The final one is the Blackhole community. This is the most recent defined well-known community, RFC7999. And this is to null route a prefix. If the prefix is announced to a neighbor with the Blackhole community set, it tells the neighbor to null route any traffic to that prefix. It's extremely useful for the Remote Triggered Black Hole filtering BGP security feature that is widely used on the internet today to help defeat denial of service attacks. We'll now look at the no-export community. The no-export community tells the neighboring AS not to announce this prefix to any other autonomous system. It's most commonly used in load balancing situations when your're multihoming with a neighboring AS. So the example I have here, has three links between AS 100 and AS 200. The traditional way of multihoming as we'll see later on in this series, is to announce the aggregate on all three links, as well as announce three subnets of the aggregate, one on each link. The subnets we will announce with the no-export community. And that will tell the neighboring AS, AS 200, not to announce the subnets to the wider Internet. Router G will spot the no-export community and not announce these prefixes to any other operator that it connects to. So the intention here is really to implement the traffic engineering between AS 100 and 200 without leaking local traffic engineering prefixes to the global Internet. As we've mentioned already the default-free zone in the global Internet is a very, very large number of prefixes, 660,000 in October 2017, and this number is only growing. Again, mostly caused by traffic engineering prefixes leaking out into the wider internet. So the no-export community is very, very useful community intended to help deal with this big growing problem on the Internet. The second one I want to show is the no-peer community. The no-peer community, as you can see in the diagram, is intended to let upstream networks know to only send this prefix to the upstreams and not to their bilateral peers. So we start off in router A. Again, we're trying to load balance we send the aggregate to our 3 upstreams. and we send the traffic engineering subnets with no peer attached to them, one on each link. Now the upstream operators that peer with each other, C, D, and E, in the diagram, they're all peers, for example they might be tier ones. All they want to see and all they need to see, are the actual aggregates they don't need to see the sub-prefixes. The sub-prefixes, you have sent with the no-peer community attached to them. So the border routers on those upstream providers will not send those subnets tagged with no-peer. Now I've talked about the format in RFC1998 as being: <AS number>:<Any other number>. We've taken the 32-bit attribute and divided it into two 16-bit integers. But as we've seen already, AS numbers are now 4-bytes, 32-bits. So what happens if you have a 32-bit AS number, an AS number bigger than 65535? You can't use this "standard" or so-called "standard" practice. Even though this is just a convention, a convenient convention used by operators, it's not standardized. But this is now so fixed in operational community best practices, that we tend to expect the format is now: <AS number>:<Some local number you define>. So the solutions, certainly over recent years, has been to use a private AS number for the first 16-bits. More recently, RFC8092 has defined BGP large communities, this was standardized in early 2017. And this is a new BGP attribute to deal with the case, nowadays, where most operators have 4-byte AS numbers. So the BGP large community attribute is a new attribute designed to accommodate the local 32-bit AS number, a Local Operator Defined Action, which can be up to 32-bits big, and a Remote Operator Defined Action, which also is 32-bits big. Which allows operators using 32-bit AS numbers to peer with others using 32-bit AS numbers and define policy actions as well. So this is much superior to the original community definition which only accommodated 16-bits of ASN's and 16-bits of action. So I've got some examples here showing common community conventions. And we're going to cover this in much more detail later on in this series. So the first example, 131072:3:131074, that might be AS 131072 requesting AS 131074 to do a three times prepend of this prefix on AS 131074's peerings. It means that AS 131074 has to look out for this community, and do three times prepend on it's peerings for AS 131072 prefixes. Or what about 131072:0:131074? AS 131072 requests AS 131074 not to announce this prefix at all. Again, using common conventions for what some of these policy numbers mean in BGP communities.