Metro Ethernet Terms

As some of you reading this dive into metro ethernet you should know some terminology

• User-Network Interface (UNI): The UNI is a physical Ethernet port on the service provider side of the network along with a predefined set of parameters to provide data, control and management traffic exchange with the end-customer CPE device. The customer CPE device can be a Layer 2 Ethernet switch, Layer 3 routing node or some of LTE nodes.

• Network-to-Network Interface (NNI):  NNI is represented by the physical Ethernet port on the service provider access node that is used to interconnect two Ethernet MANs of two different service providers. We are also using E-NNI as a reference point for the interconnection of Layer 2 MAN service with Layer 3 service nodes—the provider edge router (PE), a broadband network gateway (BNG), vertical handover (VHO), etc—in the provider network.

• Ethernet Virtual Connection (EVC) is the architecture construct that supports the association of UNI reference points for the purpose of delivering an Ethernet flow between subscriber sites across the MAN.

Simple shut-off scripting

I had a client today who is doing some manual things as they are using Quickbooks for billing and such.  One thing they kind of struggle with is turning off people for non-payment and such.  Their current method is adding a que and throttling someone to a low-speed to make them call.  Their network is a routed network utilizing DHCP to the CPE at the customer.  Everything is in router mode and they control the addressing of the units via DHCP reservations.  So how do we make this better without adding radius and all kinds of stuff into the network?

First we set up a web-proxy

/ip proxy
set enabled=yes port=8089

/ip proxy access
add dst-host=mtin.net dst-port=80
add dst-host=*.mtin.net dst-port=80
add dst-port=53
add action=deny redirect-to=www.mtin.net

What the above code does is says anyone coming into the proxy is only allowed to go to mtin.net (used our domain as an example), use port 53 (DNS), and anything else gets redirected to www.mtin.net. We chose port 53 because they are in the process of cleaning up some of the radios and such which are using 8.8.8.8 and other DNS servers.

Next we set up a nat rule

/ip firewall nat
add action=redirect chain=dstnat dst-port=80 protocol=tcp src-address-list=\
SHUTOFF to-ports=8089

This nat rule says anyone making a port 80 request coming from our SHUTOFF address-list gets redirected to port 8089 (our proxy port setup earlier).

Our third step is to setup our address list. this is very straightforward.  Just modify and add users to this list when they are to be turned off.

/ip firewall address-list
add address=10.20.0.192 list=SHUTOFF

Lastly, we add a filter rule which denies the SHUTOFF folks from using anything except port 53 and port 80.  We do this because we can’t proxy port 443 and other SSL traffic. If folks go to a HTTPS site it simply fails.  This is a drawback of using a web-proxy.

/ip firewall filter
add action=drop chain=forward dst-port=!53,80 protocol=tcp src-address-list=\
SHUTOFF

If you have an SSL payment gateway you can modify your filter rules to allow traffic to it. This is just one quick and dirty way of letting customers know they have been turned off.

Soft Reconfiguration inbound

Several people have been asking what soft Reconfiguration Inbound is on a BGP peer.

In the dark days of BGP you had to tear down the BGP session and do a full reestablishment in order to bring it up.  What soft reconfiguration does is copies of all routes received (this is why it is called inbound) are stored separately from the regular BGP table.   When a change is made the new change is applied to the stored copy of the BGP routes.

Disadvantage? This takes up memory because you have two files basically.

So how is this different than route refresh described in RFC 2918? This is a standard, with an RFC unlike Soft Reconfiguration inbound, which is a Cisco thing. Route refresh asks the peer to resend all its routes.

Homeland Security US-Cert e-mail on Network infrastructure

A few days ago Homeland Security published an e-mail on threats to network devices and securing them.  Rather than cut and paste I exported the e-mail to a PDF. Some good best practices in here.

TA16250A The Increasing Threat to Network Infrastructure Devices and Recommended Mitigations