Fritz!Box 7390 and QoS Tagging

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › Fritz!Box 7390 and QoS Tagging

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#191498 5-Feb-2016 22:42

Wasn't sure if this should go here, or the VoIP, or router forum.

I have a Fritz!Box 7390 sitting behind my main router. Fritz is configure to "share an existing Internet connection", so is just on the network for VoIP.

I wish to setup QoS on my main router, but when I examine the VoIP traffic I notice that traffic originating from the Fritz isn't tagged as DSCP 24 & 46 (SIP & RTP).

How do I get the Fritz to tag the outbound VoIP traffic?

Thanks

Home: Work:
Home Work

1 | 2 | 3

meow
13579 posts

Uber Geek
+1 received by user: 10910

Moderator

ID Verified

Trusted

Lifetime subscriber

#1486327 5-Feb-2016 23:42

On your Edgerouter mark the standard SIP and RTP ports via a NAT rule. You can from here add QoS to it via the Edgerouter itself. I personally don't use SIP anymore (mobile only) and also bare in mine QoS is not hardware packet accelerated yet on the EdgeRouter so it'll use its CPU instead possibly decreasing performance instead of increasing it.

Personally, I wouldn't worry about it - since you have UFB and a powerful router you'll find that VoIP shouldn't drop even if you're maxing out your connection both upstream and down.

Michael Murphy | https://murfy.nz
Referral Links: Quic Broadband (use R122101E7CV7Q for free setup)

Are you happy with what you get from Geekzone? Please consider supporting us by subscribing.
Opinions are my own and not the views of my employer.

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#1486356 6-Feb-2016 08:35

2degrees VoIP (and VoIP from most providers using it on the RGW) uses the UFB CIR which uses 802.1p tagging, not DSCP.

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#1486375 6-Feb-2016 10:19

michaelmurfy:

On your Edgerouter mark the standard SIP and RTP ports via a NAT rule. You can from here add QoS to it via the Edgerouter itself. I personally don't use SIP anymore (mobile only) and also bare in mine QoS is not hardware packet accelerated yet on the EdgeRouter so it'll use its CPU instead possibly decreasing performance instead of increasing it.

Personally, I wouldn't worry about it - since you have UFB and a powerful router you'll find that VoIP shouldn't drop even if you're maxing out your connection both upstream and down.

We only have the VoIP line for parents and grandparents phoning us, so it's barely used - it was more about figuring out how to get it all configured, not necessarily to keep it that way.

I had read that QoS will disable the hardware acceleration, but again, it was more for the sake of experimentation and learning.

Does the EdgeRouter definitely process the QoS after the NAT rule adds the tags? All the tutorials I've looked at make the assumption that the traffic is already tagged before it hits the router.

Thanks

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#1486376 6-Feb-2016 10:34

sbiddle:

2degrees VoIP (and VoIP from most providers using it on the RGW) uses the UFB CIR which uses 802.1p tagging, not DSCP.

None of the packets (inbound or outbound) appear to have an 802.1p tag at all. Inbound traffic is DSCP tagged 24 and 46, out bound traffic DSCP value is 0. I may be missing something obvious here, as I haven't done much with QoS in the past.

Below is a screen shot from Wireshark:

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#1486379 6-Feb-2016 11:01

Paul1977:

sbiddle:

2degrees VoIP (and VoIP from most providers using it on the RGW) uses the UFB CIR which uses 802.1p tagging, not DSCP.

None of the packets (inbound or outbound) appear to have an 802.1p tag at all. Inbound traffic is DSCP tagged 24 and 46, out bound traffic DSCP value is 0. I may be missing something obvious here, as I haven't done much with QoS in the past.

Below is a screen shot from Wireshark:

802.1p headers can only exist within a 802.1q VLAN. This is why most metro Ethernet style networks use a VLAN tag (10 in the case of UFB and VDSL2 and EUBA ADSL2+) to deliver the service. This means you can offer a EIR and CIR component, which in the case of most UFB plans is a headline best effort EIR and a roughly 2.5 - 5Mbps CIR that is only accessible with the correct 802.1p tag.

