2007 Sep 14 - Fri
IP Addressing Best Practices (plus VRF and VLAN ideas)
I've encountered many weird and wonderful IP Addressing schemes during my consulting
engagements. During my early years, I'm sure I've contributed some less than optimal ideas
into the mix. I'm going to try to mend my ways and introduce some ideas that I think make
things better.
Since the advent of Network Address Translation, network designers/architects/engineers
have three basic address ranges from which to choose. These address ranges are based upon
what is known as RFC 1918
- Address Allocation for Private Internets. The three ranges are:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
These are, what some call non-routable addresses. To be more specific, routers routing
public addresses, will typically drop (not route) packets having destination addresses from
these ranges. Of course, private networks are free to route these addressess as they see
fit.
The commentary below assumes a basic knowledge of ip addressing, subnet allocation,
host addressing, and routing.
When starting with small networks, a network installer may
simply choose some random /24 block from one of the three ranges, and start assigning
addresses to all devices on the network to that block. When installing IP Phones, some
similar rationale may be used to pick some onother block for the phones. Some rationales
that I've see included:
- let's choose 10.20.10.x for workstations and 10.20.20.x for phones, it keeps them in a
similar big block, and keeps the octents nice workable numbers
- let's choose 10.20.30.x for workstations and 192.168.30.x for phones, it keeps them
separate and identifiable, but yet similar in one octet
- let's add 172.20.30.x as a network management block as it is something completely
different and identifiable as being not normal traffic
I'm sure you can come up with many other mechanisms. But what happens when you want to
get another office joined in? Then suddenly one has a bunch of different blocks one has to
add into a routing table. The lazy answer would be to simply use a statement like 'network
10.0.0.0'. There. All routes for that block are automatically known and added into the
routing table (syntax and concept varies a bit depending upon which routing protocol you
use).
I'm not sure if that is an optimal solution. I generally like to be very specific about
which subnets or supernets I allow into a network table. With addressing scattered through
three different address ranges, detailed route table maintenance becomes time consuming.
I like to use route aggregation whenever possible.
I left that statement by itself as it is a very powerful statement. It is also a
strong, guiding principle in network/routing table design.
I've used that to come up with a hierarchical addressing structure that works with many
of my client sites. There are some scalability issues for very large organizations with
many large offices. For the majority of organizations, I think the following scheme works
well. As I'm in Bermuda, Bermuda is the center of my universe, and the numbering is based
partially on that concept. There is nothing saying you can't change things to match your
own geographic realities.
Since the 10/8 address range has the most number of addresses to work with, I use that
as a basis for most schemes. The hiearchy I use follows this pattern. I'll break the last
three octets into a bit map and assign meanings:
octet bitmap:
00001010.wwwxxxxx.yyyyzzzz.00000000
bitmap meanings:
www: region (NA (001), SA (010), Europe (011), PacRim (101), Asia (100)
xxxxx: country [ BM 1, CA 2, US 3, UK 1, IR 2 ]
yyyy: city [ HAM,BM 1; NY,US 1; PA,US 2 ]
zzzz: VLAN
The region numberse, starting at 1, are loosley based upon contintents and how
inter-country fibres are run.
These categories help with aggregation. Within a region, countries are numbered, starting
at 1. Within a country, cities are numbered starting at 1. I start the numbering for each
bit section at 1, as I use the 000, 00000, and 0000 portions for addressing of inter-region,
inter-country, and inter-city links. You can't really aggregate those addresses into the
routes of either site, so they need to be kept separate.
Therefore, for a site in Hamilton, Bermuda, addressing would start at 10.33.16.0.
Addresses from the range 10.33.0.0 to 10.33.15.255 would be used for inter-city links.
Addresses from 10.32.0.0 to 10.32.255.255 would be used for inter country links. Addresses
from 10.0.0.0 to 10.31.255.255 would be used for inter-region links. Ip address utilization
in this range is acknowledged to be quite sparse.
You'll note that this scheme breaks when you have coverage in more than 15 cities. Therefor
the scheme needs to be adjusted based upon how many locations you have, how many
buildings in each location, and how many floors in each location. It doesn't matter how the
bit map is structured, just so long as some rule for aggregation is followed as the level of
aggregation grows.
At each site, I've been refining a strategy for vlan and ip address block assignments.
Sixteen is a base(2) number, and therefore easy to aggregate. I assign 16 /24 blocks and 16
VLANs per site using a strategy similar to:
+0 Subnets for /30 links
+1 Servers
+2 Server ILO Ports
+3 SAN, iSCSI Traffic
+4 Voice Servers & Gateways
+5 Lab/Classroom/Testing
+6 Spare, To Be Assigned
+7 DMZ
+8 Workstations
+9 Phones
+10 Wireless Corporate
+11 Wireless Phones
+12 Wireless Guest
+13 Wired Guest
+14 Printers
+15 Network Management
The first set of eight blocks are server related. The second block of eight are client
related. If an organization has mulitiple floors, conceivably a sequential block of eight
would be assigned to each additional floor.
For VLAN numbering, I have a couple of different schemes. One scheme starts at VLAN 100
and assigns vlans 100 through 115 to each /24.
A second scheme is more complicated. In some locations, I use VRF's to segragate and
route traffic. VRF's are handy when you have guest traffic you want to keep separate from
corporate traffic. Cisco has a number of SRND documents on how this is accomplished.
Anyway, I've used up to 5 segragations: 1 global routing table plus four VRF's:
1XX global 100
2XX vrfExterior 200
3XX vrfData 300
4XX vrfVoice 400
5XX vrfGuest 500
The first column is are the VLAN identifying numbers, the second is the VRF name, and the
third column is the OSPF process number. By adding this numbering scheme to the VLAN types
previously provided, the following table might be used, where column 1 is the VLAN ID,
column 2 is a relative offset of a sequential VLAN numbering system, and the third column is
the description:
+0 Subnets for /30 links
301 +1 Servers
302 +2 Server ILO Ports
303 +3 SAN, iSCSI Traffic
304 +4 Voice Servers & Gateways
305 +5 Lab/Classroom/Testing
+6 To Be Assigned
+7 DMZ
308 +8 Workstations
309 +9 Phones
310 +10 Wireless Corporate
311 +11 Wireless Phones
512 +12 Wireless Guest
513 +13 Wired Guest
314 +14 Printers
115 +15 Network Management
Some don't have VLANs as they don't exist as VLANS, but are address ranges uses elsewhere
at the site.
Here are some additional VLAN assignments I'll use:
- 1: turned off, or not used at all
- 2: trunk native VLAN
- 3: 802.1x unauhtorized clients
- 20 - 29: switch SPAN ports for various monitoring activities
- 299: vrfExterior router to firewall exterior
- 399: vrfInterior router to firewall interior
- 599: vrfGuest router to firewall interior
Here is a finished table for showing address assignments for two different locations:
VLAN Offset BM Office NY Office
+0 10.33.16.0 10.35.16.0 Subnets for /30 links and loopbacks
301 +1 10.33.17.0 10.35.17.0 Servers
302 +2 10.33.18.0 10.35.18.0 Server ILO Ports
303 +3 10.33.19.0 10.35.19.0 SAN, iSCSI Traffic
304 +4 10.33.20.0 10.35.20.0 Voice Servers & Gateways
305 +5 10.33.21.0 10.35.21.0 Lab/Classroom/Testing
+6 10.33.22.0 10.35.22.0 To Be Assigned
+7 10.33.23.0 10.35.23.0 DMZ
308 +8 10.33.24.0 10.35.24.0 Workstations
309 +9 10.33.25.0 10.35.25.0 Phones
310 +10 10.33.26.0 10.35.26.0 Wireless Corporate
311 +11 10.33.27.0 10.35.27.0 Wireless Phones
512 +12 10.33.28.0 10.35.28.0 Wireless Guest
513 +13 10.33.29.0 10.35.29.0 Wired Guest
314 +14 10.33.30.0 10.35.30.0 Printers
115 +15 10.33.31.0 10.35.31.0 Network Management
Default Gateway is x.x.x.254
This type of scheme, when implemented from the start, provides easy expansion of an organization's network,
provides an ability to add protections between network devices, and simplifies inter-site routing.
2007 Jun 29 - Fri
One Unified Address Management, v1.3
I've updated the schema of my prototype address management database to reflect some
additional relationships with VRFs and VLANs.
The address management
schema is for a PostgreSQL 8.1 database.
Once I have the address tables populated, I'll want to generate zone files for DNS to
facilitate informative traceroutes. There were a couple of useful suggestions on the Nanog
mailing lists, one by Mark Tinka, and the other one by Joe Abley,
the same person who did a paper on
toolmaking at Nanog 26.
2007 May 16 - Wed
One Unified Address Management Schema v1.1
I did some more brainstorming on how I wanted to visually represent a network along
with it's address structure. I've incorporated some additional tables into the design
to handle a hierarchical network map.
The core of the database schema is still represented by the host, interface, circuit, address,
location, organization, and ianaiftype tables.
The Image table contains references to all pictures of hosts and locations. All other associated tables
reference the images managed by this table.
The WeatherMap group of tables allows a Network Weathermap to be defined for a collection of circuits.
By requesting a certain weathermap, the WeathermapCircuit table provides a list of associated circuits.
The circuit links to interfaces and their respective hosts. By looking for hosts in the HostOnImage table
that reference the same hostid and imageid, a weather map can be automatically drawn with the appropriate
host picture from the HostImage table along with the collected interface statistics.
The HostType table represents names such as 'Router', 'Switch', 'Server', 'Access Point', etc.
Two tables have been added to the Location group of tables. LocationImage represents images of
locations: a building, a floor, a cabinet, a back panel, with each image suggesting a collection of
sub-locations. The LocationOnImage table provides the ability to click on an active area on LocationImage
and drill down to the more specific LocationImage.
2007 May 15 - Tue
One Unified Address Management (OUAM)
For the longest time, I thought that the sum total of the ip address management solutions out there revolved
around NorthStar and IPplan, neither of which really were as robust as I'd like.
A recent 'net search comes up with some different candidates. A IP Addressing Space Management
Applications? has
some interesting pointers to IP Address Management solutions, both Open Source as well as Commercial. One Open
Source solution that appeared to be a stand out is Carnegie
Mellon's Network Registration/Network Monitoring solution. It is under active development. Internet2 has some links to solutions that handle various combinations of Agents, Registration,
and Active/Passive Detection.
Some of the above actually crosses over into the region of Network Authentication, of which Internet2's SALSAK is trying to rigorize through
a Poicy Framework. Their second
draft has better details, in my opinion.
So I can come back to this later, in following the various links from an earlier mentioned table, I came across PacketFence which is a Network Access Control
(NAC) solution wrapped up in a VMWare deployment package.
When coming up with an IP Address Management Solution, BT Diamond IP has a handy guide to Best Practices for
Next-Generation IP Address Management.
During my initial thoughts of what I'd like to see, I was focussing more on address management, floor diagrams,
and port management than on DNS and DHCP. I figured DNS would be easy by simply exporting bind files on an as
required basis. I havn't considered DHCP integration yet, but should be straight forward with dhcp configuration
file exports, or data base lookups.
I had put together a schema diagram of what I was thinking of for ip address and facilities management.
Here is a description of the various links:
- Host -> Location: every host is associated with a particular location, floor, rack, shelf, etc
- Interface -> Host: an interface, and its sub-interfaces are associated with a host
- Interface -> Address:
- an interface, or sub-interface will have an associated address
- an interface will need multiple sub interfaces to contain additional addresses
- these sub-interfaces may simply be 'secondary address blocks', or secondary addresses, or vlans
- Interface -> Circuit: an interface is associated with a particular circuit, patch panel, connector, etc
- Circuit -> Address:
- a circuit may reference an address or address range that can be used to find attached interfaces, hosts,
and circuits (and is recursive by looking at subnets and contained addresses)
- thus routed address blocks shouldn't be referenced this way, only a circuit with ip endpoints should have
an address reference
- Port -> Address: for ports routed to different locations, or are routed, this is where this is
documented,
such as on NAT.d addresses (eg port 80 (http) or port 25 (smtp))
- Address -> Organization: Every address range is associated with a controlling organization
Some of the tables have 'self' links. This provides an ability for defining a hierarchy of relationships:
- Address: address blocks can be subdivided down to a /32
- Interface: a phsysical interface may be divided into sub-interfaces
- Circuit: a circuit may be composed of sub-circuits, wire going from wall jack to IDF to MDF to IDF to
wall
jack
- Location: a building may have multiple floors, a server room may have multiple racks, a rack will
have
multiple 'U' locations
Here is a sql schema file to go along with the diagram. It
is based upon PostgreSQL as it has native data types for handling ip addresses and mac addresses.
Import IANAifType
From the web page http://www.iana.org/assignments/ianaiftype-mib there is an
list of interface types. Early portions of this list are incorporated into /usr/share/cricket/util/genDevConfig.
The full list is parsed and imported into the database.
Conversion
Create a perl program ianaif.pl:
#! /usr/bin/perlwhile ( <STDIN> ) {
$_ =~ /^\s+([\-\w]+)\s*\((\d+)\),?(\s*|\s*--\s(.+?))\s*$/;
print "insert into ianaiftype (ianaiftypeid, name, description) values ($2, '$1', '$4');\n";
}
Create a file 'ianaif.txt' with the mildly edited content from web site.
Run the perl script to create an imort file:
perl ianaif.pl < ianaif.txt > ianaif.import
Import into the database:
su - postgres
psql oneunified
\i ianaif.import
\q
Here is the raw data:
other(1), -- none of the following
regular1822(2),
hdh1822(3),
ddnX25(4),
rfc877x25(5),
ethernetCsmacd(6), -- for all ethernet-like interfaces,
iso88023Csmacd(7), -- Deprecated, use ethernetCsmacd (6)
iso88024TokenBus(8),
iso88025TokenRing(9),
iso88026Man(10),
starLan(11), -- Deprecated, use ethernetCsmacd (6)
proteon10Mbit(12),
proteon80Mbit(13),
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18), -- DS1-MIB
e1(19), -- Obsolete see DS1-MIB
basicISDN(20),
primaryISDN(21),
propPointToPointSerial(22), -- proprietary serial
ppp(23),
softwareLoopback(24),
eon(25), -- CLNP over IP
ethernet3Mbit(26),
nsip(27), -- XNS over IP
slip(28), -- generic SLIP
ultra(29), -- ULTRA technologies
ds3(30), -- DS3-MIB
sip(31), -- SMDS, coffee
frameRelay(32), -- DTE only.
rs232(33),
para(34), -- parallel-port
arcnet(35), -- arcnet
arcnetPlus(36), -- arcnet plus
atm(37), -- ATM cells
miox25(38),
sonet(39), -- SONET or SDH
x25ple(40),
iso88022llc(41),
localTalk(42),
smdsDxi(43),
frameRelayService(44), -- FRNETSERV-MIB
v35(45),
hssi(46),
hippi(47),
modem(48), -- Generic modem
aal5(49), -- AAL5 over ATM
sonetPath(50),
sonetVT(51),
smdsIcip(52), -- SMDS InterCarrier Interface
propVirtual(53), -- proprietary virtual/internal
propMultiplexor(54),-- proprietary multiplexing
ieee80212(55), -- 100BaseVG
fibreChannel(56), -- Fibre Channel
hippiInterface(57), -- HIPPI interfaces
frameRelayInterconnect(58), -- Obsolete, use frameRelay(32) or frameRelayService(44)
aflane8023(59), -- ATM Emulated LAN for 802.3
aflane8025(60), -- ATM Emulated LAN for 802.5
cctEmul(61), -- ATM Emulated circuit
fastEther(62), -- Obsoleted, use ethernetCsmacd (6)
isdn(63), -- ISDN and X.25
v11(64), -- CCITT V.11/X.21
v36(65), -- CCITT V.36
g703at64k(66), -- CCITT G703 at 64Kbps
g703at2mb(67), -- Obsolete see DS1-MIB
qllc(68), -- SNA QLLC
fastEtherFX(69), -- Obsoleted, use ethernetCsmacd (6)
channel(70), -- channel
ieee80211(71), -- radio spread spectrum
ibm370parChan(72), -- IBM System 360/370 OEMI Channel
escon(73), -- IBM Enterprise Systems Connection
dlsw(74), -- Data Link Switching
isdns(75), -- ISDN S/T interface
isdnu(76), -- ISDN U interface
lapd(77), -- Link Access Protocol D
ipSwitch(78), -- IP Switching Objects
rsrb(79), -- Remote Source Route Bridging
atmLogical(80), -- ATM Logical Port
ds0(81), -- Digital Signal Level 0
ds0Bundle(82), -- group of ds0s on the same ds1
bsc(83), -- Bisynchronous Protocol
async(84), -- Asynchronous Protocol
cnr(85), -- Combat Net Radio
iso88025Dtr(86), -- ISO 802.5r DTR
eplrs(87), -- Ext Pos Loc Report Sys
arap(88), -- Appletalk Remote Access Protocol
propCnls(89), -- Proprietary Connectionless Protocol
hostPad(90), -- CCITT-ITU X.29 PAD Protocol
termPad(91), -- CCITT-ITU X.3 PAD Facility
frameRelayMPI(92), -- Multiproto Interconnect over FR
x213(93), -- CCITT-ITU X213
adsl(94), -- Asymmetric Digital Subscriber Loop
radsl(95), -- Rate-Adapt. Digital Subscriber Loop
sdsl(96), -- Symmetric Digital Subscriber Loop
vdsl(97), -- Very H-Speed Digital Subscrib. Loop
iso88025CRFPInt(98), -- ISO 802.5 CRFP
myrinet(99), -- Myricom Myrinet
voiceEM(100), -- voice recEive and transMit
voiceFXO(101), -- voice Foreign Exchange Office
voiceFXS(102), -- voice Foreign Exchange Station
voiceEncap(103), -- voice encapsulation
voiceOverIp(104), -- voice over IP encapsulation
atmDxi(105), -- ATM DXI
atmFuni(106), -- ATM FUNI
atmIma (107), -- ATM IMA
pppMultilinkBundle(108), -- PPP Multilink Bundle
ipOverCdlc (109), -- IBM ipOverCdlc
ipOverClaw (110), -- IBM Common Link Access to Workstn
stackToStack (111), -- IBM stackToStack
virtualIpAddress (112), -- IBM VIPA
mpc (113), -- IBM multi-protocol channel support
ipOverAtm (114), -- IBM ipOverAtm
iso88025Fiber (115), -- ISO 802.5j Fiber Token Ring
tdlc (116), -- IBM twinaxial data link control
gigabitEthernet (117), -- Obsoleted, use ethernetCsmacd (6)
hdlc (118), -- HDLC
lapf (119), -- LAP F
v37 (120), -- V.37
x25mlp (121), -- Multi-Link Protocol
x25huntGroup (122), -- X25 Hunt Group
trasnpHdlc (123), -- Transp HDLC
interleave (124), -- Interleave channel
fast (125), -- Fast channel
ip (126), -- IP (for APPN HPR in IP networks)
docsCableMaclayer (127), -- CATV Mac Layer
docsCableDownstream (128), -- CATV Downstream interface
docsCableUpstream (129), -- CATV Upstream interface
a12MppSwitch (130), -- Avalon Parallel Processor
tunnel (131), -- Encapsulation interface
coffee (132), -- coffee pot
ces (133), -- Circuit Emulation Service
atmSubInterface (134), -- ATM Sub Interface
l2vlan (135), -- Layer 2 Virtual LAN using 802.1Q
l3ipvlan (136), -- Layer 3 Virtual LAN using IP
l3ipxvlan (137), -- Layer 3 Virtual LAN using IPX
digitalPowerline (138), -- IP over Power Lines
mediaMailOverIp (139), -- Multimedia Mail over IP
dtm (140), -- Dynamic syncronous Transfer Mode
dcn (141), -- Data Communications Network
ipForward (142), -- IP Forwarding Interface
msdsl (143), -- Multi-rate Symmetric DSL
ieee1394 (144), -- IEEE1394 High Performance Serial Bus
if-gsn (145), -- HIPPI-6400
dvbRccMacLayer (146), -- DVB-RCC MAC Layer
dvbRccDownstream (147), -- DVB-RCC Downstream Channel
dvbRccUpstream (148), -- DVB-RCC Upstream Channel
atmVirtual (149), -- ATM Virtual Interface
mplsTunnel (150), -- MPLS Tunnel Virtual Interface
srp (151), -- Spatial Reuse Protocol
voiceOverAtm (152), -- Voice Over ATM
voiceOverFrameRelay (153), -- Voice Over Frame Relay
idsl (154), -- Digital Subscriber Loop over ISDN
compositeLink (155), -- Avici Composite Link Interface
ss7SigLink (156), -- SS7 Signaling Link
propWirelessP2P (157), -- Prop. P2P wireless interface
frForward (158), -- Frame Forward Interface
rfc1483 (159), -- Multiprotocol over ATM AAL5
usb (160), -- USB Interface
ieee8023adLag (161), -- IEEE 802.3ad Link Aggregate
bgppolicyaccounting (162), -- BGP Policy Accounting
frf16MfrBundle (163), -- FRF .16 Multilink Frame Relay
h323Gatekeeper (164), -- H323 Gatekeeper
h323Proxy (165), -- H323 Voice and Video Proxy
mpls (166), -- MPLS
mfSigLink (167), -- Multi-frequency signaling link
hdsl2 (168), -- High Bit-Rate DSL - 2nd generation
shdsl (169), -- Multirate HDSL2
ds1FDL (170), -- Facility Data Link 4Kbps on a DS1
pos (171), -- Packet over SONET/SDH Interface
dvbAsiIn (172), -- DVB-ASI Input
dvbAsiOut (173), -- DVB-ASI Output
plc (174), -- Power Line Communtications
nfas (175), -- Non Facility Associated Signaling
tr008 (176), -- TR008
gr303RDT (177), -- Remote Digital Terminal
gr303IDT (178), -- Integrated Digital Terminal
isup (179), -- ISUP
propDocsWirelessMaclayer (180), -- Cisco proprietary Maclayer
propDocsWirelessDownstream (181), -- Cisco proprietary Downstream
propDocsWirelessUpstream (182), -- Cisco proprietary Upstream
hiperlan2 (183), -- HIPERLAN Type 2 Radio Interface
propBWAp2Mp (184), -- PropBroadbandWirelessAccesspt2multipt
sonetOverheadChannel (185), -- SONET Overhead Channel
digitalWrapperOverheadChannel (186), -- Digital Wrapper
aal2 (187), -- ATM adaptation layer 2
radioMAC (188), -- MAC layer over radio links
atmRadio (189), -- ATM over radio links
imt (190), -- Inter Machine Trunks
mvl (191), -- Multiple Virtual Lines DSL
reachDSL (192), -- Long Reach DSL
frDlciEndPt (193), -- Frame Relay DLCI End Point
atmVciEndPt (194), -- ATM VCI End Point
opticalChannel (195), -- Optical Channel
opticalTransport (196), -- Optical Transport
propAtm (197), -- Proprietary ATM
voiceOverCable (198), -- Voice Over Cable Interface
infiniband (199), -- Infiniband
teLink (200), -- TE Link
q2931 (201), -- Q.2931
virtualTg (202), -- Virtual Trunk Group
sipTg (203), -- SIP Trunk Group
sipSig (204), -- SIP Signaling
docsCableUpstreamChannel (205), -- CATV Upstream Channel
econet (206), -- Acorn Econet
pon155 (207), -- FSAN 155Mb Symetrical PON interface
pon622 (208), -- FSAN622Mb Symetrical PON interface
bridge (209), -- Transparent bridge interface
linegroup (210), -- Interface common to multiple lines
voiceEMFGD (211), -- voice E&M Feature Group D
voiceFGDEANA (212), -- voice FGD Exchange Access North American
voiceDID (213), -- voice Direct Inward Dialing
mpegTransport (214), -- MPEG transport interface
sixToFour (215), -- 6to4 interface (DEPRECATED)
gtp (216), -- GTP (GPRS Tunneling Protocol)
pdnEtherLoop1 (217), -- Paradyne EtherLoop 1
pdnEtherLoop2 (218), -- Paradyne EtherLoop 2
opticalChannelGroup (219), -- Optical Channel Group
homepna (220), -- HomePNA ITU-T G.989
gfp (221), -- Generic Framing Procedure (GFP)
ciscoISLvlan (222), -- Layer 2 Virtual LAN using Cisco ISL
actelisMetaLOOP (223), -- Acteleis proprietary MetaLOOP High Speed Link
fcipLink (224), -- FCIP Link
rpr (225), -- Resilient Packet Ring Interface Type
qam (226), -- RF Qam Interface
lmp (227), -- Link Management Protocol
cblVectaStar (228), -- Cambridge Broadband Limited VectaStar
docsCableMCmtsDownstream (229), -- CATV Modular CMTS Downstream Interface
adsl2 (230), -- Asymmetric Digital Subscriber Loop Version 2
macSecControlledIF (231), -- MACSecControlled
macSecUncontrolledIF (232), -- MACSecUncontrolled
aviciOpticalEther (233), -- Avici Optical Ethernet Aggregate
atmbond (234), -- atmbond
voiceFGDOS (235), -- voice FGD Operator Services
mocaVersion1 (236), -- MultiMedia over Coax Alliance (MoCA) Interface
ieee80216WMAN (237), -- IEEE 802.16 WMAN interface
adsl2plus (238), -- Asymmetric Digital Subscriber Loop Version 2,
dvbRcsMacLayer (239), -- DVB-RCS MAC Layer
dvbTdm (240), -- DVB Satellite TDM
dvbRcsTdma (241), -- DVB-RCS TDMA
x86Laps (242) -- LAPS based on ITU-T X.86/Y.1323
|
