Scott's Blog

My blog; no-one else's

Tag: routing

JunOS and SNMPv3 into VRFs and Logical Systems

July 29, 2023 /

Without addition configuration, SNMP elements that lie without the scope of the base logical system and default routing instance (aka master) are not visible to SNMP agents. This means routes, BGP neighbours, etc that are configured in routing instances and logical systems are not accessible.

To make these elements accessible to SNMP agents, a non-default SNMPv3 context must be created that refers to the LSYS and/or instance that is to be exposed. To expose the default/master instance of a logical system:

set snmp v3 vacm access group <snmpv3Group> context-prefix <lsys>/default security-model usm security-level privacy <read-view|write-view> <snmpView>

To expose a VRF/routing instance of the base LSYS:

set snmp v3 vacm access group <snmpv3Group> context-prefix <routingInstance> security-model usm security-level privacy <read-view|write-view> <snmpView>

To expose a VRF/routing instance of an LSYS:

set snmp v3 vacm access group <snmpv3Group> context-prefix <lsys>/<routingInstance> security-model usm security-level privacy <read-view|write-view> <snmpView>

To access these contexts with UCD’s snmp utilities you must specify a context with the `-n’ option:

$ snmpwalk -v3 -l authPriv -u '<user>' -a SHA -A '<authPassword>' -x AES128 -X '<privacyPassword>' -n '<lsys>/<routingInstance>' <host> <oid>

For example:

$ snmpwalk -v3 -l authPriv -u '<user>' -a SHA -A '<authPassword>' -x AES128 -X '<privacyPassword>' -n 'LSYS-TEST/RI-TEST' <host> ipCidrRouteDest
IP-FORWARD-MIB::ipCidrRouteDest.100.1.1.2.255.255.255.255.0.0.0.0.0 = IpAddress: 100.1.1.2

While I’ve not configured anything similar for SNMP v2c, I believe the same functionality can be attained by combining the context with the community with the `@’ sign. Or something like that.

Private vLANs

March 22, 2021 /

Having just implemented private vLANs on a Cisco 3750X switch I thought I’d share some findings.

A private vLAN configuration consists of a primary vLAN, zero or one isolated vLANs, and zero or more community vLANs.

When associated with each other, primary, isolated and community vLANs limit the switch’s forwarding scope for frames.

For a normal vLAN the forwarding scope comprises all ports to which that vLAN is assigned.

For a pvLAN the scope changes:

  • the primary vLAN is a normal vLAN with a normal scope; frames are forwarded to any or all ports to which the primary vLAN is assigned
  • an isolated vLAN is a point-to-multipoint topology, much like the Frame Relay NBMA, where the scope is limited to a single port to which the isolated vLAN is assigned and all associated primary vLAN ports
  • a community vLAN’s scope is a hybrid of that of primary and isolated vLANs; it comprises all ports to which the community vLAN is assigned and all associated primary vLAN ports

Treatment of broadcast and unknown destination frames received on a given port is as follows:

  • primary vLAN: frames are forwarded to:
    • all other ports in the primary vLAN, all ports in the isolated vLAN, and all ports in all community vLANs
  • isolated vLAN: frames are forward to:
    • all ports in the primary vLAN, while having their vLAN translated to the primary vLAN number
  • community vLANs: frames are forwarded to:
    • all ports in the same community vLAN and all ports in the primary vLAN, again having their vLAN translated to the primary vLAN number

Another way to look at private vLANs is that they provide vLAN translation on ports depending on which way frames are flowing:

From/ToPrimaryIsolatedCommunity
PrimaryNo translationP->IP->C
IsolatedI->PNot permittedNot permitted
CommunityC->PNot permittedNo translation
pvLAN translation

You can see that ports, regardless of their assigned pvLAN type, receive frames with their own vLAN id.

An interesting consideration with pvLANs is with layer 3 SVIs and pvLAN trunks with a router connected. If there is no IP ACL on the SVI/router port denying such traffic, any host, regardless of the vLAN type assigned to its port, can reach any other host in the same private vLAN configuration, simply by creating a static ARP entry where the destination host’s IP is mapped to the SVI/router port’s MAC address.

This is because any host can reach a router on a primary vLAN (using its MAC address), which then is able to reach any other host within the pvLAN.

© 2024 Scott's Blog

Theme by Anders Noren — Up ↑