As you're obviously capturing the traffic on the LAN side of your network you won't see inbound 802.1p marks as they'll be stripped by your router as your Fritzbox isn't sitting on a VLAN. Likewise the Fritzbox can't tag 802.1p headers for outbound traffic because it's not on a VLAN.

In a corporate environment you'd normally run voice on it's own VLAN because switches and the internal network can do very simple QoS based on the COS headers. You'd then have a router ensuring that upstream 802.1p tags are carried upstream to the ISP to use the CIR.

LennonNZ

2459 posts

Uber Geek
+1 received by user: 411

ID Verified

Trusted

#1486397 6-Feb-2016 11:10

The VOIP Box has to set DSCP Values (46/24 (cs3 SIP/ef RTP)). I would have no idea why your VOIp device is not setting it :-(

After it gets to your UFB router it has to add the cos value when it goes over the UFB (4 or 5 depending on what service you have) so the data goes into the HP Pool of the UFB connection. This is the main thing that people don't do (if they are using their own router) so even if the DSCP is being set it has no effect on QOS over the UFB connection.

Also the ISP has to set this COS marking on their end (the most important part) but you usually won't have any control over this. Anyone know what and ISPs do? Also What ISPs supplied routers are set up to do?

Dyson

Shop now for Dyson appliances (affiliate link).

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#1486398 6-Feb-2016 11:14

sbiddle:

Paul1977:

sbiddle:

2degrees VoIP (and VoIP from most providers using it on the RGW) uses the UFB CIR which uses 802.1p tagging, not DSCP.

None of the packets (inbound or outbound) appear to have an 802.1p tag at all. Inbound traffic is DSCP tagged 24 and 46, out bound traffic DSCP value is 0. I may be missing something obvious here, as I haven't done much with QoS in the past.

Below is a screen shot from Wireshark:

802.1p headers can only exist within a 802.1q VLAN. This is why most metro Ethernet style networks use a VLAN tag (10 in the case of UFB and VDSL2 and EUBA ADSL2+) to deliver the service. This means you can offer a EIR and CIR component, which in the case of most UFB plans is a headline best effort EIR and a roughly 2.5 - 5Mbps CIR that is only accessible with the correct 802.1p tag.

As you're obviously capturing the traffic on the LAN side of your network you won't see inbound 802.1p marks as they'll be stripped by your router as your Fritzbox isn't sitting on a VLAN. Likewise the Fritzbox can't tag 802.1p headers for outbound traffic because it's not on a VLAN.

In a corporate environment you'd normally run voice on it's own VLAN because switches and the internal network can do very simple QoS based on the COS headers. You'd then have a router ensuring that upstream 802.1p tags are carried upstream to the ISP to use the CIR.

That just dawned on me about the traffic not being in a VLAN on the local network and you post confirmed the tags won't stay on the packets, I should have realized it straight away because it makes perfect sense when you think about it.

So, 2Degrees must do both 802.1p and DSCP since inbound packets have DSCP tags?

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#1486416 6-Feb-2016 11:31

24 for SIP and 46 for RTP are stock standard values for VoIP. Regardless of whether they're used or not, 99% of hardware is going to use these values, and it's best practice to set these anyway.

Depending on your router (as in a cheap router it's unlikely, something such as a Mikrotik/Cisco/Edgerouter will do it) you should be able to remap DSCP26 and 46 into a COS field to set the outbound 802.1p marking for outbound traffic so it uses the high priority CIR.

At the end of the day however this is simply a case of best practice, it's highly unlikely in the real world that you're ever going to saturate your UFB to the point it impacts voice, unlike ADSL2+ where saturating the upload is very simple and will impact voice quality.

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#1486438 6-Feb-2016 12:36

sbiddle:

24 for SIP and 46 for RTP are stock standard values for VoIP. Regardless of whether they're used or not, 99% of hardware is going to use these values, and it's best practice to set these anyway.

Depending on your router (as in a cheap router it's unlikely, something such as a Mikrotik/Cisco/Edgerouter will do it) you should be able to remap DSCP26 and 46 into a COS field to set the outbound 802.1p marking for outbound traffic so it uses the high priority CIR.

At the end of the day however this is simply a case of best practice, it's highly unlikely in the real world that you're ever going to saturate your UFB to the point it impacts voice, unlike ADSL2+ where saturating the upload is very simple and will impact voice quality.

Wouldn't the outbound traffic from the Fritz have to already have the DSCP tags in order to remap it though? Looking at the Wireshark capture the traffic originating from the Fritz (192.168.2.253) has not set the DSCP tags?

It sounds like it probably isn't worth me doing it, but as an academic exercise it interests me.

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#1486439 6-Feb-2016 12:41

LennonNZ:

The VOIP Box has to set DSCP Values (46/24 (cs3 SIP/ef RTP)). I would have no idea why your VoIP device is not setting it :-(

I don't know much about VoIP, but given the Fritz is the 2Degrees supplied box I would have thought it would do this if it is best practice.

I'm not using the Fritz how 2Degrees intended, i.e. not as a router, but you'd think it would still do it?

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#1486445 6-Feb-2016 12:54

Paul1977:

LennonNZ:

The VOIP Box has to set DSCP Values (46/24 (cs3 SIP/ef RTP)). I would have no idea why your VoIP device is not setting it :-(

I don't know much about VoIP, but given the Fritz is the 2Degrees supplied box I would have thought it would do this if it is best practice.

I'm not using the Fritz how 2Degrees intended, i.e. not as a router, but you'd think it would still do it?

Without knowing exactly how 2degrees have their network configured it's not really possible to answer that. DSCP tags mean nothing over a UFB connection as EIR/CIR is split using 802.1p tags. 2degrees quite possibly have no need for DSCP tags internally within their network.

Setting DSCP tags can be easily done within the Fritzbox but I don't think they're in the GUI.

Dell

Shop now for Dell laptops and other devices (affiliate link).

fe31nz

1294 posts

Uber Geek
+1 received by user: 423

#1486726 7-Feb-2016 00:04

I also have my FritzBox 7390 behind my main router (Ubiqiti Edgerouter Lite). In fact, I have it on a second Edgerouter, so that I can provide it with an environment where it works just like it does if connected directly to the fibre. The main router (name: erl) connects to the fibre using PPPoE on VLAN 10. So the second Edgerouter (name: erlt) provides the 7390 with a PPPoE VLAN 10 connection using a PPPoE server daemon on eth2. This setup allows 2D/Snap to configure the 7390 as they normally do, and I can see the log messages showing that. For example, from today:

06.02.16

15:19:45

The service provider successfully transmitted settings to this device.

By capturing the packets on erlt's eth2 interface, I can see exactly what the fibre connection would be getting. And what I am seeing is that the 7390 is not setting the DSCP bits in VOIP packets. But it is also not setting anything in the 802.1Q PRI field either - it is leaving that set to 000 = best effort. So there seems to be something wrong with how 2D is setting up VOIP.

If anyone would like to see a dump of the traffic, I have put the tshark capture file on my web server:

http://www.jsw.gen.nz/fritzbox/erlt_eth2_call_to_Snap_support_0800.pcap

From that capture, here is a Wireshark dump of an outbound SIP packet:

Frame 18: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits) on interface 0
    Interface id: 0 (eth2)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 6, 2016 23:30:33.752632000 New Zealand Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1454754633.752632000 seconds
    [Time delta from previous captured frame: 0.002953000 seconds]
    [Time delta from previous displayed frame: 0.002953000 seconds]
    [Time since reference or first frame: 13.401055000 seconds]
    Frame Number: 18
    Frame Length: 472 bytes (3776 bits)
    Capture Length: 472 bytes (3776 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:vlan:ethertype:pppoes:ppp:ip:udp:sip]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09), Dst: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Destination: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Source: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = CFI: Canonical (0)
    .... 0000 0000 1010 = ID: 10
    Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Session Data (0x00)
    Session ID: 0x0002
    Payload Length: 448
Point-to-Point Protocol
    Protocol: Internet Protocol version 4 (0x0021)
Internet Protocol Version 4, Src: 203.86.202.190.static.snap.net.nz (203.86.202.190), Dst: aklacme01.plus.snap.net.nz (123.255.8.34)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 446
    Identification: 0xf16d (61805)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x6d8b [validation disabled]
    Source: 203.86.202.190.static.snap.net.nz (203.86.202.190)
    Destination: aklacme01.plus.snap.net.nz (123.255.8.34)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol (ACK)

No.     Time                          Source                Destination           Protocol Length Info
     19 2016-02-06 23:30:33.760952    203.86.202.190.static.snap.net.nz aklacme01.plus.snap.net.nz SIP/SDP 1478   Request: INVITE sip:0800276232@connect2.plus.snap.net.nz |

And here is a dump of an outbound RTP packet:

Frame 34: 306 bytes on wire (2448 bits), 306 bytes captured (2448 bits) on interface 0
    Interface id: 0 (eth2)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 6, 2016 23:30:35.334465000 New Zealand Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1454754635.334465000 seconds
    [Time delta from previous captured frame: 0.000640000 seconds]
    [Time delta from previous displayed frame: 0.000640000 seconds]
    [Time since reference or first frame: 14.982888000 seconds]
    Frame Number: 34
    Frame Length: 306 bytes (2448 bits)
    Capture Length: 306 bytes (2448 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:vlan:ethertype:pppoes:ppp:ip:udp:rtp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09), Dst: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Destination: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Source: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = CFI: Canonical (0)
    .... 0000 0000 1010 = ID: 10
    Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Session Data (0x00)
    Session ID: 0x0002
    Payload Length: 282
Point-to-Point Protocol
    Protocol: Internet Protocol version 4 (0x0021)
Internet Protocol Version 4, Src: 203.86.202.190.static.snap.net.nz (203.86.202.190), Dst: aklacme01.plus.snap.net.nz (123.255.8.34)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 280
    Identification: 0xf174 (61812)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x6e2a [validation disabled]
    Source: 203.86.202.190.static.snap.net.nz (203.86.202.190)
    Destination: aklacme01.plus.snap.net.nz (123.255.8.34)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 7090 (7090), Dst Port: 42970 (42970)
Real-Time Transport Protocol

No.     Time                          Source                Destination           Protocol Length Info
     35 2016-02-06 23:30:35.353460    aklacme01.plus.snap.net.nz 203.86.202.190.static.snap.net.nz RTP      226    PT=ITU-T G.711 PCMA, SSRC=0x27E600, Seq=58299, Time=1920

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#1486852 7-Feb-2016 11:54

fe31nz:

I also have my FritzBox 7390 behind my main router (Ubiqiti Edgerouter Lite). In fact, I have it on a second Edgerouter, so that I can provide it with an environment where it works just like it does if connected directly to the fibre. The main router (name: erl) connects to the fibre using PPPoE on VLAN 10. So the second Edgerouter (name: erlt) provides the 7390 with a PPPoE VLAN 10 connection using a PPPoE server daemon on eth2. This setup allows 2D/Snap to configure the 7390 as they normally do, and I can see the log messages showing that. For example, from today:

06.02.16 15:19:45 The service provider successfully transmitted settings to this device.

By capturing the packets on erlt's eth2 interface, I can see exactly what the fibre connection would be getting. And what I am seeing is that the 7390 is not setting the DSCP bits in VOIP packets. But it is also not setting anything in the 802.1Q PRI field either - it is leaving that set to 000 = best effort. So there seems to be something wrong with how 2D is setting up VOIP.

If anyone would like to see a dump of the traffic, I have put the tshark capture file on my web server:

http://www.jsw.gen.nz/fritzbox/erlt_eth2_call_to_Snap_support_0800.pcap

From that capture, here is a Wireshark dump of an outbound SIP packet:

Frame 18: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits) on interface 0
    Interface id: 0 (eth2)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 6, 2016 23:30:33.752632000 New Zealand Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1454754633.752632000 seconds
    [Time delta from previous captured frame: 0.002953000 seconds]
    [Time delta from previous displayed frame: 0.002953000 seconds]
    [Time since reference or first frame: 13.401055000 seconds]
    Frame Number: 18
    Frame Length: 472 bytes (3776 bits)
    Capture Length: 472 bytes (3776 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:vlan:ethertype:pppoes:ppp:ip:udp:sip]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09), Dst: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Destination: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Source: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = CFI: Canonical (0)
    .... 0000 0000 1010 = ID: 10
    Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Session Data (0x00)
    Session ID: 0x0002
    Payload Length: 448
Point-to-Point Protocol
    Protocol: Internet Protocol version 4 (0x0021)
Internet Protocol Version 4, Src: 203.86.202.190.static.snap.net.nz (203.86.202.190), Dst: aklacme01.plus.snap.net.nz (123.255.8.34)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 446
    Identification: 0xf16d (61805)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x6d8b [validation disabled]
    Source: 203.86.202.190.static.snap.net.nz (203.86.202.190)
    Destination: aklacme01.plus.snap.net.nz (123.255.8.34)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol (ACK)

No.     Time                          Source                Destination           Protocol Length Info
     19 2016-02-06 23:30:33.760952    203.86.202.190.static.snap.net.nz aklacme01.plus.snap.net.nz SIP/SDP 1478   Request: INVITE sip:0800276232@connect2.plus.snap.net.nz |

And here is a dump of an outbound RTP packet:

Frame 34: 306 bytes on wire (2448 bits), 306 bytes captured (2448 bits) on interface 0
    Interface id: 0 (eth2)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 6, 2016 23:30:35.334465000 New Zealand Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1454754635.334465000 seconds
    [Time delta from previous captured frame: 0.000640000 seconds]
    [Time delta from previous displayed frame: 0.000640000 seconds]
    [Time since reference or first frame: 14.982888000 seconds]
    Frame Number: 34
    Frame Length: 306 bytes (2448 bits)
    Capture Length: 306 bytes (2448 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:vlan:ethertype:pppoes:ppp:ip:udp:rtp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09), Dst: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Destination: Ubiquiti_b3:3f:af (24:a4:3c:b3:3f:af)
    Source: AvmGmbh_a8:b0:09 (9c:c7:a6:a8:b0:09)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 10
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = CFI: Canonical (0)
    .... 0000 0000 1010 = ID: 10
    Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Session Data (0x00)
    Session ID: 0x0002
    Payload Length: 282
Point-to-Point Protocol
    Protocol: Internet Protocol version 4 (0x0021)
Internet Protocol Version 4, Src: 203.86.202.190.static.snap.net.nz (203.86.202.190), Dst: aklacme01.plus.snap.net.nz (123.255.8.34)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 280
    Identification: 0xf174 (61812)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x6e2a [validation disabled]
    Source: 203.86.202.190.static.snap.net.nz (203.86.202.190)
    Destination: aklacme01.plus.snap.net.nz (123.255.8.34)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 7090 (7090), Dst Port: 42970 (42970)
Real-Time Transport Protocol

No.     Time                          Source                Destination           Protocol Length Info
     35 2016-02-06 23:30:35.353460    aklacme01.plus.snap.net.nz 203.86.202.190.static.snap.net.nz RTP      226    PT=ITU-T G.711 PCMA, SSRC=0x27E600, Seq=58299, Time=1920

Is it possible that the Fritz manages it's QoS without tagging? E.g. since it is essentially a PBX and router in one, it just automatically prioritizes it's own outbound VoIP traffic?

I'm also using an EdgeRouter Lite as my main router (just have the one though). Only had it a couple of weeks, so still learning. I'm using the Fritz as a wireless AP as well, so want to keep it sitting in my main subnet.

How have you got the EdgeRouters to pass the 2D configuration traffic onto the Fritz in you setup?

fe31nz

1294 posts

Uber Geek
+1 received by user: 423

#1487063 7-Feb-2016 16:58

Paul1977:

Is it possible that the Fritz manages it's QoS without tagging? E.g. since it is essentially a PBX and router in one, it just automatically prioritizes it's own outbound VoIP traffic?

I'm also using an EdgeRouter Lite as my main router (just have the one though). Only had it a couple of weeks, so still learning. I'm using the Fritz as a wireless AP as well, so want to keep it sitting in my main subnet.

How have you got the EdgeRouters to pass the 2D configuration traffic onto the Fritz in you setup?

The FritzBox can do all the QoS it likes, but without somehow tagging the packets, the upstream routers will not give them any priority, so when the traffic merges with other customers' traffic, the VOIP packets would be treated as normal packets and risk getting dropped anywhere there is congestion. Once the VOIP packets reach 2D's routers, those routers could be automatically giving the VOIP traffic priority (maybe by adding appropriate tags), but in between, in the Chorus network, their documentation makes it pretty clear that they expect the packets to have the 802.1Q PRI tags set for traffic to be given priority. In the absence of congestion, that does not matter much, but as more and more people connect to fibre, there will be congestion problems eventually. So it is much better to discover problems like this now and get them fixed.

I am only using my 7390 for telephony, as I have a Linksys WRT1900AC router to do my WiFi - it does 802.11ac which the 7390 is not capable of (7490's do ac). What I have done to make the 7390 work just like it was directly connected to the fibre is to give it the same IP address as the external IP address given by 2D to my erl router, and to connect it in the same way as it does on the fibre, using PPPoE on VLAN 10. I do not have it working on IPv6 as the PPPoE software in the EdgeRouters can not handle that yet. The rest of my network does do full IPv6.

The trick to making this work is that my main router (erl) has my external IP address on its eth0.10 PPPoE connection to the fibre. A router can not have the same IP address on different interfaces, as it would not know which interface it should send a packet destined for that address to. So I need a second router to have the second copy of my external IP address. Since I had a spare Edgerouter Lite as a backup unit, I just used that. All packets arriving at my external IP address on the main router (erl) that need to be sent on to the 7390 get the destination address changed to one of my internal IP addresses assigned for this purpose, representing traffic to the external interface of the 7390. Packets with the 7390's internal IP address are routed to the second EdgeRouter (erlt). Inside erlt, any packets that arrive from erl with the 7390's internal IP address get that address changed back to my external IP address and are routed on using that address. Since the PPPoE server on erlt that connects to the 7390 has my external IP address as the address it provides to the 7390, the packets for the 7390 get sent to it over the PPPoE VLAN 10 connection. In the other direction, packets from the 7390 get sent out to the PPPoE server on erlt using my external IP address, and inside erlt they get the external IP address changed to the internal IP address and are sent on to erl. In erl, packets arriving from erlt with the 7390's internal IP address as their source address get that address translated back to the external IP address and are routed on out the PPPoE connection to the fibre.

The traffic that needs to be sent to the 7390 to handle configuration from 2D and telephony is the following ports:

UDP 5060 (VOIP SIP)

TCP 8089 (TR-069 management)

TCP xxx (https login port - this varies between 2D customers, depending on what they set up at the time. It may not be necessary to have this port open once it has been used initially by 2D to set up the FritzBox for TR-069 management, but I have kept it open for my own use).

UDP 7078-7109 (VOIP RTP)

Changing addresses in the EdgeRouters is done using NAT rules. Packets to the 7390 get their destination address changed using destination NAT rules or ordinary "forward-to" rules (which are just simplified destination NAT rules). Packets from the 7390 get their source addresses changed using source NAT rules.

For the sake of completeness, I have also spoofed the MAC address of my 7390 on erl's eth0 port, so that if the 2D router it is connecting to viap PPPoE VLAN 10 can see that address, it will see what it is expecting if it was connecting directly to my 7390. It is unlikely that it is necessary to do that.

I would like to be able to do all this in just one EdgeRouter, but the only way I can see to do that would be to write a customised version of the PPPoE server software that did the address translations internally. It would present the internal IP address of the 7390 to erl's routing, and would present my external IP address to the 7390. That would involve being able to compile things to run on an EdgeRouter, which I have not got set up, but other people have reported being able to do. I may try this at some point if I find the time, but in the mean time, my current setup works well, just costing a little more on my electicity bill to run an extra EdgeRouter.

If you do not have a static external IP address as I do, then you would also need a script that detected any change of your extenal IP address and changed that address in the config of the main router and the router connecting the FritzBox, then force the FritzBox to reconnect. That is a non-tivial script, but definitely possible to do. It could reside on either router, or somewhere else on your network.

If anyone wants help with doing a similar setup for themselves, please feel free to PM me and I can provide the Edgerouter config to do it.

Paul1977

5171 posts

Uber Geek
+1 received by user: 2192

#1487113 7-Feb-2016 18:11

fe31nz:

The FritzBox can do all the QoS it likes, but without somehow tagging the packets, the upstream routers will not give them any priority, so when the traffic merges with other customers' traffic, the VOIP packets would be treated as normal packets and risk getting dropped anywhere there is congestion. Once the VOIP packets reach 2D's routers, those routers could be automatically giving the VOIP traffic priority (maybe by adding appropriate tags), but in between, in the Chorus network, their documentation makes it pretty clear that they expect the packets to have the 802.1Q PRI tags set for traffic to be given priority. In the absence of congestion, that does not matter much, but as more and more people connect to fibre, there will be congestion problems eventually. So it is much better to discover problems like this now and get them fixed.

I am only using my 7390 for telephony, as I have a Linksys WRT1900AC router to do my WiFi - it does 802.11ac which the 7390 is not capable of (7490's do ac). What I have done to make the 7390 work just like it was directly connected to the fibre is to give it the same IP address as the external IP address given by 2D to my erl router, and to connect it in the same way as it does on the fibre, using PPPoE on VLAN 10. I do not have it working on IPv6 as the PPPoE software in the EdgeRouters can not handle that yet. The rest of my network does do full IPv6.

The trick to making this work is that my main router (erl) has my external IP address on its eth0.10 PPPoE connection to the fibre. A router can not have the same IP address on different interfaces, as it would not know which interface it should send a packet destined for that address to. So I need a second router to have the second copy of my external IP address. Since I had a spare Edgerouter Lite as a backup unit, I just used that. All packets arriving at my external IP address on the main router (erl) that need to be sent on to the 7390 get the destination address changed to one of my internal IP addresses assigned for this purpose, representing traffic to the external interface of the 7390. Packets with the 7390's internal IP address are routed to the second EdgeRouter (erlt). Inside erlt, any packets that arrive from erl with the 7390's internal IP address get that address changed back to my external IP address and are routed on using that address. Since the PPPoE server on erlt that connects to the 7390 has my external IP address as the address it provides to the 7390, the packets for the 7390 get sent to it over the PPPoE VLAN 10 connection. In the other direction, packets from the 7390 get sent out to the PPPoE server on erlt using my external IP address, and inside erlt they get the external IP address changed to the internal IP address and are sent on to erl. In erl, packets arriving from erlt with the 7390's internal IP address as their source address get that address translated back to the external IP address and are routed on out the PPPoE connection to the fibre.

The traffic that needs to be sent to the 7390 to handle configuration from 2D and telephony is the following ports:

UDP 5060 (VOIP SIP)

TCP 8089 (TR-069 management)

TCP xxx (https login port - this varies between 2D customers, depending on what they set up at the time. It may not be necessary to have this port open once it has been used initially by 2D to set up the FritzBox for TR-069 management, but I have kept it open for my own use).

UDP 7078-7109 (VOIP RTP)

Changing addresses in the EdgeRouters is done using NAT rules. Packets to the 7390 get their destination address changed using destination NAT rules or ordinary "forward-to" rules (which are just simplified destination NAT rules). Packets from the 7390 get their source addresses changed using source NAT rules.

For the sake of completeness, I have also spoofed the MAC address of my 7390 on erl's eth0 port, so that if the 2D router it is connecting to viap PPPoE VLAN 10 can see that address, it will see what it is expecting if it was connecting directly to my 7390. It is unlikely that it is necessary to do that.

I would like to be able to do all this in just one EdgeRouter, but the only way I can see to do that would be to write a customised version of the PPPoE server software that did the address translations internally. It would present the internal IP address of the 7390 to erl's routing, and would present my external IP address to the 7390. That would involve being able to compile things to run on an EdgeRouter, which I have not got set up, but other people have reported being able to do. I may try this at some point if I find the time, but in the mean time, my current setup works well, just costing a little more on my electicity bill to run an extra EdgeRouter.

If you do not have a static external IP address as I do, then you would also need a script that detected any change of your extenal IP address and changed that address in the config of the main router and the router connecting the FritzBox, then force the FritzBox to reconnect. That is a non-tivial script, but definitely possible to do. It could reside on either router, or somewhere else on your network.

If anyone wants help with doing a similar setup for themselves, please feel free to PM me and I can provide the Edgerouter config to do it.

I don't think I'd attempt a setup like that until I was a little more savvy with the EdgeRouters, also don't want to by another one!

Other than retaining the TR-069 access for 2D, does this setup give you any other benefits?

1 | 2 | 3