Источник:
https://blogs.oracle.com/olympus/entry/dscp
Sun SPARC Enterprise Approach
Sun SPARC Enterprise M-series decided the application scalability of the
Maintenance Area Network was a benefit, but we wanted to achieve it
without having to run a separate Ethernet network. The result is what we
called DSCP -- the Domain to Service Processor Communication Protocol.
DSCP provides IP communication between the SP and the domain without any
new hardware; it uses a single mailbox in the shared RAM, and using a
pseudo serial driver on top of that mailbox, we enable PPP (the Point-to-Point Protocol).
Configuring DSCP
The Sun SPARC Enterprise Server Administration Guide explains how to set up DSCP, but it is really quite simple. The easiest method is using the syntax: setdscp -i NETWORK -m NETMASK
Choose a network address (be sure to pick a subnet that is not in use at your facility) and the corresponding netmask, and setdscp will do the rest. For example, in my lab the subnet 192.168.244.0 is unused, so I do: XSCF> setdscp -i 192.168.224.0 -m 255.255.255.0
There are other ways to set up the DSCP network addresses, but this is really the best approach.
setdscp will assign an IP address to the SP, and
reserve one IP address for every possible domain (the M9000-64 supports
24 domains, so a maximum of 25 IP addresses are reserved). A common
question that's asked is, if you're running PPP between the SP and each
domain, don't you need to two addresses for each domain, one for the
domain and one for the SP? No, not really. Since routing is done based
on the destination address, we can get away with using the same IP
address for the SP on every PPP link. So technically speaking, the
NETWORK and NETMASK are not defining a DSCP subnet; they are
defining a range of IP addresses from which DSCP selects endpoint
addresses. A subtle difference, but still a difference.
On the SP, showdscp will display the IP addresses assigned to each domain and the SP, for example:
XSCF> showdscp
DSCP Configuration:
Network: 192.168.224.0
Netmask: 255.255.255.0
Location Address
---------- ---------
XSCF 192.168.224.1
Domain #00 192.168.224.2
Domain #01 192.168.224.3
Domain #02 192.168.224.4
Domain #03 192.168.224.5
In Solaris, the prtdscp(1M) command will display the IP address of that domain and the SP (prtdscp is located in
/usr/platform/SUNW,SPARC-Enterprise/sbin). You can get the same basic information
from ifconfig sppp0: % /usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp
Domain Address: 192.168.224.2
SP Address: 192.168.224.1
% ifconfig sppp0
sppp0: flags=10010008d1 mtu 1500 index 3
inet 192.168.224.2 --> 192.168.224.1 netmask ffffff00
Benefits
Plumbing IP between the Solaris domain and the SP brings the obvious
benefit of standards-based communication -- networking applications
"just work". For example, you can configure the SP as an NTP server and
configure the Solaris domains to use NTP to synchronize their time with
the SP, all using the internal DSCP network. You can even use ssh to
connect to the SP from a Solaris domain using the DSCP network. Since
the SP does not have a hostname on the DSCP network, you need to get the
IP address using prtdscp, for example ssh `/usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp -s`
Personally, I create an alias sshsp with the above line.
On the SP side, you can't use ssh or scp directly -- they're not
available in the XSCF shell. But you can use them indirectly. You can
configure log archiving (see the
setarchiving man page) to use one of the domains as an archive host:
XSCF> setarchiving -t rjh@192.168.224.2:/home/rjh/archive
XSCF> setarchiving enable
[I'm not sure it makes sense to use a domain as a log archive
host -- a catastrophic failure with the system means you also lose your
log archive host -- but it is technically possible.]
And when you need to take a snapshot of the system for diagnosis
purposes (see snapshot man page), you can specify one of the domains as
the snapshot host using the -t option, for example:
XSCF> snapshot -l -t rjh@192.168.224.2:/home/rjh/snap
Downloading Public Key from '192.168.224.2'...
Public Key Fingerprint: 44:9a:ad:55:2e:33:99:2e:fd:b7:47:74:de:ad:be:ef
Accept this public key (yes/no)? yes
Enter ssh password for user 'rjh' on host '192.168.224.2':
Setting up ssh connection to rjh@192.168.224.2...
Collecting data into rjh@192.168.224.2:/home/rjh/snap/mymachine_10.4.55.144_2007-05-07T19-39-40.zip
Data collection complete
If your domain has internet access or a DVD burner, this might be the
easiest way to get a snapshot back to a Sun Service Engineer.
Security
One of the most important security goals with the DSCP design was: Ensure
that if one Solaris domain is compromised, that an attacker would not
be able to affect the SP or another domain in the same chassis. This primary security requirement drove most of the DSCP design approach.
Using PPP provides an added security benefit. Each shared RAM mailbox
represents a single PPP connection between Solaris and the SP. This
means there is no opportunity for one domain to snoop the traffic
between another domain and the SP, and no way for one domain to directly
attach another domain using the DSCP network. There is also no routing
between DSCP networks (or from DSCP to Ethernet or vice versa) on the
SP. The communication paths of each domain are physically isolated.
Most of the protocols used on the Sun SPARC Enterprise servers place the
client on the SP
and the server on the domain. This means that the SP does not need to
open up well-known ports for incoming connections, reducing the
opportunity for attacks. Furthermore, the severs running in Solaris use IPsec to authenticate that incoming connections are coming from the SP.
To prevent the domain from attacking the SP, several methods are used.
First, all of the authentication and authorization protocols employed
for Ethernet users are in place for the DSCP networks. There is no DSCP
"back door", so to speak. Further, the SP employs a firewall that blocks
all the ports on the DSCP networks except a couple -- ssh and ntp.
There are additional features in place, for example, bandwidth limiting
to prevent denial-of-service attacks.
Summary
The Domain to Service Processor Communication Protocol enables IP-based
communication between the Solaris domain and the SP, in a secure
fashion, which enables standards-compliant applications such as ssh and
ntp to "just work" between the SP and Solaris domains.
| 
Меню сайта